Healthcare Data Models: A Practical Guide to OMOP, FHIR, Star Schemas, and Everything In Between

Ask five people at a health plan how many members it had last March and you’ll get five numbers.

Not because anyone is careless. Because one person counted anyone enrolled on March 1, another counted anyone enrolled at any point in March, a third counted member months, a fourth excluded members who retroactively terminated, and the fifth pulled from a table where the enrollment span had been overwritten by a correction that arrived in June.

Every one of those answers is defensible. They disagree because the underlying healthcare data model never settled what a member month is, whether history is preserved when a record changes, or which grain the enrollment table represents.

That’s what data modeling actually is. Not diagrams. Deciding what a row means, and making that decision hold.

This guide covers the layers of a healthcare data model, why clinical and claims data resist conventional modeling, the major paradigms, the standard common data models including OMOP, how vendor EHR and payer models really look, and how to choose. It’s written for people who have to build the thing, not admire it.

What is a Healthcare Data Model?

A healthcare data model is the structured definition of how clinical, claims, and administrative data are organized: what entities exist, how they relate, what each row represents, and which codes and vocabularies give the values meaning.

Data models exist at three levels, and mixing them up is the source of a remarkable amount of wasted meeting time.

Clinical Data Model vs. Claims Data Model

Before the three levels, one split worth naming. Teams often maintain a clinical data model built around patients, encounters, observations, medications, and problem lists, and a separate claims data model built around members, enrollment spans, claim headers and lines, and paid amounts.

They describe overlapping reality from different vantage points. Clinical data knows what a clinician observed; claims data knows what got billed and paid. Neither is complete, they disagree routinely, and reconciling them is the actual work in value-based care analytics. Any serious enterprise model has to hold both and be explicit about which one wins for which question.

Conceptual, Logical, and Physical

• Conceptual answers what things exist and how they relate. Patients have encounters. Encounters generate diagnoses, procedures, and claims. No technology, no field names. One whiteboard.
• Logical answers what attributes each entity carries, what the keys are, what the cardinality is, and what the grain of each table is. Still platform-independent, but precise enough to argue about.
• Physical answers how it’s implemented: table definitions, data types, partitioning, indexes, clustering keys, file formats.

Most healthcare data projects fail at the logical layer. The conceptual model is obvious and the physical layer is a solved engineering problem. The hard part is deciding whether a row in your encounter table is a visit, a claim, a claim line, or an episode of care, and then defending that decision when someone’s report doesn’t tie.

Grain is the Decision That Matters Most

The grain of a table is what one row represents. Get it wrong and every downstream number is wrong in a way that’s difficult to detect and expensive to fix.

Healthcare grain decisions that reliably cause trouble:

• Claim versus claim line. A single claim can carry dozens of lines with different procedure codes, dates, and amounts. Summing at the wrong level double counts or loses detail.
• Encounter versus visit versus episode. A hospital stay is one admission, many daily charges, several departments, and possibly multiple claims. An episode of care might span months.
• Member month. The workhorse grain of payer analytics, and the one most often defined inconsistently across teams.
• Lab result versus lab panel. A CBC is one order and roughly a dozen results.
• Medication order versus dispense versus administration. Three different events, three different tables, three different truths about whether the patient took the drug.

Write your grain definitions down in plain language, put them in the table description, and enforce them with tests. This is unglamorous and it prevents more incidents than any tooling decision you’ll make.

Why Healthcare Data Modeling is Harder than Other Domains?

People arriving from retail or finance often assume healthcare is just another transactional domain with worse acronyms. It isn’t. Several properties genuinely differ.

1. Time is Complicated

Healthcare data is bitemporal. Every fact has a time when it happened and a separate time when the system learned about it. Claims arrive weeks or months after service and get adjusted, reversed, and resubmitted. Diagnoses get added retroactively. Enrollment terminates backdated to the first of a prior month.

A model that stores only current state cannot answer “what did we know on the day we made that decision?” For risk adjustment, quality reporting, and any audit defense, that question is not optional. Claims runout and completion factors exist precisely because of this.

2. The Same Fact Arrives From Multiple Sources and They Disagree

A patient’s diabetes diagnosis might appear in a claim, a problem list, an encounter diagnosis, an HCC submission, and a lab value implying it. These will conflict on date, specificity, and existence.

Your model needs a deliberate answer to source-of-truth conflicts, and “whichever loaded last” is not an answer.

3. Meaning Lives in Vocabularies, Not Columns

A value of 250.00 means nothing without knowing it’s ICD-9. The codes carry the semantics:

• ICD-10-CM for diagnoses, ICD-10-PCS for inpatient procedures
• CPT and HCPCS for professional and outpatient procedures
• SNOMED CT for clinical findings, the terminology most EHRs use internally
• LOINC for labs and observations
• RxNorm for medications, NDC for dispensed products, CVX for vaccines
• UB-04 revenue codes, place of service, DRG, taxonomy codes on the administrative side

A healthcare data model without a terminology strategy is a pile of strings. You need code system identifiers stored alongside every code, a mapping layer, and versioning, because ICD-10-CM changes annually and value sets change with measure years.

4. Identity is Not Given

There’s no national patient identifier in the United States. Patients arrive with different name spellings, addresses, and member IDs across sources. Your model needs an enterprise identifier, a crosswalk to source identifiers, and an honest accounting of match confidence. Provider identity is nearly as messy, with NPIs, TINs, group affiliations, and location hierarchies that change constantly.

5. Attributes Change and History Matters

Patient address, primary care attribution, plan enrollment, provider group, risk score. All of these change over time, and analytics almost always needs the value as of a point in time rather than today’s value. That means slowly changing dimensions, effective date ranges, and the discipline to use them.

6. Regulation Shapes the Schema

HIPAA minimum necessary, 42 CFR Part 2 for substance use disorder records, and state laws on behavioral health, HIV status, and reproductive health all mean some data classes need separate handling, segmented access, and provenance tracking. This is a modeling requirement, not just a security configuration.

The Main Healthcare Data Modeling Paradigms

Four approaches account for most of what you’ll encounter. They are not mutually exclusive, and mature organizations use several in layers.

1. Normalized (Third Normal Form)

The Inmon-style approach: an integrated, normalized enterprise warehouse feeding purpose-built marts.

Good for: integration integrity, avoiding update anomalies, a single defensible source layer. Bad for: query performance and analyst comprehension. A question that touches patients, encounters, diagnoses, and providers can require a dozen joins.

2. Dimensional Modeling (Star Schema)

The Kimball approach, and still the most common shape for a healthcare data warehouse serving BI and reporting.

Facts are the measurable events. Dimensions are the descriptive context.

• Fact tables: claim lines, encounters, lab results, medication dispenses, member months
• Dimensions: patient, provider, facility, date, plan, diagnosis, procedure, coverage

A star schema is fast, comprehensible, and works well with BI tools. Analysts can read it without a data engineer translating.

Its weakness in healthcare is that conformed dimensions across sources are genuinely hard, and a rigid star can be painful to extend when a new source arrives with a different shape.

3. Data Vault 2.0

Hubs for business keys, links for relationships, satellites for descriptive attributes and history.

Data Vault fits healthcare unusually well, and it’s underused. It’s built for exactly the conditions healthcare imposes: many sources describing the same entities, constant schema change, full history retention, and auditability by design. Satellites keep every source’s version of the truth with load timestamps, so you never lose the ability to reconstruct what you knew and when.

The cost is complexity and row counts. Nobody queries a raw vault directly. You build dimensional marts on top of it.

The pattern that works for most large organizations: raw landing, then Data Vault for integration and history, then star schemas for consumption.

4. One Big Table and Wide Denormalized Structures

For machine learning and some analytics, a wide patient-level or patient-period-level table with hundreds of engineered features beats any normalized structure. Cheap columnar storage made this practical.

Good for: model training, feature reuse, fast iteration. Bad for: as a source of truth. Treat wide tables as derived outputs with defined lineage, never as the place data lives.

Medallion Layers Are Not a Data Model

Bronze, silver, gold is a layering convention, not a modeling paradigm. It tells you nothing about grain, keys, or history. Teams that adopt medallion terminology and skip the modeling work end up with three copies of an unmodeled mess. You still have to decide what a row means in the gold layer.

Approach	Best at	Weakest at	Typical healthcare use
Normalized 3NF	Integration integrity	Query performance	Source-aligned staging
Star schema	BI, reporting, clarity	Handling new sources	Marts for quality, finance, utilization
Data Vault 2.0	History, audit, many sources	Complexity, sprawl	Integration layer under marts
Wide tables	ML and feature reuse	Being a source of truth	Risk models, propensity scoring
OMOP CDM	Portable research, RWE	Operational reporting	Observational studies, network research

Common Data Models in Healthcare

A common data model is a published, standardized schema that multiple organizations adopt so that analytic code written once runs anywhere. This is a different goal from a warehouse designed for your own reporting, and it’s why common data models look strange to BI teams.

1. OMOP CDM

The OMOP Common Data Model, maintained by the OHDSI community, is the dominant common data model for observational research and real-world evidence. Version 5.4 is the widely deployed release.

Its structure is person-centric and event-oriented:

• person, observation_period, death
• visit_occurrence and visit_detail
• condition_occurrence, procedure_occurrence, drug_exposure, device_exposure
• measurement for quantitative results, observation for everything else
• note and note_nlp for unstructured text and its extraction
• payer_plan_period and cost for the financial side
• Vocabulary tables: concept, concept_relationship, concept_ancestor, concept_synonym

OMOP’s real contribution is the vocabulary layer, not the table layout. Source codes get mapped to standard concepts with a single concept_id, and the concept_ancestor table encodes hierarchy so a query for “any diabetes” resolves without hand-listing codes. That is what makes analytic code portable across institutions.

Choose OMOP when you’re doing observational research, participating in a research network, or generating real-world evidence, and you want to run standardized analytics packages.

Don’t choose OMOP when your primary need is operational or financial reporting. The ETL is substantial, the mapping work is ongoing, and the model deliberately discards source detail that your finance team will ask about.

2. FHIR as a Data Model

FHIR is an exchange model, not an analytics model. This distinction gets blurred constantly and it causes real damage.

FHIR resources are optimized for API request and response: nested JSON, references between resources, extensions everywhere. That’s excellent for moving one patient’s data and painful for aggregate analysis. Querying “average A1c by provider” across a raw FHIR store means flattening deeply nested documents at scale.

The practical pattern:

• Ingest with FHIR, especially via Bulk FHIR export to newline-delimited JSON
• Land the raw resources for provenance
• Flatten and model into dimensional or OMOP structures for analysis

Regulatory pressure is pushing more organizations into FHIR ingestion whether they planned for it or not. TEFCA has committed to FHIR-based exchange, and CMS payer API requirements including the prior authorization APIs run on FHIR implementation guides. Building the FHIR-to-analytics flattening layer is fast becoming standard infrastructure rather than a special project.

3. i2b2

An older star schema built around a single massive observation_fact table with a flexible concept dimension. Widely deployed in academic medical centers for cohort discovery. Its generic fact design makes it simple to load and awkward to query precisely.

4. PCORnet and Sentinel CDMs

• PCORnet CDM supports the national patient-centered research network, with a relational structure closer to claims and EHR source shapes than OMOP’s concept-normalized approach.
• The Sentinel Common Data Model, developed for FDA’s active surveillance program, is built for distributed queries against claims-heavy data.

Both are less abstracted than OMOP, which makes ETL easier and cross-network semantic consistency weaker.

5. openEHR

A dual-model approach separating a stable reference model from clinical content defined in archetypes and templates. Strong clinical expressiveness and much wider adoption in Europe than in the United States.

USCDI Is a List, Not a Model

The United States Core Data for Interoperability specifies which data classes and elements must be exchangeable. It does not specify a schema. Certified health IT was required to support USCDI v3 as of January 1, 2026, with later versions in the pipeline. Treat USCDI as a coverage requirement to satisfy, not a model to implement.

6. CDISC SDTM and ADaM

For regulated clinical trials, SDTM standardizes collected data and ADaM standardizes analysis-ready datasets for submission. Entirely separate lineage from the observational world, and mandatory if you’re filing with FDA.

EHR and Payer Data Models in the Real World

Standards are what you read about. Vendor models are what you actually query.

1. EHR Data Models

Epic runs on Chronicles, a hierarchical database, and exposes analytics through Clarity, a normalized relational extract with thousands of tables, and Caboodle, a dimensional warehouse. Most Epic analytics work happens in Caboodle, with Clarity for detail Caboodle doesn’t carry. Both are Epic’s schemas, not yours, and both change with upgrades.

Oracle Health (Cerner) exposes Millennium data through its own reporting structures and the HealtheIntent population platform.

MEDITECH provides the Data Repository as its relational reporting layer.

Every one of these is a vendor-defined physical model. Building your enterprise model directly on vendor table structures couples your analytics to their release cycle. Land it, then map it into your own model.

2. Claims and Payer Data Models

Payer data arrives shaped by EDI transactions rather than clinical workflow:

• 837 for claims submitted, 835 for remittance
• 834 for enrollment and maintenance
• NCPDP standards for pharmacy claims
• 270/271 for eligibility inquiry and response

A claims data model typically centers on:

• Claim header and claim line facts, at explicit and separate grains
• Enrollment spans with effective dates, plan, product, and line of business
• Provider dimension with NPI, TIN, specialty, and network status as of service date
• Member dimension with slowly changing attributes
• Member month as the denominator grain for utilization and cost metrics

Layered on top sit the analytic constructs that drive the business: HCC and RAF calculations, HEDIS value sets, Star measure logic, episode groupers, and risk-adjusted benchmarks. These are not raw data. They’re derived models with their own versioning problems, because measure specifications change every year and last year’s numbers must remain reproducible.

Modeling for AI and Machine Learning

This is where most published guidance on healthcare data models is a decade out of date.

Traditional warehouse modeling assumed a human wrote a query and read a number. Increasingly the consumer is a model, and that changes requirements.

• Unstructured text becomes first-class. Clinical notes, pathology reports, and imaging narratives carry information that never made it into a coded field. Your model needs a place for documents, their metadata, and the extractions derived from them, with links back to the source. OMOP’s note and note_nlp tables were an early version of this idea.
• Vector storage sits beside relational, not instead of it. Embeddings for retrieval, with the relational model providing filters, permissions, and provenance. Retrieval that can’t filter by patient, date range, and access rights is not usable in healthcare.
• Point-in-time correctness becomes a hard requirement. Training a model on data that leaked future information is the most common serious error in healthcare ML. Your model must be able to reconstruct feature values as of a prediction date. Bitemporal design pays for itself here.
• Feature definitions need governance. The same feature computed two ways in two projects produces two models nobody can reconcile. A semantic or metrics layer with versioned definitions is the fix.
• Provenance becomes a compliance artifact. When a model output influences a clinical or coverage decision, you need to show which data produced it. That’s lineage down to the row, which is much easier if you kept history in the first place.

The organizations doing this well are not the ones with the newest platform. They’re the ones whose data model preserved history and provenance before anyone asked them to.

How to Choose a Healthcare Data Model

Start from the use case, not the technology.

If your primary need is	Build toward
Operational and financial reporting	Dimensional star schemas
Multi-source integration with full audit history	Data Vault, then dimensional marts
Observational research and real-world evidence	OMOP CDM
Data exchange and regulatory APIs	FHIR, with a flattening layer for analytics
Regulated clinical trial submission	CDISC SDTM and ADaM
Machine learning and risk models	Wide feature tables derived from a modeled core
Quality measurement and Stars	Dimensional marts plus versioned measure logic

Three principles that hold regardless of choice:

1. Separate ingestion, integration, and consumption. Land raw and immutable, integrate with history, then serve purpose-shaped marts. Trying to do all three in one layer is the most common architectural mistake.
2. Never model directly on a vendor schema. Land it, map it, own your model.
3. Write the grain and the source-of-truth rules down. In the table description, in the docs, in the tests. Ambiguity here compounds forever.

Common Healthcare Data Modeling Mistakes

• Overwriting history. Updating a patient’s attributed PCP in place destroys your ability to reproduce last quarter’s report. Use effective dating.
• Storing codes without code systems. A bare code column is a future incident.
• Mixing grains in one table. Header and line data in a single fact table guarantees double counting.
• Treating a common data model as a warehouse. OMOP is not a reporting layer. Standing one up and pointing finance at it disappoints everyone.
• Modeling for today’s source list. A new payer feed, a practice acquisition, or an EHR migration will arrive. Design for the second and third source.
• Skipping identity resolution. Duplicate patients silently corrupt every rate, ratio, and cohort count.
• Ignoring completeness lag. Reporting recent claims periods without runout adjustment produces numbers that keep changing after publication.
• Letting derived metrics live in BI tools. Measure logic buried in a dashboard is unversioned, untestable, and unfindable.

Frequently Asked Questions

What is a healthcare data model?

A structured definition of how clinical, claims, and administrative data are organized: which entities exist, how they relate, what a single row represents, and which code systems give values meaning. It exists at conceptual, logical, and physical levels.

What is the OMOP common data model?

A standardized schema and vocabulary maintained by the OHDSI community for observational health research. It normalizes source codes into standard concepts so analytic code written at one institution runs at another. Version 5.4 is the widely deployed release.

Is FHIR a data model?

Yes, but an exchange model rather than an analytics model. FHIR defines resources and an API for moving data between systems. For aggregate analysis, organizations typically ingest FHIR, land it raw, then flatten it into dimensional or OMOP structures.

What is the difference between OMOP and FHIR?

Purpose. FHIR moves data between systems using nested resources over a REST API. OMOP stores data for population analysis in flat, concept-normalized tables. Many organizations use both: FHIR to acquire, OMOP to analyze.

Should I use a star schema or Data Vault for healthcare data?

Both, in layers. Data Vault handles multi-source integration and history well, which suits healthcare’s constant schema change and audit requirements. Star schemas serve reporting and BI. The common pattern is a vault integration layer with dimensional marts on top.

What is grain in healthcare data modeling?

What one row represents. Claim versus claim line, encounter versus episode, member month, lab result versus panel. Grain errors are the leading cause of numbers that don’t tie.

Why is healthcare data modeling so difficult? Bitemporal data with retroactive corrections, the same fact arriving from conflicting sources, meaning encoded in multiple changing vocabularies, no national patient identifier, attributes that change over time, and regulatory constraints that require segmented handling of specific data classes.

Where to Start

If you’re standing up or rescuing a healthcare data model, three moves produce disproportionate returns.

Write down the grain of your five most-used tables, in one sentence each, and circulate it. You will find disagreement immediately, and finding it now is much cheaper than finding it during an audit.

Pick one metric that multiple teams report differently and trace it to the model. Member months, readmission rate, PMPM, gap closure rate. The trace will expose exactly which modeling decisions were never made, and it makes the case for the work better than any architecture diagram.

Decide your history strategy before your next source goes live. Effective dating, satellites, snapshots, whichever fits. Retrofitting history onto a model that overwrote it is the most expensive remediation in this domain, and it’s the one nobody budgets for.