Bell Eapen MD, PhD.

It is important for health information systems to talk to each other. Unfortunately they speak different languages. This article is not for eHealth experts to understand the nuances of interoperability (HIE), but for health care professionals to have an idea about what is out there and what can be expected in the future.

When we consider HIE we have to think about what is being exchanged (package), how the information is organized (format) and how it is being transported (protocol). Though it is not essential to know, few terms that you might recognize are: HL7, XML for format and HTTP, TCP/IP for protocol. (Have you heard of MLLP? Google it!) The donor has the information in a certain format and protocol while the recipient expects it in a particular format and protocol.

At the core of all HIE platforms such as MirthConnect or OrionHealth’s Rhapsody, is an engine that does this conversion. Format and protocol of donor to format and protocol of recipient. Simple eh?

Is pragmatic interoperability the best solution?- M. Martineau @eHealthMusings explores a pragmatic Rhapsody approach http://t.co/XMkMXAEdt7

— Orion Health Canada (@OrionHealthCA) December 11, 2014

Now most of these platforms have a user interface or IDE for making this connection. You can also introduce certain filters at this stage. Enterprise systems like Rhapsody presents an attractive visual interface, whereas open source solutions may not be very user friendly.

What else can the engine do? It usually keeps a log of all package deliveries and whether the delivery was successful. If the delivery failed, it can attempt again and alert the maintenance team through a console. The console can even be mobile as in rhapsody. Though the engine can store the package itself for a limited time, storing the package is not really its job.

The donors could be:

• A single department in a hospital sending lab reports.
• All departments in a hospital sending all sorts of information.
• Several hospitals in a region.

The recipient could be:

• Another department in the same hospital expecting a lab test report.
• A family physician who wants real time access to the lab reports for his patients admitted in the hospital.
• A researcher who wants to know blood sugar status of all the diabetes patients. (population health)

We need a separate layer between the engine and the recipient to support all these use cases. Let us call this layer mediator.

The mediator can pull data in real time from donors or store it in a local database. The first one is the federated model while the other one is the centralized model. Federated is slow but up-to-date while centralized is fast but not concurrent. Mixed model has both and is preferred. The so called clinical viewers are federated mediators with a web interface.

Emerging paradigms like NoSQL and RDF may be ideal for data representation in mixed model. I have discussed RDF before. Will discuss NoSQL soon!