Systems Interoperability

Hi all,

It is time we started work on this topic. All contributions are highly appreciated. To start us off, here are some of the items to be in the TOR.

  • Clearly description of the inter-operability problem we are trying to solve
  • Proposed solution(s)
  • What it will take to implement the proposed solution
  • Propose timelines with a high level road map
  • Proposed roles and responsibilities
  • Proposals on how to engage other stakeholders

I’m working on a draft TOR. Any person with a contribution to any of the items above are welcome to submit it.



I know that Gitahi had done some considerable work on this. Do we want to use that as a starting point and build on it or should we do this from scratch? I am leaning towards the former.



Yes I agree that where there is some work we should evaluate first before starting from scratch and in this case I recommend that we start with what goals to achieve. For example it is great that different teams are building different systems all serving the same patient such as in kenya

EMRs serving adult clients(either HIV or all Clients) (variousEMRs) LIMs serving the Lab HITs tracking pediatric HIV data EID/Viral load systems tracking Pediatric/Adult lab sample ADT tracking HIV dispensed drugs Financial system tracking hospital finances in OPD and inpatient

Could we then agree at what solutions we would like to offer jointly given the above situation ?

There has been quite a bit of work on this front for some time and the new SMART wrapper and FHIR modules seem to be moving OpenMRS into a more traditional interoperability universe. Of note, it is import to distinguish between electronic data interchange and true semantic interoperability which requires actionable transmission of data between systems. The CIEL dictionary has provided reference terminology maps to the OpenMRS concepts since its inception. Understanding how the information model of OpenMRS translates to other systems is also important. I believe someone was working on a C-CDA interface which would be an important step (and will not likely be totally replaced by FHIR anyway). Happy to talk to folks about the terminology parts of this.


Thanks Stans, for getting this started.

As people have pointed out, there are a number of disjointed efforts put by different people at various points and this is a good opportunity to align our thinking and strategies.

I think a TOR is useful as a place to consolidate high level ideas and overall vision. But I also think interoperability at the scale we envision it is complex enough that we need some way to represent the details. I hope as the conversation advances ideas will emerge for how we might do this.

Let me now take a shot at defining the first 2 items of the TOR, which I hope team members will review, critique and build upon.

What problem are we trying to solve?

Simply put, there exists many Health IT systems that store and manage data on the same subjects, typically patients and care providers. As things stand now, each one of these systems provides a useful perspective of some aspect of the totality of all data available in a given context e.g. a single patient’s record might fragmented across an EMRS, a PIS, an LIS and even a County Data Repository.

Unfortunately, it is currently impossible to take a more holistic view of this data - which has advantages not only in terms of improved patient care but also policy making. The desirable scenario is for these systems to be able to meaningfully exchange information e.g. an EMRS sending a patient’s prescription to a PIS and the PIS eventually sending back the actual medication dispensed.

These exchanges can get complicated very quickly as the use cases expand, thus the need for a well considered, robust and scalable solution.

What solution do we propose?

Solving the problem of systems interoperability is most complicated by the following factors;

  1. The fact that the systems involved are typically implemented using different technologies.
  2. The need to unambiguously identify entities e.g. patients and health facilities across the different systems.
  3. The potential complexity of network connections between the systems in order to satisfy different use cases.

The solution we create must take these challenges into account.

  1. The problem of disparity can be addressed through globally accepted standards. There are standards for both terminology e.g. SNOMED-CT, and also for message packaging e.g. HL7. These then become the “standard language” by which disparate systems communicate.
  2. The problem of unambiguous identification can be addressed through universally unique identifiers. However, these require registries (think MPI, for example) that are searchable by other attributes to retrieve the unique ids. For instance, unique ids assigned to patients might be unwieldy and difficult to remember but they can be retrieved from an MPI system by supplying more “natural” patient attributes such as names, telephone numbers or even bio-metric identifiers.
  3. The problem of potential network complexity can be addressed via a hub-and-spoke architecture where the hubs act as “routers” to deliver traffic to “end-points”. This means that communicating end-points are relieved of the responsibility of locating each other on the network and instead need only to know each other’s “application addresses”.

I-TECH has designed, developed and prototyped each of these solutions to different extents. I am sure other organizations have too, and we can all benefit from the lessons learned. We can also, as I think (Edwin Mulwa) @eddiemu suggested, take some time to determine what existing work we can leverage and how much needs to be done from scratch.


Gitahi, you have summarised this quite well and clearly. I agree with you that let us not complicate interoperability any more than it already is even as we detail out a TOR for this WG. A couple of suggestions;

  1. Those developing/implementing some sort of solution to improve/enhance interoperability between multiple health information systems, kindly share some write up that describes your solution. The point of this is to educate ourselves on what is being done by ourselves, members of OpenMRS Kenya (and beyond this community too), but even more importantly, determine reusable artefacts from all our efforts, then leverage on that to collectively/collaboratively push through a broadly usable solution. For now, I only know of KEMRI-CDC and I-TECH that are developing an interoperability solution. Anyone else in Kenya? (of course we all know about OpenHIE -
  2. In addition to #1 above, please share your roadmap as well.
  3. I challenge for now KEMRI-CDC and I-TECH to then compare their approaches, road maps, etc and clearly describe where they see opportunities to leverage on their individual efforts and just do it.