In a collaboration with AMPATH, Palladium,and Health IT in Kenya, we proposed “OpenMRS Connect”, an interoperability layer for OpenMRS. It allows for seamless integration with other EMR systems, and health information systems (HIS), as well as with third-party apps and services that support FHIR. This enables healthcare providers to share patient data across different systems and platforms, improving patient care and streamlining workflow.
The Approach
We want to develop an OpenMRS IL that leverages Hibernate events(Using Events module - hibernate interceptors) to listen to database operations and retrieve OpenMRS objects, which are then converted into FHIR messages using the fhir2 module API. The messages are then published to an external message broker (such as Kafka) or a middleware (such as OpenHIM). OpenHIM is an ideal middleware for this interoperability layer because of its flexibility, integration with FHIR, robust security features, scalability, monitoring and logging capabilities.
With this approach we have developed a proof of concept interop module which seamlessly emits FHIR messages to OpeHIM channels. Once the FHIR messages reach the openhim server, they are queued and , we can do customizations and data transformations to suit the target system leveraging OpenHIM mediators. Mediators in OpenHIM are components that handle the mapping, transformation, and orchestration of health information between different systems. Mediators can be custom-built or configured to handle specific types of data or interactions. They act as intermediaries between different healthcare systems and ensure that information is translated into a format that can be understood by all participating systems.
We would like to invite the OpenMRS community to consider our approach and provide feedback and suggestions. We believe that this approach will enable integration of OpenMRS with other health IT systems/health information systems(HIS). We look forward to working with the community to make it a reality.
Great work @corneliouzbett/team and thanks for sharing. Without knowing much details, I feel that Kafka integration can open up many use-cases too; great idea.
I have not been paying close attention to OpenMRS/FHIR-module development for a while. But over two years ago when we wanted to solve a similar integration problem (for the Analytics streaming pipeline) we considered Events-module/Hibernate-interceptors but decided against using it. Instead, we implemented a separate Debezium based tool that would listen to DB log messages and fetch FHIR resources when needed. You can see the main function here. I am just curious if you considered this as an option too and why you decided against it? I can think of reasons but I prefer not to speculate
One reason we chose our approach was the separation from OpenMRS service. That said, if back then OpenMRS had native Kafka support with FHIR resources, we would have definitely considered developing against that too.
Thanks for sharing @corneliouzbett. Some really quick comments below.
This makes a lot of sense and is done following comparable patterns in Ozone:
Multi-directional integration routes with openmrs-eip (as @dkayiwa pointed out), this relies on Debezium anyway btw.
Use case “all things EIP”:
like syncing EMR drug orders with pharmacy systems prescriptions, or syncing EMR lab test orders with LIMS analysis requests, etc.
like syncing back data into the EMR (I don’t see this in your diagram), like receiving lab test results from the LIMS.
Streaming out with Kafka - by leveraging Apache Flink (but Apache Spark is as good), and this also relies on Debezium.
Use case, outbound real-time data analytics.
Roughly if I attempted to compare:
Function
Ozone
Your architecture
EIP
Apache Camel (+ ActiveMQ)
OpenHIM
Streaming
Apache Flink
Debezium + Kafka
We did not leverage the Event module because we wanted the middleware to not be invasive, and to stay outside of the OpenMRS distro. We went for more of a plug and play microservice architecture.
Before settling on the approach shared, we looked into Spring AOP and Debezium for CDC but ended up settling on Hibernate Interceptors and take advantage of the Event module though rarely maintained, it would be easier to intergrate with FHIR such that when those event are registered(creation of patient, creation of encounters etc) we delegate FHIR 2 module to convert into compartible FHIR resource and push that to OpenHIM, then through application of mediators for transformation, we let the routing mechanism deliver that on the SHR(https://linuxforhealth.github.io/FHIR/). The systems participating in the data exchange are NOT all entirely running on OpenMRS framework, so consumption from the SHR is upon the respective systems to figure out how, what everyone else is required of is to PUSH uniform FHIR compliant profile/resource to the SHR. The systems consuming can decide if to store certain sets locally from the SHR but that is upon them, sice there is Unique Patient Identification dictated by the Client Registry, we intend to reference unique patient clinical information every time a doctor would request patient history
We built something like this in UgandaEMR leveraging the FHIR2 module and so far we have used it to implement about 3 HIE projects.
The engine helps in filtering targeted data and then pushes it to any API as long as it FHIR Based.
One could decide to bridge with a mediator should one choose to. Its bee really helpful and reduced the development time taken in defining any HIE project provided it requires data in FHIR format.
Thanks @slubwama can we organize for 30 minute talk share this over a google meet, looks like what we are doing is already there and we can take advantage and just leverage
Because it is Hibernate-based, it will miss out on any non-Hibernate transactions. And while that should be ok in theory, it is in fact not ok in practice as there is a bunch of code out there that bypasses Hibernate to touch OpenMRS’ database. There is also a bunch of processes out there (data migrations, custom integrations, etc) that may bypass the Java API. This is where Debezium is truly ubiquitous and where the Event module will remain blind.
As an aside it would be possible to make the Event module listen to Debezium. But that’s not the case right now and because of our microservice-based architecture an org. like Mekom never had sufficient incentive to bring this to the Event module in order to use it.
A note on the Event module vs pure outside middleware
Looks like folks were drawn to stick to a module to enjoy the OpenMRS Java API within their custom modules, typically to create FHIR messages out of events, etc. I can see why people find this convenient, and yet it is unnecessary from an architectural standpoint and contributes to the proliferation of custom modules within distributions.
Furthermore there are no impediments to do just the same thing outside of OpenMRS, in the middleware layer that translates from Debezium payloads to FHIR payloads.
I’d like to know the reasoning behind or why you chose the Debezium approach.
Yes, I’d like the Debezium approach because it provides database-level streaming of events, unlike the hibernate interceptors which are application-level only.
But we are leaning towards the events module; because; it requires additional infrastructure and for small site/facility deployment, an entire stack outside would be overkill, and also it requires technical expertise to maintain this, among other reasons.
I had thought of doing a Debezium-based module to replace hibernate interceptors(Event module).
We still don’t have this. I’d hope we achieve this someday. From the concept, the new module tries to build support for OpenMRS to emit FHIR messages thru Kafka.
Sure. We are happy to share our experience. Maybe we should ask @grace to find us a schedule where this is discussed with the entire OpenMRS community.
We chose Event module because it’s readily available out there, but the Debezium-based module would be the perfect way for streaming events out of OpenMRS.
We chose OpenHIM as the middleware because;
It provides us with plug-and-play microservice architecture. mediators as just pluggable services.
It has support for multiple languages. Java, Javascript, Python, C#
Admin Console
Monitoring and alerts
Scalability
Authentication mechanism
I think OpenHIM is comparable to openmrs-EIP but OpenHIM has more robust features.
Practically for the same reasons above ,
At ITECH ,we leverage a similar architecture ie the Event module for CDC and OpenHIM as a middleware component for integrating OpenMRS with a CR , LIS and SHR .
Some of the WIP includes client registry and Lab on FHIR .
here is a quick demo on the OpenMRS-OpenELIS interop
Hi all, Jembi has been hard at work trying to solve this exact problem. We have been focusing on the central components rather than the EMRs and have come up with something that we are (for lack of a better name) calling the Jembi Platform.
At it’s essence it’s a set of components that can be deployed to enable a FHIR-based HIE, including the OpenHIM, Kafka, client registry tools, a FHIR-based SHR, reporting tools and monitoring tools. As well as a way to deploy them in a scalable way using Docker Swarm. The components are similar to what is being described in this thread. This is how we have through about such an architecture working:
I’d love to hear if this helps to solve the original approach set out in this thread and would love to collaborate on an open approach to solving these challenges.
As an aside, we also have it on our roadmap to build an integration directly into the OpenHIM to push to Kafka. Right now we are doing this through a mediator, however, feel first class support would be better.
Probably worth spawning another topic to discuss in more detail, but this is something that I’ve been working on at PIH in the last month or two. Basically, we feel like there are use cases where a microservice approach fits best (eg. a Debezium-based system running indepedently of OpenMRS), and other cases where it would be most straightforward to have this CDC functionality built into OpenMRS (eg. in a module). I have a new module that embeds Debezium - called dbevent for now - which I am happy to move to the OpenMRS github organization and have more community involvement with (and advice on design and testing!) if there is broader interest. I know others have embarked on similar projects in the past, with similar intents.
@rcrichton I’d like to think of OpenHIM as a message broker but with additional capabilities such as message forwarding and monitoring through the OpenHIM console,
I was wondering what’s the motivation to send data from OpenHIM to another message broker (Kafka)
