MENDS-on-FHIR: leveraging the OMOP common data model and FHIR standards for national chronic disease surveillance

Abstract

Objectives: The Multi-State EHR-Based Network for Disease Surveillance (MENDS) is a population-based chronic disease surveillance distributed data network that uses institution-specific extraction-transformation-load (ETL) routines. MENDS-on-FHIR examined using Health Language Seven's Fast Healthcare Interoperability Resources (HL7^® FHIR^®) and US Core Implementation Guide (US Core IG) compliant resources derived from the Observational Medical Outcomes Partnership (OMOP) Common Data Model (CDM) to create a standards-based ETL pipeline.

Materials and methods: The input data source was a research data warehouse containing clinical and administrative data in OMOP CDM Version 5.3 format. OMOP-to-FHIR transformations, using a unique JavaScript Object Notation (JSON)-to-JSON transformation language called Whistle, created FHIR R4 V4.0.1/US Core IG V4.0.0 conformant resources that were stored in a local FHIR server. A REST-based Bulk FHIR $export request extracted FHIR resources to populate a local MENDS database.

Results: Eleven OMOP tables were used to create 10 FHIR/US Core compliant resource types. A total of 1.13 trillion resources were extracted and inserted into the MENDS repository. A very low rate of non-compliant resources was observed.

Discussion: OMOP-to-FHIR transformation results passed validation with less than a 1% non-compliance rate. These standards-compliant FHIR resources provided standardized data elements required by the MENDS surveillance use case. The Bulk FHIR application programming interface (API) enabled population-level data exchange using interoperable FHIR resources. The OMOP-to-FHIR transformation pipeline creates a FHIR interface for accessing OMOP data.

Conclusion: MENDS-on-FHIR successfully replaced custom ETL with standards-based interoperable FHIR resources using Bulk FHIR. The OMOP-to-FHIR transformations provide an alternative mechanism for sharing OMOP data.

Keywords: HL7 Fast Healthcare Interoperability Resources (FHIR); Health Level Seven; electronic health records; health information interoperability; public health surveillance.

Figure 1.

Level 1 logical data flow diagram. Yellow components perform the OMOP-to-FHIR transformation and FHIR server upload. Green components perform the Bulk FHIR export and FHIR-based ETL into the MENDS database.

Figure 2.

Structure of “OMOP JSON” extracted from OMOP CDM V5.3 queries using synthetic data based on the OMOP Condition_Occurrence table. The person_id, provider_id, and condition_start/end date fields do not refer to actual values.

Figure 3.

Whistle transformation specification for creating FHIR R4 Person resource from OMOP CDM V5.3 Patient record. Functions such as USCore_Birthsex() use a unique feature of the Whistle transformation language that calls FHIR concept maps to convert OMOP-specific concept_ids into US Core IG-compliant CodeableConcepts.

Figure 4.

FHIR ConceptMap maps OMOP-specific concept_ids for patient sex into FHIR US Core compliant values.

Figure 5.

Multiple JSON Codings in a FHIR code element enable inclusion of both local source and FHIR-required values. In this example, both FHIR-required RxNorm (red box) and local NDC source codes (green box) are included in 2 Coding objects in the Medication.code JSON object.