Federated Common Data Model

Establishes a single, canonical data representation that all nodes must map their local schemas to. This is typically achieved through Extract-Transform-Load (ETL) or Extract-Load-Transform (ELT) processes that convert local idiosyncratic formats into the common model.

• OMOP CDM: The Observational Medical Outcomes Partnership model is the dominant standard for observational health data.
• FHIR Alignment: Modern FCDMs often align with HL7 FHIR resources for API-level interoperability.
• Mapping Logic: Local codes (e.g., proprietary lab codes) are mapped to standard terminologies like LOINC or SNOMED CT.

Enables analytical queries to be executed locally at each data node, with only de-identified, aggregated results returned to the query originator. This preserves data locality while enabling network-wide insights.

• Query Distribution: A central orchestrator dispatches the same analytical code to all participating sites.
• Local Execution: Each site runs the query against its own harmonized data in its secure environment.
• Result Aggregation: Only aggregate statistics, not patient-level data, are returned and combined.

Forces the binding of all clinical concepts to a shared, controlled vocabulary to eliminate semantic ambiguity. A diagnosis of 'Type II Diabetes' at one hospital must map to the exact same concept identifier as 'Diabetes Mellitus Type 2' at another.

• Standard Terminologies: Relies on SNOMED CT for conditions, LOINC for labs, RxNorm for medications.
• Concept Relationships: Defines hierarchical relationships (e.g., 'is a', 'has finding') between concepts.
• Vocabulary Versioning: The entire network must synchronize vocabulary updates to prevent concept drift.

Provides mechanisms to link records belonging to the same patient across different institutions without revealing their identity. This is critical for longitudinal studies where a patient's journey spans multiple providers.

• Deterministic Matching: Uses exact matches on encrypted identifiers like hashed National Insurance numbers.
• Probabilistic Matching: Uses statistical models on demographics (e.g., name, DOB) to calculate linkage likelihood.
• Privacy-Preserving Record Linkage (PPRL): Uses advanced techniques like Bloom filters to match records without sharing plaintext identifiers.

Enforces rigorous data quality checks at the point of ingestion into the common model to ensure that local mappings are technically correct and clinically meaningful before they are exposed to the network.

• Structural Validation: Checks data types, required fields, and referential integrity against the model schema.
• Semantic Validation: Verifies that mapped concepts are clinically plausible (e.g., a 'prostate cancer' diagnosis is not mapped to a female patient).
• Achilles Heel: An automated characterization tool that profiles the data to identify outliers and data quality issues.

Manages changes to the common data model over time without breaking existing queries or requiring all nodes to upgrade simultaneously. This ensures backward compatibility as medical knowledge and analytical needs evolve.

• Semantic Versioning: Uses MAJOR.MINOR.PATCH versioning to signal breaking vs. non-breaking changes.
• Deprecation Cycles: Old schema elements are deprecated over a defined period, giving sites time to migrate.
• ETL Adaptation: Local mapping scripts must be updated to accommodate new tables, fields, or vocabulary changes.

The dominant open-community data standard for observational health data. OMOP defines a person-centric relational schema with standardized vocabularies (SNOMED, LOINC, RxNorm) that map disparate source data into a consistent format. In a federated context, each hospital node transforms its local EHR into the OMOP Common Data Model, enabling distributed analytics where identical SQL or R queries can be executed across all sites without exposing raw patient records.

A patient-centric data model developed by the FDA's Sentinel Initiative for active drug safety surveillance. Unlike OMOP's research focus, Sentinel is optimized for distributed querying against large administrative claims and EHR datasets. It uses a pre-computed summary table approach where each partner site transforms data into the Sentinel CDM and executes FDA-authored parameterized queries locally, returning only aggregate results.

Two opposing data integration philosophies critical to FCDM design. Schema-on-Write transforms data into the canonical model before storage—guaranteeing query-time consistency but adding upfront ETL latency. Schema-on-Read keeps data in native format and applies the common model only at query time—offering flexibility but risking inconsistent interpretations. Most federated healthcare networks adopt a hybrid approach: schema-on-write for core clinical entities, schema-on-read for unstructured notes.

The distributed execution layer that translates a single analytical query into sub-queries dispatched to each participating node. The engine relies on the FCDM to decompose and federate queries correctly:

• Query parsing: Validates against the common schema
• Query splitting: Generates node-specific sub-queries
• Result assembly: Merges aggregate results without raw data
• Privacy budget tracking: Enforces differential privacy constraints Examples include OHDSI's Achilles and ARES tools operating over OMOP.

The highest level of interoperability where systems can exchange and meaningfully interpret data based on shared, formally defined domain ontologies. An FCDM achieves this by:

• Structural interoperability: Shared table schemas and relationships
• Syntactic interoperability: Common data formats (CSV, Parquet, JSON)
• Semantic interoperability: Standardized terminologies ensuring 'HbA1c' means the same lab test at every hospital Without semantic alignment, federated models train on incompatible feature spaces, producing unreliable global models.