Deterministic OMOP-to-FHIR export validated against US Core 6.1.0

If your organization stores clinical data in OMOP CDM and needs to deliver patient records to a clinical trial sponsor, a payer API, or a regulatory submission, you need a FHIR bundle that validates against US Core 6.1.0 - every resource and required element, for every patient. Patient Journey Intelligence includes a deterministic OMOP-to-FHIR converter that covers all 14 OMOP clinical tables, produces 18 FHIR R4 resource types, and handles the routing decisions that most conversion approaches miss. Tested on a 117-patient Synthea cohort, the converter produced zero US Core 6.1.0 validation errors across all exported bundles.

OMOP CDM organizes clinical data into flat, interconnected tables optimized for population queries. FHIR R4 represents the same data as nested, typed resource documents designed for API-based exchange. The structural gap between the two models is why conversion requires purpose-built logic.

Why OMOP-to-FHIR export requires purpose-built conversion logic

OMOP CDM and FHIR R4 solve different problems, and their structural differences make conversion non-trivial in both directions.

OMOP CDM is a relational research schema. Clinical events from EHRs, claims, and lab systems are normalized into flat, interconnected tables optimized for population queries and cohort analysis. Every clinical event resolves through a fixed set of standard vocabularies: SNOMED CT for conditions, RxNorm for medications, LOINC for labs, CVX for vaccines.

HL7 FHIR R4 is a nested, resource-based exchange standard. Clinical data is represented as typed resources - Patient, Encounter, Condition, Observation, MedicationRequest - each a self-contained JSON document with typed fields, required elements, and cross-resource references by URL. FHIR allows flexible code system bindings per profile; US Core 6.1.0 narrows those bindings with mandatory constraints that base FHIR R4 does not require.

FHIR-to-OMOP (data ingestion into a research database) has established tooling and an official HL7 implementation guide. OMOP-to-FHIR (export for operational and regulatory use) has no normative artifacts - a gap the Patient Journey Intelligence converter fills.

The direction from FHIR to OMOP (loading EHR exchange data into a research database) has attracted significant tooling investment. The HL7 FHIR-OMOP Implementation Guide covers it. The OHDSI community has maintained open-source tools for it. The reverse direction has not received the same attention: the official implementation guide defines mappings exclusively in the FHIR→OMOP direction, and most organizations with a mature OMOP research database have no validated path to export that data back to FHIR for operational or regulatory use.

Three requirements every production FHIR export must meet

Three properties separate an export that works in production from one that fails silently downstream.

Completeness. An OMOP patient record spans thousands of rows across a dozen clinical tables: visits, conditions, drugs, measurements, lab panels, clinical notes, providers, care sites, and devices. Every row must produce a corresponding FHIR resource of the correct type with the correct references. Most conversion approaches have no mechanism to confirm how many source rows they handled and how many they dropped.

Context-dependent routing. A drug_exposure row in OMOP does not map to a single FHIR resource type. Depending on how the drug was prescribed, administered, dispensed, or self-reported, it maps to one of five resource types: MedicationRequest, MedicationAdministration, MedicationDispense, MedicationStatement, or Immunization. A measurement row maps to Observation in most cases, but a panel header row maps to DiagnosticReport. Making these routing decisions correctly requires coded logic, not heuristics. A converter that collapses all drug events into MedicationRequest produces a medication history that is structurally incomplete - vaccination records, dispensing records, and self-reported medications all look the same or disappear entirely.

Conformance validation. A bundle that looks correct to a human reviewer can fail the HL7 FHIR Validator on required elements that are simply absent. Missing a required category slice on an Observation resource, using a terminology URI that falls outside the US Core value set, or omitting a profile annotation on a DocumentReference - each is invisible until a downstream system rejects the bundle. The failure mode is silent: the export completes, the bundle looks populated, and the error surfaces only when the receiving system validates.

OMOP-to-FHIR converter architecture

The OMOP2FHIR converter is a tool included in the Patient Journey Intelligence platform. By the time data reaches the conversion step, it has already been analyzed by upstream platform components - which is what makes deterministic, validated FHIR export possible at this level of fidelity.

Input: enriched OMOP CDM. The source is an OMOP CDM database populated and enriched by Patient Journey Intelligence. Unstructured clinical content such as physician notes, discharge summaries, and pathology reports has been processed by the Ingestion Layer to extract structured clinical facts: diagnoses, medications, procedures, measurements, and device events. Those facts are written back into the appropriate OMOP tables. In parallel, the Terminology Server maps every clinical code to standard vocabularies: SNOMED CT for conditions, RxNorm for medications, LOINC for lab results, CVX for vaccines. By the time the converter reads the OMOP database, every row is structured, coded, and terminology-normalized - no lookup or inference is required during conversion.

Conversion layer: three domain groups. The converter organizes the 14 OMOP source tables into three domain groups, each handled by dedicated mapping modules:

• Administrative data - person (joined with death and location), visit_occurrence, care_site, and provider map to Patient, Encounter, Organization, and Practitioner. These resources form the reference backbone that all clinical resources point to.
• Medications and devices - drug_exposure routes across six FHIR resource types (MedicationRequest, MedicationAdministration, MedicationDispense, MedicationStatement, Immunization, and Medication catalog) based on drug_type_concept_id and CVX vocabulary detection. device_exposure maps to Device and DeviceUseStatement. specimen maps to Specimen.
• Clinical data - condition_occurrence and procedure_occurrence map directly to Condition and Procedure. measurement routes to Observation or DiagnosticReport depending on whether the row is an individual result or a panel header. observation maps to Observation. note maps to DocumentReference, preserving the full clinical note text.

Output: validated FHIR bundle. Once all resources are assembled, the full patient bundle is passed to the HL7 FHIR Validator running against the US Core 6.1.0 profile set. Validation checks every resource for required elements, mandatory category slices, terminology system URIs, and profile annotations. Only a bundle that passes with zero errors is exported as the final FHIR output. Tested on 117 Synthea patients, the converter produced zero US Core 6.1.0 validation errors across all exported bundles.

Patient Journey Intelligence OMOP-to-FHIR converter: enriched OMOP CDM input, three-group conversion layer (administrative, medications and devices, clinical data), US Core 6.1.0 validation, and final FHIR bundle export.

OMOP table coverage and FHIR resource mapping

The converter maps all 14 OMOP clinical source tables to 18 FHIR R4 resource types, including the high-volume domains where most open-source tools have gaps:

14 OMOP CDM source tables and their corresponding FHIR R4 resource types. Each domain requires distinct routing logic - drug_exposure alone maps to six resource types depending on clinical context.

Every Condition, Observation, Procedure, and MedicationRequest carries a reference to the correct Encounter, Patient, Practitioner, and Organization. Reference integrity holds across the full bundle.

Drug routing fidelity

drug_exposure is the highest-complexity domain in the OMOP-to-FHIR mapping. A single OMOP table must produce six different FHIR resource types based on clinical context:

• MedicationRequest - drug_type_concept_id 32838 (EHR prescription)
• MedicationAdministration - drug_type_concept_id 32818 (EHR administration)
• MedicationDispense - drug_type_concept_id 32825 (EHR dispensing)
• MedicationStatement - drug_type_concept_id 32865 or 32830 (self-report or medication list)
• Immunization - CVX vocabulary detected in drug_concept_id, overriding drug_type_concept_id
• Medication - catalog entry created for each unique drug concept, referenced by the above resources

A converter that routes all drug_exposure rows to MedicationRequest produces a patient record where vaccination history, dispensing records, and self-reported medications are indistinguishable from prescriptions or are simply absent. In our evaluation, no open-source OMOP-to-FHIR tool handled all six routing cases. The converter in Patient Journey Intelligence handles all six, preserving the clinical context of how and why each drug event was recorded.

Completeness reporting

A coverage layer counts source rows per OMOP domain and compares them to the number of exported FHIR resources. The export reports what it produced and what it could not map. Every run produces a row-level delta between source data and output bundle, per domain - the mechanism that separates a production-grade export from one that relies on spot checks.

De-identification before FHIR export

For use cases that require regulated data sharing - clinical trial submissions, research collaborations, payer exchange under a limited data set agreement - Patient Journey Intelligence de-identifies structured patient records at the OMOP layer before FHIR export. The output is a US Core 6.1.0-compliant FHIR bundle generated from de-identified data. De-identification and FHIR export run as a single pipeline, covering the full regulated sharing workflow without a manual handoff between steps.

Validated against US Core 6.1.0

US Core 6.1.0 is the U.S. implementation guide for FHIR R4. Where FHIR provides the general framework for healthcare data exchange, US Core defines the specific requirements for U.S. interoperability and regulatory compliance: which resources and data elements are required, which terminology standards apply, and how systems are expected to exchange and access data. It standardizes how patients, allergies, medications, conditions, immunizations, and laboratory results must be represented and coded. A bundle that validates against base FHIR R4 can still fail US Core validation if it does not meet these additional constraints - and because constraints change between releases, conformance to an older version does not carry forward to a newer one.

Community implementations that cover broad OMOP domains typically target US Core 4.0.0. Profile requirements changed materially between 4.0.0 and 6.1.0 - in required category slices, terminology bindings, and mandatory elements per resource type. A bundle that conforms to 4.0.0 may fail 6.1.0 validation on elements the older guide did not require.

The OMOP2FHIR converter targets US Core 6.1.0, the version used in current U.S. payer and regulatory interoperability workflows. Converter rules are encoded in versioned, testable code and re-validated against the HL7 FHIR Validator on every release - so a US Core update triggers a code change and a validation run, not a prompt-tuning cycle.

Tested across a 117-patient Synthea cohort: zero US Core 6.1.0 validation errors across all exported bundles, with full row-level coverage reporting.

Benchmark results: deterministic conversion vs. frontier LLMs

We benchmarked Patient Journey Intelligence's deterministic OMOP-to-FHIR converter against frontier LLMs on the same patient record. The input had already been processed through the Data2OMOP pipeline - the Patient Journey Intelligence component that normalizes and harmonizes data from all modalities into a unified OMOP schema - so all three approaches started from identical, structured input.

Approach	Bundle entries	Completeness	US Core validation	Errors	Warnings	Cost/patient	Deterministic
Claude Opus 4.8	140	93%	Fail	67	294	~$1.48	No
GPT-5.5	150	100%	Fail	248	303	~$1.34	No
Patient Journey Intelligence	150	100%	Pass	0	77	Fixed fee	Yes

A production FHIR export requires completeness, terminology grounding, deterministic output, and validated conformance - not just well-formed JSON.

Why LLMs are not a production substitute for deterministic conversion

LLMs can generate FHIR-shaped JSON from structured OMOP input. They are not a reliable path to US Core 6.1.0 conformance at scale. In our evaluation, GPT-5.5's second prompt iteration reached full resource count (150 of 150) but produced 248 validation errors - a 14× increase over the first run as coverage improved. Claude Opus 4.8 showed the same pattern: 67 errors on a 140-resource bundle that still missed 10 Medication catalog entries. Fixing one conformance requirement in a prompt consistently introduced failures in others. US Core 6.1.0 has hundreds of profile constraints across 18 resource types; deterministic code encodes and tests all of them. LLMs belong upstream - extracting clinical facts from unstructured notes into OMOP CDM - where their strengths align with the task.

Five criteria for evaluating an OMOP-to-FHIR converter

1. Domain coverage - Which OMOP tables does it handle? Person and Encounter are baseline. Confirm drug_exposure routing, measurement-to-DiagnosticReport handling, clinical notes, device exposures, and specimens. These are where most tools have gaps.
2. Drug routing fidelity - Does it route drug_exposure rows to the correct resource type based on drug_type_concept_id and CVX vocabulary detection? Six resource types - five medication types plus Immunization - is the complete set. Anything less produces an incomplete medication history.
3. US Core version - US Core 4.0.0 and 6.1.0 have material differences. Confirm which version the output targets and whether it has been validated against the HL7 FHIR Validator, not just targeted.
4. Completeness reporting - Does the tool report source rows vs. exported resources per domain? Without this, you are validating by spot check.
5. De-identification support - If your use case involves regulated sharing, can the pipeline de-identify at the OMOP layer before converting? Handling these separately introduces an integration seam and a compliance risk.

---

FAQ

The HL7 FHIR-OMOP Implementation Guide defines mappings exclusively in the FHIR-to-OMOP direction - ingesting clinical exchange data into a research database. There are no normative OMOP-to-FHIR mapping artifacts in the official specification. This is a gap in the standard itself, not a tooling limitation. Patient Journey Intelligence's converter fills this gap with a purpose-built, deterministic implementation validated against US Core 6.1.0.

The same OMOP input produces the same FHIR bundle every time, with resource identifiers traceable back to source rows. This is a requirement for regulated workflows: a clinical trial sponsor receiving a bundle re-exported six months later needs to be able to identify which records changed and which did not. LLM-based generation is non-deterministic by design - the same input can produce different output across runs, making reproducibility and audit trail compliance difficult.

US Core 6.1.0, the current version used in U.S. payer and regulatory interoperability workflows. The converter produces bundles validated against this version by the HL7 FHIR Validator, not self-reported conformance. Tested on a 117-patient Synthea cohort, the converter produced zero US Core 6.1.0 validation errors.

Each drug_exposure row is routed to the correct FHIR resource type based on drug_type_concept_id: MedicationRequest for EHR prescriptions, MedicationAdministration for EHR administrations, MedicationDispense for dispensing records, MedicationStatement for self-reported medications and medication lists. CVX vocabulary detection in drug_concept_id overrides the type field and routes any vaccine row to Immunization. A Medication catalog entry is created for each unique drug concept and referenced by the other resource types.

Yes. Patient Journey Intelligence de-identifies structured patient records at the OMOP layer - removing PHI from OMOP tables before conversion - and then produces a US Core 6.1.0-compliant FHIR bundle from the de-identified data. The de-identification and FHIR export steps run as a single pipeline with no manual handoff between them. This covers regulated sharing use cases including clinical trial submissions, research collaborations, and payer exchange under limited data set agreements.

The converter includes a built-in coverage layer that counts source rows per OMOP domain and compares them to the number of exported FHIR resources. Each export run produces a row-level completeness report showing the delta between what was in the source data and what was included in the output bundle, per domain. You do not need to validate by spot check.

Related pages: De-Identification · Medical Terminology · Data Governance