interoperability Archives

Interoperability for Doctors and Healthcare professionals Part I

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!

Published by Bell Eapen on December 13, 2014 | Permalink

Yosemite Manifesto on RDF as a Universal Healthcare Exchange Language

Layered Semantic Web Technology Stack (Photo credit: jalbertbowdenii)

The Bring Your Own EMR (#BYOE) pronounced ‘bio‘, as explained in my last post relies on a reliable interoperability platform. I have always believed that RDF is the key to successful interoperability. RDF has successfully been employed in several other fields and has many stable tools such as jena. I was searching the web for information on how to present the advantages of an RDF based interoperability platform for healthcare data. Then I found this website.

Yosemite Manifesto, pretty much summarizes whatever I had in mind and a lot more! They are also trying to raise awareness about the possible advantages of adopting the RDF platform by requesting researchers to sign a form. I have already signed. Have you?

I am starting a wiki page for #BYOE too.

Bring Your Own EMR (#BYOE)

The e-Health lessons from healthcare.gov debacle is being debated widely. The idea of applying large scale IT initiatives in clinical domains has its own risks. As we relentlessly move towards a fully digital healthcare ecosystem, is it possible to hide some of its complexities from the clinicians?

Patient empowerment is the buzzword in eHealth now and clinicians are generally viewed with some skepticism. EHealth has learnt over the years (in the hard way) that the clinicians may be reluctant to relinquish their firm grip on clinical data. After all they generated the data and they are the custodians though they do not own it!

One of the approaches worth trying is to give the clinicians control and freedom over their end of things. In other words, separate enterprise EMR from the physician EMR. However the key to success in this scenario is interoperability.

Interoperability of EMRs are being actively explored by many research teams and organizations. However the emphasis is on better standardization. As interoperability emerges as a global paradigm, the standardization strategy that has failed for the last decade or so, still seems impractical?

I am working on an interoperability solution that segregates physician EMR solutions logically and physically from Enterprise EMR solutions. I would like to call this Bring Your Own EMR (#BYOE) pronounced as ‘bio’. The general framework is shown above. If you would like to join the #BYOE initiative or give feedback, shoot me an email!!