- One standardised research dataset across sites instead of per-request extracts
- Data quality measured and published every load, with blocking checks
- Cohort definitions shared and re-run across sites without moving patient data
- A repeatable path to join federated network studies
Anonymised composite. Client names, identifying details and confidential figures are withheld; public facts are cited in the references.
The situation
A hospital network wanted to use its clinical data for research, quality improvement and, eventually, AI. In practice every question became a bespoke extract: a request, a queue, a data engineer writing site-specific SQL against each EHR's reporting database, and weeks of reconciliation when the sites disagreed. The same diagnosis was coded differently between sites, lab units varied, and nobody could say how complete the data was.
The network had already invested in FHIR APIs for interoperability. The question was whether those APIs could become the feed for a research platform, rather than building yet another set of point-to-point extracts.
What had to be true
- One model for analysis, so a cohort defined once runs everywhere.
- Standard vocabularies, so "type 2 diabetes" means the same concept set at every site.
- Measured quality, visible to researchers before they trust a result.
- Privacy by architecture: identifiable data stays inside each site's boundary, and collaboration happens by sharing code and aggregates.
- Something the internal team could run after hand-off, without a consultancy on retainer.
Architecture
The design used FHIR for extraction and OMOP CDM v5.4 for analysis, following the direction of the HL7 FHIR-to-OMOP implementation guide, developed by the Vulcan accelerator with the OHDSI community1.
The data flow, end to end
- ExportScheduled Bulk Data $export per site, written as NDJSON to a raw zone
- StageParse and validate resources; quarantine malformed records with reasons
- MapFHIR resources to OMOP tables; local codes to standard concepts
- CheckRun data quality checks; fail the load on blocking thresholds
- PublishSwap to a new versioned CDM schema; record lineage and vocabulary version
- AnalyseCohorts and studies run against the published version only
Bulk export was chosen over per-patient API calls because it's designed for population-level extraction, returning newline-delimited JSON files asynchronously2. The detailed pipeline patterns are in FHIR bulk data export pipelines and FHIR to OMOP architecture.
The hard part: meaning, not pipes
The pipeline engineering took less time than agreeing what the data meant. OMOP's standardised vocabularies map source codes to standard concepts in defined domains, which is what makes cross-site analysis possible5. Getting there required:
- A mapping backlog ranked by how often each unmapped local code appeared, so effort went where the data was.
- Clinician review for ambiguous mappings, recorded with reasons, rather than an engineer's best guess.
- Unit normalisation rules for laboratory measurements, agreed with lab leads.
- A policy for what to do with codes that can't be mapped: keep the source value, flag the concept as unmapped, and report the rate.
More on this in clinical terminologies and OMOP vocabularies.
Quality as a release gate
OHDSI's Data Quality Dashboard runs a large library of checks across conformance, completeness and plausibility4. The key decision was to treat a subset as blocking: if they fail, the new version doesn't publish and researchers keep using the previous one. The rest are published alongside the data, so researchers can judge fitness for their question. See OMOP data quality checks.
Researchers trust a platform that tells them what is wrong with it. Published quality results build more confidence than any feature list.
How a federated study runs
- Define cohorts in ATLAS
- Package study code
- Meta-analyse results
- Review package
- Run locally on OMOP
- Approve aggregate output
- Code repository
- Aggregate results only
- Published evidence
This is the OHDSI network model described in The Book of OHDSI3, and it is what let the network collaborate without centralising identifiable records. More in federated health analytics.
How the engagement ran
- Source system inventory
- Top research questions
- Governance and privacy model
- Bulk export and staging
- Core OMOP tables
- First quality baseline
- Vocabulary backlog
- Blocking checks
- Versioned releases
- Further sites
- Runbooks and training
- First federated study
Key decisions and trade-offs
| Decision | Alternative | Why |
|---|---|---|
| FHIR Bulk Data as the feed | Direct database extracts | Reuses interoperability investment; vendor-neutral; less coupling to EHR schemas |
| OMOP for analysis | Query FHIR directly | Standard vocabularies and the OHDSI tool and study ecosystem |
| Versioned CDM releases | Update in place | Reproducible studies and safe rollback |
| Blocking quality checks | Report-only quality | Stops bad loads reaching researchers |
| One pilot site first | All sites in parallel | Mapping lessons learned once, reused everywhere |
What I'd do again, and differently
Again: start from the research questions, not the tables, and make quality visible from day one. Differently: bring the vocabulary and clinical review effort forward. It's always the critical path, and it's the part that can't be bought.
If you're planning something similar, the healthcare data architecture page describes how I run these engagements, or analyse your challenge and bring the result to a call.
- 1FHIR to OMOP FHIR IGHL7 International (Vulcan / OHDSI)
- 2Bulk Data Access IGHL7 International
- 3The Book of OHDSIOHDSI
- 4
- 5