OpenMRS has HL7 standards in its blood. The community has, from the very beginning, used HL7 standards as a point of reference. As the world embraces the HL7’s Fast Healthcare Interoperability Resources (FHIR) standard, OpenMRS needs to fully embrace this standard and become a leader in its adoption.
While HL7 standards are most commonly promoted for the sake of interoperability (allowing disparate systems to “speak the same language”) and this is a very important need within the OpenMRS community, there are several additional benefits of standards that are equally (if not more) important for OpenMRS:
- The ability to adopt/use tools built against the standard.
- Increases the number of developers who can contribute.
- Development is quicker & less costly (e.g., avoid inventing custom models and then discovering their limitations after building up technical debt).
FHIR also presents many new options for OpenMRS, whether it’s integrating OpenMRS with other systems, reporting data to centralized systems, providing a way for applications to interact with OpenMRS without needing to understand the OpenMRS data model, or supporting clinical decision support FHIR holds exciting prospects for the future.
Where we have been
The core of OpenMRS is the OpenMRS data model, which is based loosely on the HL7 model, has served well through the years, scaling from small HIV and TB clinics to teaching hospitals. Notable efforts to promote access to the data and improve interoperability along the way include the AtomFeed module, the REST API, and various modules that have been developed over the years to support export of healthcare data to common formats including HL7 v2 and trusty CSVs. But the custom data model and API of OpenMRS limit our ability to exchange data with external systems, require custom code for every new application feature, and require developers to learn an OpenMRS-specific approach to clinical data.
In 2015, OpenMRS served as an early pilot for adding the FHIR API to an existing electronic medical record. Since then, a FHIR module has been part of the core OpenMRS distribution. However, this first version of the FHIR module has seen very little adoption by implementations and OpenMRS’s FHIR capabilities have remained under-developed (built for FHIR v2, while FHIR has since evolved to v4).
Where we are today
Since December, the FHIR Squad has been hard at work creating a new FHIR2 module. The purpose of this new module is to provide a flexible and extensible mapping from the OpenMRS data model to FHIR v4 resources. While the module provides a common framework for mapping OpenMRS data to FHIR resources, it remains pluggable to allow it to adapt to various ways data has been stored in OpenMRS over the years and across different implementations. This new module is nearly ready for its first stable release, when it can be adopted into the core OpenMRS Platform.
Most importantly, the FHIR squad is still looking to support real use cases across the community. Currently, we are working with ITECH and UW, using FHIR to integrate the global edition of OpenELIS with OpenMRS. We are also working with the Micro Frontends squad to ensure the newest OpenMRS frontends use FHIR to communicate with the OpenMRS backend.
Interoperability in the age of FHIR
One of the main strengths of OpenMRS, making it successful in a wide variety of situations, is its modular architecture. Developers and implementers are able to add functionality they need on top of the OpenMRS core data model and services. FHIR offers the opportunity to scale this out even further. What is exciting about FHIR is not FHIR itself, but the doors that open when we embrace a standard.
One of the more exciting capabilities being built on top of FHIR is the SMART on FHIR protocol. This protocol enables third-party applications to securely interact with permitted patient data stored on a FHIR server and even feed this data back into the system. This is useful for building clinical decision support tools that are not tied to a particular system or backend. These solutions could be developed in one country for one system and easily migrated to other countries and other systems.
In addition, FHIR enables us to utilise analytics tools built to support FHIR-formatted data. A number of tools and pipelines that can consume FHIR-formatted data are actively being developed around the world. Being able to represent OpenMRS data in a FHIR format enables OpenMRS-based systems to take advantage of these new pipelines.
Of course, FHIR is also useful for many cases where it is necessary to exchange data with other systems or to produce data in a standardised format for analytics pipelines.
The Future of FHIR in OpenMRS
Adding FHIR capabilities to OpenMRS cannot serve as an end unto itself. After all, if the FHIR module does not provide a way for implementations to do things they could not otherwise do, we will see very little adoption of it. Fortunately, some work on exciting directions is already taking place.
-
As mentioned above, the FHIR squad has been engaged in work with ITECH to provide a FHIR-based interface for talking to OpenELIS Global. We expect this work will lead to a module to provide FHIR-based connectivity with OpenELIS for implementations that want to use OpenELIS as a lab information system alongside OpenMRS.
-
We have a GSoC project underway this year to pilot providing an interface for SMART on FHIR using OpenMRS and the open-source Keycloak authentication provider. By September, we expect to have the groundwork for an easy-to-deploy system that can be used to integrate SMART on FHIR applications with OpenMRS.
-
We have funding through a DIAL grant to build support for pushing changes from the OpenMRS FHIR Server to other FHIR servers. This change will help us to fulfill use-cases where the exchange of data via a notification is necessary; for example, to send an order to a lab or send patient details to a shared health record or master patient index.
-
We have a small group of people who are interested in building on our work with the FHIR module to support the FHIR Bulk Data Access / Flat FHIR implementation guide and the FHIR Asynchronous Request pattern that supports it, which allows for efficient querying of large quantities of FHIR data. This can serve as a basis for many data pipelines that are based around consuming a large volume of data in a single step.
In the longer term, we hope that OpenMRS will see FHIR not simply as a bolt-on product, but as a core part of the application and that the various FHIR APIs will become the preferred way of accessing health care data stored in an OpenMRS instance.
