Wiki Spaces


Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack


Page tree
Skip to end of metadata
Go to start of metadata

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, the OpenMRS community - especially implementers and policy makers - has increasingly embraced 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". 
  • 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). 

Other Applications of FHIR

  • Using FHIR for Data Storage. Some community members are interested in whether a FHIR Database (e.g. HAPI FHIR) could eventually be used to completely replace the custom OpenMRS backend altogether; however, there remains world-wide debate about whether FHIR should only be used for data transfer rather than data storage. For now, we are keenly watching the experience of other global goods like Ona who recently completed this switch to a FHIR database. In fact, we are watching community interest in and maintenance of the current FHIR Module to help us gauge the actual market demand for FHIR amidst OpenMRS implementers.
  • 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. 

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

Links to Know

The OpenMRS FHIR Implementation Guide (IG) at

Guide: Using FHIR with OpenMRS

How to Use the OpenMRS FHIR API

Best Practice Guideline

The OpenMRS Global Product Support Team recommends that all frontend contributors leverage the FHIR API as much as possible. (e.g. O3 development.)

  • 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. 
  • How is FHIR structured in general? 
    • The aim of FHIR is to provide the 80% base functionality that most people need to represent data in a healthcare context and exchange it across different systems
    • FHIR provides a syntax-neutral logical data model for representing objects involved in various kinds of health care transactions. For example, what information needs to be communicated about a Patient? A Provider? These logical data models are called resources.
    • These logical data models can be mapped to specific syntaxes, e.g., XML or JSON.
  • How can I navigate the HL7 FHIR online docs? 
  • How do I know what FHIR resources are supported by the OpenMRS FHIR API?

Resources to Bookmark

Bookmarks OpenMRS Devs have found helpful:

What to do if an endpoint or resource is not supported

Coming soon

Contributing to FHIR in OpenMRS

Coming soon

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: 

Lab Results Exchange: OpenMRS and OpenELIS Interoperability using the OpenMRS FHIR Module

MPI (National Patient Identity Index): OpenMRS system and MPI interoperability using the OpenMRS FHIR Module

SHR (Shared Health Record): OpenMRS system and SHR interoperability using the OpenMRS FHIR Module

Tutorial Videos

Tutorial Video: Intro to the FHIR API in General

Want to know more about FHIR?

FHIR (Fast Healthcare Interoperability Resources) is an HL7 standard for representing healthcare information electronically. It is based on a series of Resources, which define common representations for different kinds of healthcare data. You can find the current version of the FHIR specification at

  • No labels