Written and maintained by CASRAI Editorial Board
Last updated
The PCORnet Common Data Model (CDM) is the relational database specification used across PCORnet (the National Patient-Centered Clinical Research Network) to standardize electronic health record (EHR), administrative claims, and patient-reported outcome data for multi-site comparative clinical effectiveness research and pragmatic clinical trials. Derived structurally from the U.S. Food and Drug Administration (FDA) Mini-Sentinel / Sentinel Common Data Model, the PCORnet CDM enables participating Clinical Research Networks (CRNs) to maintain patient-level data locally behind institutional firewalls while executing uniform SAS, R, and SQL analytic packages.
What Is the PCORnet Common Data Model (CDM) and How Are Its Tables Structured?
The PCORnet CDM organizes longitudinal clinical and administrative records around a person-level identifier (PATID) and an encounter-level identifier (ENCOUNTERID) across domain-specific relational tables:
| PCORnet CDM Table | Primary Key / Granularity | Clinical Content & Coding Systems |
|---|---|---|
DEMOGRAPHIC |
One row per PATID |
Birth date, sex, sexual orientation, gender identity, Hispanic ethnicity, race, and preferred language. |
ENCOUNTER |
One row per ENCOUNTERID |
Ambulatory visits (AV), emergency department (ED), inpatient stays (IP), telehealth (TH), admit/discharge dates, and DRG/discharge disposition. |
DIAGNOSIS & CONDITION |
DIAGNOSISID / CONDITIONID |
Encounter-billed diagnoses (`DIAGNOSIS`) vs. problem-list / medical-history entries (`CONDITION`) coded in ICD-9-CM, ICD-10-CM, or SNOMED CT. |
PROCEDURES |
PROCEDURESID |
Billed and ordered clinical procedures coded in CPT, HCPCS, ICD-10-PCS, ICD-9-CM Vol 3, or LOINC/SNOMED CT. |
VITAL & OBS_CLIN |
VITALID / OBSCLINID |
Height, weight, systolic/diastolic BP, BMI, smoking/tobacco status, and standardized clinical observations. |
LAB_RESULT_CM |
LAB_RESULT_CM_ID |
Quantitative and qualitative laboratory results indexed by LOINC (`LAB_LOINC`), specimen source, result value, and UCUM/standardized units. |
PRESCRIBING, DISPENSING, MED_ADMIN |
Order / Dispense / Admin ID | Separates EHR medication orders (`PRESCRIBING`, coded in RxNorm RxCUI), pharmacy fills (`DISPENSING`, coded in NDC), and inpatient administrations (`MED_ADMIN`). |
PRO_CM, IMMUNIZATION, DEATH |
Event / Patient level | Patient-Reported Outcomes (PROMIS/LOINC), CVX/NDC immunizations, and vital-status / NDI cause-of-death linkages. |
Why PCORnet Separates Prescribing, Dispensing, and Medication Administration
A core design principle inherited from the FDA Sentinel model is keeping data provenance explicit at the table level rather than collapsing disparate clinical workflows into a single exposure table. By separating PRESCRIBING (what a clinician ordered in the EHR, typically represented by RxNorm RxCUI), DISPENSING (what a community or outpatient pharmacy actually dispensed and billed, represented by 11-digit NDC along with days’ supply and quantity dispensed), and MED_ADMIN (what was administered at the inpatient bedside or infusion clinic with exact start/stop timestamps), comparative effectiveness investigators can distinguish primary medication non-adherence from confirmed inpatient exposure.
How Does PCORnet CDM Differ from OHDSI OMOP CDM and i2b2?
Many academic health centers participate simultaneously in PCORnet, OHDSI, and CTSA Accrual to Clinical Trials (ACT / ENACT), requiring data architects to understand how the PCORnet CDM differs from the OMOP Common Data Model and i2b2:
| Architectural Dimension | PCORnet CDM | OHDSI OMOP CDM | i2b2 Star Schema |
|---|---|---|---|
| Vocabulary Handling at ETL | Preserves native source codes (ICD-10-CM, CPT, HCPCS, NDC, RxNorm, LOINC) paired with explicit code-type indicator columns (e.g., DX_TYPE = '10'). |
Maps all source codes at ETL time into unified Standard Concepts (SNOMED CT, RxNorm, LOINC) while retaining *_source_value. |
Stores local or standard codes inside a central entity-attribute-value OBSERVATION_FACT table mapped via a hierarchical ontology tree. |
| Schema Structure | Domain-specific relational tables modeled closely on EHR/claims operational workflows and FDA Sentinel. | Standardized clinical event tables linked to a central relational vocabulary graph (`concept`, `concept_ancestor`). | Narrow, tall star schema (`PATIENT_DIMENSION`, `VISIT_DIMENSION`, `OBSERVATION_FACT`, `CONCEPT_DIMENSION`). |
| Medication Granularity | Three separate tables: PRESCRIBING, DISPENSING, and MED_ADMIN. |
Single unified drug_exposure table differentiated by drug_type_concept_id. |
Rows in OBSERVATION_FACT under a Medications ontology prefix. |
| Primary Query Paradigm | Centralized SAS, R, or SQL query packages distributed via PopMedNet to network DataMarts. | Standardized R analytic packages (HADES / Atlas cohort definitions) run across OMOP sites. | Federated drag-and-drop cohort count queries via the SHRINE network adapter. |
Implications of Source-Code Preservation vs. ETL Vocabulary Mapping
Because the PCORnet CDM stores diagnosed conditions and procedures in their original clinical or billing vocabulary (such as ICD-10-CM E11.9 or CPT 99214) without forcing a translation to SNOMED CT during ETL, sites avoid information loss or one-to-many mapping ambiguity during database construction. Instead, computable phenotype definitions (code lists for ICD-9-CM, ICD-10-CM, SNOMED CT, CPT, HCPCS, LOINC, and RxNorm/NDC) are defined explicitly within each study’s query package at analysis time.
How Are Distributed SAS/R/SQL Queries Executed Across PCORnet Clinical Research Networks?
To ensure that a single distributed query executes identically across dozens of heterogeneous health systems without syntax or data-type failures, every PCORnet DataMart undergoes formal Data Curation cycles coordinated by the PCORnet Coordinating Center:
- Foundational Data Curation Checks: Sites run standardized curation query packages that evaluate data model conformance (table/column names, field formats, primary/foreign key integrity), data completeness (populate rates across core domains and laboratory LOINC coverage), and data plausibility (temporal trends, age/sex distributions, and refresh latency).
- Distributed Query Dispatch via PopMedNet: Once a DataMart passes curation, study investigators distribute executable SAS, R, or SQL query packages through the PopMedNet query portal.
- Aggregate vs. Patient-Level Returns: For feasibility counts and prep-to-research queries, the script executes locally against the site’s PCORnet CDM tables and returns only aggregate summary tables with small-cell masking. For approved observational studies or pragmatic trials, sites can generate project-specific HIPAA Limited Data Set extracts (`LDS_ADDRESS_HISTORY`, real service dates) and link overlapping patient records across sites or payers using Privacy-Preserving Record Linkage (PPRL) cryptographic tokens.
Frequently Asked Questions
How does the PCORnet CDM handle both raw and standardized values in its columns?
Every coded or categorical column in the PCORnet CDM is accompanied by a corresponding RAW_* column (for example, SEX paired with RAW_SEX, or RESULT_UNIT paired with RAW_RESULT_UNIT). While the standardized column must strictly use values from the PCORnet CDM value set (or `NI` for No Information, `UN` for Unknown, `OT` for Other), the `RAW_*` column retains the exact unmapped source string from the local EHR to aid troubleshooting and curation upgrades.
Can a health system populate both PCORnet CDM and OMOP CDM from the same clinical data warehouse?
Yes. Many academic medical centers maintain harmonized ETL pipelines—or use the NCATS N3C / OHDSI cross-model mapping specifications—to populate both a PCORnet DataMart and an OMOP CDM instance from their enterprise clinical data warehouse, since both models draw from the same underlying Epic or Cerner Clarity/Caboodle source tables.
What is the relationship between the PCORnet CDM and the FDA Sentinel Common Data Model?
The PCORnet CDM was originally forked from the FDA Mini-Sentinel Common Data Model v4.0 to maintain compatibility with regulatory post-market surveillance queries while adding EHR-specific clinical tables that claims databases lack—such as VITAL, LAB_RESULT_CM, PRESCRIBING, MED_ADMIN, OBS_CLIN, and PRO_CM.
