An EHR data model is a structured blueprint that defines how clinical information is organized, labeled, and stored inside an electronic health record system. It specifies what types of data go where, how different pieces of information relate to each other, and what vocabulary is used to describe diagnoses, medications, lab results, and procedures. Without a shared data model, a hospital’s records and a research database might both contain the same patient’s blood pressure readings but store them in formats so different that no software can automatically compare them. The concept sounds abstract, but it sits at the center of nearly every major challenge in health IT, from sharing records across hospitals to running large-scale medical research.
Why Healthcare Data Needs a Shared Blueprint
A single patient encounter can generate dozens of data points: vital signs, a physician’s narrative notes, lab orders, imaging results, billing codes, medication lists, allergy flags, and more. Each EHR vendor might store these elements in its own proprietary schema, using its own table names, field types, and coding conventions. When two hospitals run different EHR software, their databases are effectively speaking different languages even though they hold the same kinds of clinical information. A data model imposes a common grammar so that “systolic blood pressure” means the same thing, lives in the same logical place, and is coded in the same vocabulary regardless of which system produced it.
The payoff is what the field calls semantic interoperability: not just moving files from point A to point B, but ensuring the meaning of the data survives the trip. Standardized data modeling has become one of the most important pathways toward that goal, especially as more organizations try to integrate patient data from multiple healthcare systems for coordinated care and population-level research.1PubMed Central. Standardized electronic health record data modeling and persistence: A comparative review
The Major Common Data Models
Several common data models (CDMs) have emerged to standardize how EHR data is represented for research and analytics. Each was built for a slightly different purpose, and their coverage of clinical data elements varies considerably.
The one you will encounter most often in the research world is the OMOP CDM, maintained by the Observational Health Data Sciences and Informatics (OHDSI) community. OMOP was designed for observational research on large clinical datasets. In a head-to-head evaluation using a longitudinal community registry, OMOP accommodated about 76% of the registry’s data elements and had broader terminology coverage than competing models. The Sentinel CDM, built for FDA drug safety surveillance, matched only about 37% of those same elements, while the PCORnet CDM, created for patient-centered outcomes research, matched roughly 48%.2PubMed Central. Evaluating common data models for use with a longitudinal community registry – Section: RESULTS
Those numbers do not mean Sentinel or PCORnet are inferior across the board. Each CDM was optimized for its own use case. Sentinel is lean by design because its primary job is rapid safety signal detection for drugs and devices, not comprehensive longitudinal profiling. PCORnet focuses on pragmatic clinical trials and comparative effectiveness research. And i2b2, another widely used model, was built specifically for cohort discovery, letting researchers query clinical data warehouses to find patients who match study criteria. The right CDM depends on the question you are trying to answer.
FHIR and the Language of Data Exchange
While CDMs define how data is organized for storage and analysis, FHIR (Fast Healthcare Interoperability Resources) defines how data is packaged and exchanged between systems in real time. Think of a CDM as the filing cabinet and FHIR as the postal service. FHIR breaks all exchangeable health content into discrete building blocks called resources, each defining the content and structure of a specific type of information, such as a patient record, a lab observation, or a medication request. These resources can reference each other, and they are designed to work with modern web technologies like REST APIs and standard data formats like JSON and XML.3JMIR Medical Informatics. Fast Healthcare Interoperability Resources (FHIR) for Interoperability in Health Research: Systematic Review – Section: Results
The practical result is that a hospital’s EHR can expose patient data through a FHIR API, and an app, a research platform, or another hospital’s system can consume that data without needing to understand the internal database schema behind it. FHIR has become the dominant interoperability standard in the United States, in large part because federal regulation now requires certified EHR systems to support it.
Mapping Between Models
Because CDMs and FHIR serve overlapping but different roles, health data often needs to be translated from one model to another. A hospital might store its records in a proprietary format, export them via FHIR, and then load them into an OMOP database for research. Each translation step requires mapping: matching fields, concepts, and terminologies between the source and target models.
This mapping work has traditionally been painstaking and manual. Recently, researchers have tested whether large language models can automate it. In a study evaluating ChatGPT, Gemini, and DeepSeek on tasks mapping data from various CDMs to FHIR, the results were promising but uneven. DeepSeek achieved the highest accuracy scores, with mean F1 scores ranging from 0.78 to 0.99 depending on the task. PCORnet-to-FHIR and i2b2-to-FHIR mappings were the most stable, while OMOP mappings proved harder for all three models, with the lowest mean F1 score around 0.74.4PLOS Digital Health. Enabling interoperability across disparate health data sources using Large Language Models – Section: Results Automated mapping is not yet reliable enough to run unsupervised, but the direction is clear: the tedious middle layer of data translation is a prime target for AI tools.
The ETL Pipeline
Before data can live inside a CDM, it has to get there. The process is called ETL, for extract, transform, and load. You pull raw data out of its source system, reshape it to fit the target model’s structure and vocabulary, and then load it into the destination database. For a large hospital converting years of clinical records into OMOP format, this can be a massive engineering project.
The transformation step is where the data model does its heaviest lifting. Local medication names need to be mapped to standardized drug concepts. Diagnosis codes from one classification system need to be translated to another. Date formats, units of measurement, and data types all need to conform. Researchers have developed modular, metadata-driven ETL approaches that can handle this regardless of the source data format, its version, or its clinical context.5PubMed. Towards ETL Processes to OMOP CDM Using Metadata and Modularization
One concrete example: a German research team built an ETL process that converts patient data from FHIR resources into OMOP CDM. They tested it on nearly 400,000 FHIR resources. The entire transformation ran in about a minute and achieved 99% conformance with the OMOP data quality rules on the other end.6PubMed. An ETL-process design for data harmonization to participate in international research with German real-world data based on FHIR and OMOP CDM – Section: RESULTS That speed and accuracy are encouraging, but they reflect a well-structured source dataset. Real-world ETL projects with messier inputs tend to take longer and require more manual review.
Structured Versus Unstructured Data
EHR data models primarily handle structured data: the neat, coded, tabular information like diagnosis codes, lab values, and medication lists. But a huge portion of what clinicians record is unstructured, meaning free-text notes, discharge summaries, radiology reports, and similar narrative documents. By some estimates, unstructured text contains clinical details that never make it into the structured fields.
This creates a gap. A data model built around coded fields will miss information buried in a physician’s admission notes. Researchers have shown that combining structured and unstructured data can improve predictive models; for example, one study found that extracting themes from physician admission notes and adding them to structured variables improved mortality risk prediction for ICU patients.7PubMed Central. Integrating Structured and Unstructured EHR Data for Predicting Mortality by Machine Learning and Latent Dirichlet Allocation Method
Bridging this gap requires natural language processing (NLP) tools that can read clinical text and extract structured concepts from it. One approach uses the FHIR type system as a common output format: NLP pipelines parse free-text medication lists and produce FHIR-formatted medication resources that can then be integrated with the structured data. A case study at Mayo Clinic demonstrated that this framework is feasible for normalizing both structured and unstructured medication data into a single interoperable format.8PubMed Central. Integrating Structured and Unstructured EHR Data Using an FHIR-based Type System: A Case Study with Medication Data – Section: Results
Terminology Coverage Gaps
Even within the structured portion of the EHR, not everything maps cleanly to standard vocabularies. Data models rely on terminology systems like SNOMED CT (for clinical terms) and LOINC (for lab observations) to give each concept a universal code. If there is no code for a concept, the data model cannot represent it in a standardized way.
Nursing flowsheet data illustrates the problem. Flowsheets capture detailed bedside observations like skin integrity assessments, pain scales, and fall risk scores. A recent pilot study found that only about 66% of flowsheet concepts and 56% of flowsheet values could be mapped to SNOMED CT and LOINC target codes.9JAMIA Open. Exploring common data model coverage of nursing flowsheet data: a pilot study using SNOMED CT and LOINC mapping – Section: Results That means roughly a third of common nursing observations have no standardized code waiting for them. These gaps tend to be worst in the data types that are most granular and most institution-specific, which are often the same data types that matter most for bedside care.
Data Quality and the Problem of Missing Information
A data model gives your information a consistent shape, but it cannot guarantee the information itself is correct or complete. EHR data quality is typically evaluated across several dimensions: accuracy, completeness, consistency, credibility, and timeliness.10PubMed. Data Quality in Electronic Health Records Research: Quality Domains and Assessment Methods A well-designed data model can enforce some of these through validation rules and required fields, but most quality issues originate upstream, in the clinical workflow itself. A physician who does not document a diagnosis cannot have that diagnosis captured by any model.
Missing data is a particularly thorny issue. It is rarely random. Patients who have less access to healthcare or who seek care less frequently tend to have sparser records, and this creates a pattern of missingness that tracks with socioeconomic and demographic factors. Research in an ICU setting found that missing data had a greater negative impact on disease prediction models for exactly these groups, and that realistic simulations of missing data using a medical knowledge graph showed stronger negative effects than random removal of data points would suggest.11Journal of Biomedical Informatics. Mining for equitable health: Assessing the impact of missing data in electronic health records In other words, the patients whose records are most incomplete are also the ones most likely to be harmed by algorithms trained on that incomplete data.
Patient Identity and Record Matching
Before you can organize a patient’s data into any model, you need to know which records belong to the same person. This sounds trivial until you realize that the same patient might appear in multiple systems under slightly different names, addresses, or date-of-birth entries. A master patient index (MPI) is the system that links these records together, and getting it wrong can mean merging two different patients into one record or splitting one patient into multiple fragments.
Traditional record-linkage algorithms use deterministic rules: if the name, date of birth, and social security number all match exactly, it is the same patient. But exact matches fail when data entry errors, name changes, or missing fields are involved. Machine learning approaches have shown significant improvement. In one study, ML-optimized configurations correctly detected over 90% of true record linkages as definite matches, with 100% positive predictive value, whereas the baseline deterministic approach detected none of those definite matches, only flagging them as possible matches.12PubMed Central. Optimizing Patient Record Linkage in a Master Patient Index Using Machine Learning: Algorithm Development and Validation – Section: Results The tradeoff was a small decrease in specificity, meaning a few more false positives that need human review. For most health systems, that tradeoff is overwhelmingly worth it compared to the alternative of fragmented patient histories.
Privacy adds another layer. Linking records across institutions means sharing identifying information, which raises concerns under regulations like HIPAA. Secure, privacy-preserving record linkage techniques exist that allow institutions to match records without exposing raw patient identifiers to each other, though translating these techniques into operational software has been slow.13PubMed Central. SOEMPI: A Secure Open Enterprise Master Patient Index Software Toolkit for Private Record Linkage
Database Technology Under the Hood
The choice of database technology matters more than people outside health IT tend to realize. Traditional relational databases organize data into rigid tables with fixed columns, which works well for structured queries but can struggle with the sheer variety of health data. A comparative review of database management systems for standardized EHR data found that flexible NoSQL databases, including document stores, column-family databases, and graph databases, dealt more effectively with the distinctive features of health data, especially in distributed systems where data comes from multiple sources and sites.14PubMed. Standardized electronic health record data modeling and persistence: A comparative review
This does not mean relational databases are disappearing from healthcare. Many production EHR systems still run on them, and they excel at transactional workloads like order entry and billing. But for large-scale analytics, population health queries, and research databases, the trend is toward database architectures that can accommodate semi-structured data, scale horizontally across servers, and handle the kind of complex relationships that clinical data naturally forms.
Real-World Evidence at Scale
One of the biggest practical payoffs of standardized data models is their ability to support real-world evidence (RWE) generation, using routine clinical data rather than purpose-built clinical trial data to answer research questions. CDMs make this possible by standardizing terminologies for medications, medical events, and procedures so that analyses can run across multiple data sources without site-specific custom code.15PubMed. Choosing Among Common Data Models for Real-World Data Analyses Fit for Making Decisions About the Effectiveness of Medical Products
The scale this enables is striking. In one project studying chronic kidney disease, researchers applied a CDM to harmonize secondary data from over 1.8 million patients across five data sources in three countries into a single database for rapid evidence generation.16PLoS ONE. Developing a common data model approach for DISCOVER CKD: A retrospective, global cohort of real-world patients with chronic kidney disease – Section: Results That kind of multi-country pooling would be effectively impossible without a shared data model to serve as the common language between datasets. Machine learning models built on harmonized EHR data have also shown promise; one study used OMOP-mapped data with roughly 26,000 features from EHR records to predict incident atrial fibrillation, demonstrating how a CDM can serve as the foundation for large-scale predictive analytics.17JAMA Network Open. Assessment of a Machine Learning Model Applied to Harmonized Electronic Health Record Data for the Prediction of Incident Atrial Fibrillation – Section: Methods
The Regulatory Push Toward Standardization
In the United States, data model standards are not just a technical preference. They are increasingly a legal requirement. The 21st Century Cures Act, passed in 2016, directed the Department of Health and Human Services to build the infrastructure for secure, high-quality health data exchange. One of the key outcomes is the United States Core Data for Interoperability (USCDI), a minimum baseline of data elements that must be available in federally certified EHR systems.18JAMA. A Unified Approach to Health Data Exchange: A Report From the US DHHS The USCDI is updated regularly, with each new version expanding the required data classes to include things like social determinants of health, clinical notes, and health insurance information.19PubMed Central. Quality Assessment of Public Health Datasets and Their Alignment With the United States Core Data for Interoperability (USCDI) Data Elements – Section: OBJECTIVES
This regulatory framework forces EHR vendors and healthcare organizations to adopt common data elements and exchange standards, making the data model question less optional than it used to be. Organizations that once could get by with proprietary schemas are now compelled to support standardized output, at least for the data classes USCDI covers.
Social Determinants of Health in the Data Model
EHR data models have traditionally been built around clinical and administrative information: diagnoses, labs, medications, procedures, and billing codes. But health outcomes are shaped just as powerfully by factors like housing stability, food access, education, and neighborhood safety. Incorporating these social determinants of health (SDoH) into EHR data models is a growing priority, and the results depend heavily on how the data is collected.
A systematic review found that about 79% of studies integrating SDoH into EHR-based analyses pulled the information from external data sources like census data or community surveys and linked it to patient records by geographic area. The rest extracted SDoH information from unstructured clinical notes. The distinction matters: nearly all studies using area-level SDoH data reported minimal improvement to predictive models, while studies that incorporated individual-level SDoH data showed meaningful gains in predicting outcomes like medication adherence, service referrals, and 30-day readmission risk.20PubMed Central. Social determinants of health in electronic health records and their impact on analysis and risk prediction: A systematic review Knowing that a patient lives in a low-income zip code is far less informative than knowing that specific patient is experiencing housing instability. The challenge is that individual-level SDoH data is harder to collect, harder to code, and raises additional privacy concerns.
Where Claims Data and EHR Data Diverge
Healthcare organizations typically maintain two parallel data streams: EHR clinical data and administrative claims data submitted for insurance billing. These overlap but do not match, and the differences matter for anyone relying on either source for research or analytics.
A large-scale study comparing diagnosis coding between claims and EHR data across multiple healthcare organizations found persistent gaps. The mean chronic condition count per patient-year was 4.42 in claims compared to 2.04 in EHRs. Claims captured about 54% of patient-years as having three or more chronic conditions, while the EHR captured only 29%. At the same time, the share of diagnoses captured exclusively in EHR data remained consistently low, around 3 to 4% throughout the study period.21Oxford Academic. Synergy of diagnosis coding between administrative claims and electronic health records of large patient populations across multiple healthcare organizations – Section: Results
The practical upshot is that claims data tends to paint a sicker picture because billing incentivizes thorough diagnosis coding, while EHR data captures the conditions that are clinically relevant to a specific visit but may omit chronic background conditions the physician did not actively address that day. Any data model designed for comprehensive patient profiling needs to account for which source it draws from, or ideally integrate both. The same study found that the proportion of diagnoses appearing in both sources had been rising over time, reaching 56% by 2020, before COVID-19 disrupted the trend.
International Approaches
The data model landscape looks different outside the United States. openEHR, an open standard widely adopted in Europe, Australia, and parts of Asia, takes a fundamentally different design philosophy from models like OMOP or FHIR. Rather than defining a fixed schema, openEHR separates the clinical knowledge model from the software architecture, using reusable templates called archetypes that clinicians can compose and adapt without changing the underlying database. During the COVID-19 pandemic, a Portuguese hospital used this approach to rapidly develop and integrate a patient care workflow for COVID-19, adapting to daily-changing clinical requirements by composing new archetypes rather than rebuilding database tables.22PubMed Central. OpenEHR modeling: improving clinical records during the COVID-19 pandemic
This flexibility comes with its own tradeoffs. openEHR’s archetype-based approach can be more adaptable to novel clinical scenarios, but the lack of a single fixed schema makes large-scale cross-institutional analytics harder compared to a model like OMOP, where everyone’s data sits in the same predefined tables. Increasingly, organizations are using multiple standards in tandem: openEHR for clinical data capture, FHIR for exchange, and OMOP for research analytics, with ETL pipelines connecting them. The future of EHR data modeling is less about picking one winner and more about building reliable bridges between the models that already exist.
De-identification and the Privacy Layer
Any discussion of EHR data models eventually runs into the question of privacy. Clinical data is among the most sensitive information that exists, and regulations like HIPAA in the United States impose strict rules on how it can be used, shared, and stored. For research purposes, EHR data typically needs to be de-identified before it leaves the institution that collected it.
De-identification is not as simple as stripping out names and social security numbers. HIPAA’s Safe Harbor method requires removing 18 categories of identifiers, but even then, combinations of remaining data points like rare diagnoses, exact ages over 89, and geographic details can sometimes be used to re-identify individuals. More sophisticated approaches apply statistical methods to quantify re-identification risk and ensure it stays below acceptable thresholds.23PubMed Central. Methods for the de-identification of electronic health records for genomic research The data model itself can help by separating identifying information from clinical content at the structural level, making it easier to strip identifiers during the ETL process without corrupting the clinical data that researchers actually need.