Where does OMOP-OHDSI fit in the open source health informatics environment?

Introduction

The OHDSI initiative is a globally recognised collaborative network of researchers, developers and clinicians dedicated to harnessing the potential of observational healthcare data. Through the adoption and continuous enhancement of the OMOP Common Data Model (CDM), OHDSI advances large-scale analytics to improve health outcomes. In addition to improving analytical capabilities, the initiative actively expands the scope of the OMOP CDM via specialized working groups, enabling its application across diverse data domains—including clinical trials, rare disease registries, and oncology datasets.

As the OHDSI community expands in its influence and methodologies, a question arises: How does OHDSI/OMOP integrate into the wider health informatics ecosystem? This blog will further explore the positioning of the OHDSI/OMOP to other widely-adopted standards, such as OpenEHR and FHIR, specifically on the domain they each inhabit and the complementary roles they offer each other. 

OHDSI versus openEHR

openEHR is a comprehensive e-health technology framework that provides open specifications, clinical models and software to standardize the capture and maintenance of electronic health records (EHRs). At the core of openEHR are the extensive ‘archetypes’: structured, reusable models that define clinical events in a relevant, consistent, and interoperable manner. The framework is primarily focused on semantic modelling and the persistent collection and sharing of EHR data within clinical environments.

While openEHR supports research with structured clinical data, it is not optimized for in-depth exploration and analysis. In contrast, OHDSI is not intended for operational use in healthcare settings, but instead provides a robust ecosystem for conducting meaningful observational research. OpenEHR can collect and structure data meaningfully, while OMOP can generate high-quality, reproducible real-world evidence from such sources. Together these frameworks offer complementary strengths, combining vendor-agnostic detailed data collection (openEHR) with a harmonized and large-scale analytics model to gain the highest-quality insights possible. 

An example of the semantic modelling differences between openEHR and OMOP is illustrated below. 

Example: Observation period

A core data element of the OMOP CDM is the ‘observation period’, which has no equivalent in EHR systems. This period is person-specific and represents the time span in which healthcare encounters occur for this person. In research, this determines how many years of follow-up time are available for analysis, both in a cohort and per person. An absence of events in a particular period means that this person did not visit the clinic. For clinical researchers, this is important information with regard to cohort inclusion criteria (e.g., minimum follow-up period). In clinical practice, this is less relevant information, and therefore not normally captured.

OHDSI versus FHIR

FHIR (Fast Healthcare Interoperability Resources) is a universal standard for the exchange of patients’ health records from EHR-systems. It is composed of so-called resources, bundled in profiles that specify how a particular information element should be represented. There are around 100 resources, including diagnostics, medication, physical measurements, et cetera. FHIR distinguishes itself by having a description of the API that exposes the resources from the underlying EHR system. This allows other applications to (securely) pull data from and push data to EHR systems. There are multiple sandboxes to explore the standards, e.g., Synthetic Mass, where a simulated population of Massachusetts has been exposed through FHIR.

In contrast to many other standards, FHIR is not the endpoint of the data. Rather than persisting data in this standard, it facilitates data transfer to other applications using the resource profiles and API definition. EHR-systems, like openEHR, can use FHIR to expose data to other applications. These can be consumer apps that make health data more insightful to patients or research platforms like OHDSI. However, FHIR data is not as useful for observational health data research; this is where the OMOP CDM provides a valuable avenue.

The transformation of FHIR data towards the OMOP CDM is a long-standing problem the solution of which is of particular interest to observational data researchers, because the usage of the FHIR specification is widespread among hospitals, but data conforming to FHIR is not readily usable for observational studies. Being able to convert these data to OMOP will unlock a vast amount of data for the purpose of such research and analytics and enable interoperability between the two standards. To address this issue, HL7 (Health Level Seven) — the foundation that has founded and is maintaining FHIR — is now collaborating closely with the OHDSI community on the development of the FHIR to OMOP implementation guide.

The FHIR to OMOP implementation guide will serve as a roadmap to ETL developers to convert FHIR data to OMOP in a more standardized manner, reduce implementation costs, increase the speed of FHIR to OMOP ETLs, and uplevel the quality of transformed data. To streamline this process, overlapping vocabularies between the FHIR terminologies and OMOP vocabularies are prioritized, as these make up the lowest hanging fruits for semantic mappings between the standards. Next, to ensure clinical and analytical relevance, clinical specificity criteria are to be considered to reduce the amount of relevant information that is lost. Thirdly, primary designations of FHIR resources and elements towards the OMOP CDM are to be determined, to transparently and logically prioritize syntactic mappings between the FHIR specification and OMOP. Lastly, to ensure deduplication and reproducibility within ETLs, temporal precedence rules have been constructed to specify the order in which equal codes are to be selected. Overall, the implementation guide ensures consistent, reproducible, and clinically valid code selection across FHIR to OMOP transformations.

Following is an example of how FHIR facilitates the connection between EHR-systems and scientific research using the OHDSI tooling.

Example: Predictive modelling

The OHDSI analytics and FHIR exchange standards can strengthen each other. A predictive model is a good example. In this case, OHDSI tools support the creation of a model, using the Patient Level Prediction (PLP) package that runs on any OMOP CDM database. The resulting model can be applied to personal health data by using FHIR resources. If you would like to know more, you can read more about this research here: Clinical Predictive Modeling Development and Deployment through FHIR Web Services.

Conclusion

As we have shown, openEHR, FHIR and OMOP/OHDSI are not exclusive tools, but each has its place in the health care and medical research data environment. Besides, they can be combined to serve a particular purpose. In summary:

  • openEHR focuses on comprehensive clinical information models and can be used to implement systems that collect and persist medical records using open standards. These standards enable the exchange of patient information between clinicians and/or to other standards.
  • FHIR focuses on pulling records from (and pushing to) a growing number of FHIR compliant EHR-systems. Medical apps can be built on top of FHIR to aid/support patients, health care providers and researchers.
  • OHDSI has been built for scientists, providing them with the tools to generate high-quality and reproducible evidence from observational health data. The data can be extracted, transformed and loaded directly from medical claims data or EHR-systems, and exchange standards like FHIR can facilitate this process.
Tags
Written by

Maxim Moinat

Liam Glück

Guus Wilmink