[WARNING: LONG POST 
]
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;
- The fact that the systems involved are typically implemented using different technologies.
- The need to unambiguously identify entities e.g. patients and health facilities across the different systems.
- 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.
- 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.
- 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.
- 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.