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.
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.
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
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.
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:
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.