OpenMRS' FHIR Strategy

Why FHIR? 

• Integrations between systems in healthcare are critical for exchanging important health information - e.g. between the EMR and a Lab System, or Inventory System, or a National Identify System.
• HL7 FHIR is a standard for how information can be shared between systems. Over the last decade FHIR has been embraced by health system leaders and corporations world-wide as the standard-of-choice for health-related data sharing. 
• In recent years, OpenMRS community members are increasingly embracing FHIR as an efficient way of achieving cross-system interoperability. 

How can OpenMRS Members use FHIR today? 

• OpenMRS FHIR API: The community-created, community-maintained OpenMRS FHIR Module acts as a translation layer between the FHIR standard and OpenMRS' custom data model: it maps OpenMRS data model items to FHIR Resources, and provides a FHIR REST API developers can use to query data for purposes of client-side rendering (e.g. a frontend widget) or data exchange with another system. The FHIR Module allows both export and import of data in the form of FHIR Resources - a "two-way street". More guidance below on this page. 
• OpenMRS FHIR IG: To see which FHIR resources are mapped to OpenMRS and what to query, see the OpenMRS FHIR IG documentation here. The OpenMRS FHIR Module does not (yet!) cover all possible FHIR resources nor all the data in OpenMRS, but we have aimed to cover the highest priority items. We have been building out the module with community implementers based on their pressing needs (e.g. see the Lab System, MPI, and SHR use cases below). 

Last Updated: April 5 2023 by Grace Potma. Note: We are forever grateful to Brown University and ITECH for their dedication in co-founding the OpenMRS FHIR Module. 

Guide: Using FHIR with OpenMRS

How to Use the OpenMRS FHIR API

• How do I know what FHIR resources are supported by the OpenMRS FHIR API?
  • See the list updated in the OpenMRS FHIR IG here: https://fhir.openmrs.org/toc.html 
• Why use the OpenMRS FHIR API instead of the REST API? 
  • Reduce Cognitive Load of Integration: Eventually devs will no longer be building a custom knowledge base, but one that can be used to integrate with any system → reduce cognitive load of integration
  • Better Search Capabilities: Lots of things the FHIR API can do search-wise that can’t be retroactively implemented in REST API
  • Addresses REST Weaknesses: There are a number of deficiencies in the REST API that are not easy to fix. (e.g. impossible to list all pts) Caveats: There are some things supported more cleanly by the REST API, e.g. global properties. 

What to do if an endpoint or resource is not yet supported by the OpenMRS FHIR Module

• First: Check through and see how resources and profiles are being developed following a given example here https://github.com/openmrs/openmrs-contrib-fhir2-ig/commit/4184cc797d50c9acccdf967fba3770974ae14c6f.
• Then: File your need in the OpenMRS FHIR Module Issue tracker. Example: FM2-131 - Getting issue details... STATUS  Please mention if you are interested in helping to add this resouce. (Need access to our Jira? Request here.)
• Contact the OpenMRS #fhir expert community in our FHIR Slack Channel (sign up for OpenMRS Slack at slack.openmrs.org) 

What to do if a resource is not clear or supported by HL7 FHIR in general?

• Don't worry - the HL7 FHIR community is very friendly, and in fact, they are very keen to hear from folks in Lower- & Middle-Income Countries. Don't hesitate to ask your questions and share your use-cases at: https://chat.fhir.org/ 

Examples: Showing FHIR being used in real OpenMRS Implementations

For an exhaustive, more detailed list, please see Real-world OpenMRS FHIR Projects and Tutorials. These examples and videos should help inspire you: 

Tutorial Videos & More

Other Applications of FHIR in OpenMRS

• Using FHIR for Data Storage

  • Some community members are interested in whether a FHIR Database (e.g. HAPI FHIR / SmileCDR) could eventually be used to completely replace the custom OpenMRS backend altogether. It would be ideal to have less technical infrastructure like our custom backend model to for our implementers and community to have to maintain. However,  this would obliterate the current OpenMRS Reporting functionality, which would have an enormous impact on the many implementers who depend on OMRS for reporting purposes. There remains world-wide debate about whether FHIR should only be used for data transfer rather than data storage. We are keenly watching the experience of other global goods like Ona who recently completed this switch to a FHIR database. We are on the look out for community interest in and maintenance of the current FHIR Module to help us gauge the actual market demand for FHIR amidst OpenMRS implementers. Given limited resources we need to be clear with our focus on whether we are focused on FHIR for Integration or for Storage - so for now we are focused on Integration use cases and benefit.

• Using FHIR for Data Analytics at scale

  • Google Health recently collaborated with the OpenMRS Analytics Squad on exactly this use case. The resulting tooling for performant fhir-based data analysis is the "fhir data pipes" project, a collection of tools for extracting FHIR resources and analytics services on top of that data.