Interoperability Support for Legacy/Commercial EMR Systems

Architecture & Standards
,
#1

Hi All,
With legacy systems(EMR systems),that are working to the expectations of governmental and private health organization units/Hospitals/Clinics, we are facing a challenge of integration(I feel like it’s an obvious problem).

From what I have seen and understood it is difficult(almost impossible) to develop an API to make those legacy/commercial EMR systems interoperable caused by many reasons(closed source, lack of expertise that worked during the EMR development and other similar issues). But one thing I have seen is that, the IT skilled, responsible individuals assigned to manage those EMR systems have become good at database layer of those systems. Taking this as an advantage, developing configurable adapter software system that has direct access to database of those EMR systems will enable us to have data rich shared health record(SHR). The following diagram illustrates the communication:

I believe this should substantially reduce the cost of building API for legacy/proprietary systems. In terms of participatory strategy (where individuals related, in any way, working with the EMR systems shall play their role) the outlined method shall allow expertise of those EMR systems easily join the work force.

Talking interface implementation, this layout is also important in terms of focus where one is engaged in implementing the adapter with dynamic configuration support and easy UI for any one to use. Instead of knowing details of several systems to develop new API (or customize existing APIs), the focus will be only to work on the adapter to incorporate those systems needs.

I am making a review on existing similar solutions. Kindly put a reference I can look to, suggestions/comments you have, direct me to similar works(or works in progress). I will share my review back, promise!

I hope my points are clear! I am available to explain the challenge and proposed solution further, just put your questions in this thread, I will react in no time.

Thank You.
@subcommunity_leads

1 Like
#2

Thank you for sharing. I believe this approach works. I have also seen approaches where the mediator does this type of work. In one of PEPFAR’s solutions, the “adapter” does calculations and message formatting. See: https://wiki.ohie.org/display/projects/Workflow+-+DATIM4U+ADX+(Aggregate+Data+eXchange)+Process

2 Likes
#3

Agreed, this is a feasible approach for legacy systems, and can be achieved using standard ETL (Extract, Transform and Load) practices. As @jennifer.e.shivers mentioned, the adapters could be developed as OpenHIM mediators, or standalone services built using any other ETL tooling (I’ve seen tools like Spring Boot/Batch, Apache Kafka and Talend used in this way), which then sends the transformed data through the OpenHIM and/or SHR.

I think an important thing to consider is what format data will be transformed to after extracting it from the various disparate databases. You’ll likely want to map and transform this into a common data format/schema, and for this, I’d suggest looking at the HL7 FHIR standard as your common schema, especially if the intention is to get this data into an HIE / SHR.

2 Likes
#4

Thank you for pointing me to the resource. The link was helpful specially the reference(following the link you provided) explains similar use case. Again going through the paper the case titled “Routine reporting from EMR”(on page 13) is what I am trying to explain. Except the paper’s objective is focussed on ADX message formats, expecting the EMR systems to provide the required API accordingly. But in our case the EMR systems are untouchable(no way to manipulate the source code) and the Adapter accessing the DB directly is expected to provide the API.

Using the terminologies in the suggested link, the legacy EMR systems are content creators and DHIS2 and SHR systems are content consumers in this special case. I drew the diagram as I want you to think of the adapter as a general purpose and possibility of becoming a FHIR compliant endpoint(exposing the EMR system data).

But again to put a scope to our discussion I have selected one case(among many manual and tedious works that exists), morbidity report. It is feed to DHIS2 after having collected with paper based registry forms. The numbers are aggregated in gender and 12 age groups in the report.

The EMR system has this information(obviously). The Adapter should expose this information, raw information without being concerned to the aggregation and calculations. Among others (that I am not sure now) the adapter should respond ICD-10 code, age, gender, organization unit and period of the transaction/encounter (@daniel.futerman what is this resource in FHIR? ). Having such simplified API, I believe, should be helpful to deploy the adapter alongside multiple EMR systems.

The mediators then utilize the adapter API to do aggregation and other calculations.

An important note here is that the adapter is single implementation being deployed with multiple EMR systems(the diagram in my first post was wrong labeling the EMR systems similarly, it has to be EMR-1, EMR-2, EMR-3 …). This is the whole point of this discussion, having a reusable adapter to enable many legacy EMR systems have an API to interact with. Therefore I like to frame this discussion integrating EMR and DHIS2 specifically for morbidity report(as a case).

I have come up, so far, with the following diagram after going through your references. @jennifer.e.shivers and @daniel.futerman thank you.

https://wiki.ohie.org/download/attachments/48463897/adapter_1.png?api=v2

1 Like
#5

Thanks for the information. I come up with the following comparison on adapter being a Mediator and a separate system.

Being an adapter
We will have as many mediators as legacy EMR systems(EMR instances)

Stand alone service
We will have single adapter but multiple running instances with as many mediators as number of cases arise

I am thinking the adapter as a fit for all.

May be I need to explore more!

Coming to the data format, as you suggested HL7 FHIR Standard should be considered. Now having the special case taken(morbidity reporting in my previous reply), I have seen the measure and measure report resources to be related. But I am not sure on the API(interoperability) part of the FHIR standard in relation to this case. Can you brief on that?

#6

Hi All,

Just chiming in here quickly and wanted to point to some work I recall Jembi mentioning at one of the OpenHIE events - the local Information Mediator. Concept is very very similar to what @haftamu.k is mentioning in initial post – looking to create a way to write queries to extract data from a database and then push it to an HIE service through an OpenHIM or interoperability layer. @daniel.futerman Not sure if this is something that you are all still pursuing or where the code or concept lies?

1 Like
#7

Thanks @carl
Yes, the challenge on the Adapter is exactly as you said, *"looking to create a way to write queries to extract data from a database and then push it to an HIE service through an OpenHIM or interoperability layer”. So to look it a bit in steps,

  1. building queries to access DB and avail it through FHIR compliant API

  2. Use mediator to pull data using the FHIR endpoint(the adapter)

So what was done in this regard? Can you put links I can look for!

#8

I don’t have much details on it, but the adapter I am mentioning is much of like HAPI FHIR. I will put pros and cons of it in relation to our case once I do some more exploration!

#9

I unfortunately don’t have the links to this. Maybe the Jembi team can chime in here? @daniel.futerman @ryan @martinbrocker @thabo.chiloane?

1 Like
#10

HI @haftamu.k

Im not sure if this is maybe the mediator that you have been thinking of but Jembi and our partners have been working on a generic mapping mediator that should be able to handle some of your cases.

The mapping mediator requires no coding experience because its configured via JSON config files.
The mediator currently deals with:

  • Validation: Ensuring the quality of the incoming data meets the validation requirements
  • Mapping: Transforming one object into a different format. Eg
    Legacy Patient format into HL7 FHIR Patient format
  • Orchestration lookups: To perform various lookup requests to external systems for fetching of data for mapping. We also allow for sending of the transformed data to a downstream server for processing. Currently this doesnt allow for any database configuration for extracting data

The mediator repository can be found here:


https://hub.docker.com/repository/docker/jembi/openhim-mediator-mapping

NB! This is still in development and not yet ready for production use

Regards,

1 Like
#11

@carl Just to mention, we discussed this with @haftamu.k on Monday’s DevOps call, and have shared links and info with him, and proposed following this up on this month’s IOL/SHR call.