How a patient's records become research data.
Prometheno keeps health data in OMOP CDM 5.4, the research data model used by the OHDSI community, and uses FHIR R4 to bring records in from hospital portals and to send them back out. Every record passes three quality gates, is mapped to standard vocabularies, and keeps its original code next to the standard one, so it can always be traced back.
- Canonical model
- OMOP CDM 5.4
- Exchange format
- FHIR R4
- Vocabulary
- 270K concepts · 39M mappings
- Dev dataset
- 1,000 MIMIC-IV patients
FHIR is how hospitals talk. OMOP is how research asks questions.
The format hospital portals and EHRs already speak. It describes one patient at a time, as resources: a Patient, an Encounter, an Observation. Good for moving records; awkward for asking "every patient whose creatinine rose 0.3 mg/dL in 48 hours".
A relational model built for exactly those questions, with one vocabulary for every code system. Cohort definitions written against OMOP run the same way at any institution that uses it, which is most academic medical centers doing observational research.
So Prometheno does both: FHIR at the edges, OMOP in the middle. Nothing is invented in between.
Four steps, each one checkable.
- 01Ingest
Records arrive as FHIR R4 from a patient's portal login (Fasten Connect webhook) or from an on-premises sync. Gate 0 checks the JSON is valid, the resource type is known, and hashes the payload.
- 02Quality gates
Gate 1 checks required fields and codes and grades each record A, B, C, or D. Gate 2 checks the result is a valid OMOP record. The grade is stored on the row and feeds the patient's contribution score.
- 03Vocabulary mapping
LOINC for labs, SNOMED for conditions and procedures, RxNorm for drugs, with ICD-9/10, CPT4, and NDC mapped through OMOP's own concept relationships. Both the source concept and the standard concept are kept.
- 04OMOP tables
person, visit_occurrence, measurement, condition_occurrence, drug_exposure, procedure_occurrence, observation, note. Every clinical row links to its encounter.
Where each FHIR resource lands.
| FHIR R4 resource | OMOP CDM table |
|---|---|
| Patient | person |
| Encounter | visit_occurrence |
| Observation | measurement |
| Condition | condition_occurrence |
| MedicationRequest | drug_exposure |
| Immunization | drug_exposure |
| Procedure | procedure_occurrence |
| AllergyIntolerance | observation |
| DiagnosticReport | note |
| DocumentReference | note |
Every record gets a grade, and the grade has consequences.
| Class | Meaning | What happens | Share of value |
|---|---|---|---|
| A | Complete: code, value, time, unit | Mapped to OMOP | 100% |
| B | Usable with gaps | Mapped with defaults | 70% |
| C | Incomplete | Quarantined | 30% |
| D | Invalid | Archived only | 0% |
Measured on real portal data from one test patient: labs mapped 84.9%, medications 86.9%, procedures 68.4%, conditions 13.5%. The condition number is low because most were text-only nursing diagnoses with no code. We publish the low number rather than hide it.
Out the same doors it came in.
Researchers export consented cohorts as CSV, JSON, FHIR R4 bundles, or OMOP CDM tables. The FHIR API serves Patient (including $everything), Condition, MedicationRequest, Observation, and Procedure. Patients see the same records in Ember, in plain language.
Straight answers.
- Why not just use FHIR for everything?
- FHIR is built for exchanging one patient's records. Research asks questions across thousands of patients, and OMOP CDM is the model built for that, with a single vocabulary and cohort definitions that transfer between institutions. Prometheno uses FHIR at the edges and OMOP in the middle.
- Which OMOP version?
- CDM 5.4, using the OHDSI DDL. The note table additionally carries the event links introduced in CDM 6.0, so clinical documents stay attached to the encounter and record they describe.
- What happens to a code that cannot be mapped?
- The record is kept with its original code in the source_value field and a standard concept of 0. It is never silently dropped, and it is graded lower, which lowers its share of value.
- Can a mapped record be traced back to the original?
- Yes. Every row keeps its source concept next to the standard concept, links to its encounter, and carries the quality class assigned at ingest. The payload hash from gate 0 ties it to the FHIR resource it came from.
- Can I get FHIR back out?
- Yes. The FHIR API serves Patient ($everything), Condition, MedicationRequest, Observation, and Procedure, and cohort exports can be produced as FHIR R4 bundles as well as CSV, JSON, and OMOP tables.
- What data is it developed on?
- A 1,000-patient extract of MIMIC-IV: 429,000 lab measurements, 17,600 conditions, 52,900 medication records, with the full OHDSI vocabulary of 270,000 concepts and 39 million relationships. Live portal ingestion has been tested against a sandbox EHR, not yet against production hospital systems.
- How fast is ingestion?
- One measurement, January 2026, one test patient on the batch script: 17,718 records in 15.8 seconds, about 1,120 records per second. Not a benchmark suite and not re-measured since.