PRomop: A Decision-Ready Longitudinal Patient Health Record on the OMOP Common Data Model

Technical Summary: PRomop (PatientRecord on OMOP)

Problem Statement
Health systems and biopharma face a persistent gap between possessing patient data and acting on it. While data is often captured in standards-conformant formats (such as the OMOP Common Data Model), the structure is optimized for storage and population-level analysis rather than individual decision-making. Consequently, patient records are fragmented, and every downstream application (e.g., clinical trial matching, cohort analytics, clinical decision support) must independently reconstruct the patient's clinical state from normalized, transactional tables. This process requires repeated, error-prone derivation of complex clinical states—such as lines of therapy, current disease status, and normalized biomarkers—leading to redundant effort, inconsistency between applications, and high computational costs due to extensive table joins.

Methodology
PRomop (PatientRecord on OMOP) addresses this by introducing a two-layer architecture that separates the transactional record from a decision-ready projection, built upon the OMOP CDM 5.4 with oncology extensions.

1. Transactional Layer (Source of Truth): This layer adheres to the standard OMOP CDM, populated with data via FHIR-native ingestion and standard OHDSI mapping practices. It includes oncology-specific extensions (e.g., Episode and Episode_Event tables) to model disease episodes and treatment regimens, preserving the complete longitudinal history of clinical events.
2. Projection Layer (PatientRecord): The core innovation is a flattened, denormalized projection that collapses a patient's entire longitudinal history into a single "decision-ready" row containing 286 columns. This projection is computed once at ingestion or upon event-driven updates, rather than at query time.
   • Clinical Derivation: Unlike simple aggregation of the most recent values, this layer embeds complex clinical reasoning. It computes attributes that do not exist in raw transactional data, such as inferring the current line of therapy from unstructured notes and scattered drug exposures, and calculating composite disease-state markers (e.g., MeetsCRAB and MeetsSLiM for multiple myeloma).
   • Categories: The 286 columns span demographics, disease staging, laboratory values/biomarkers, treatment history, derived clinical flags, and behavioral/wearable data.
3. Serving Layer: All downstream applications (population analytics, trial matching, standard-of-care evaluation) query this single shared projection. This eliminates the need for each application to reconstruct patient state or perform joins against normalized tables.

Key Contributions

• Architectural Pattern: A validated pattern separating a standards-based transactional record from a flattened, decision-ready projection, enabling multiple application classes to serve from a single substrate.
• Oncology Extensions: Development of oncology-specific abstractions (episodes, therapy lines) within the OHDSI ecosystem, intended for upstream contribution to the OMOP CDM.
• Operational Evidence: Deployment across two independently governed oncology organizations (HealthTree Foundation and CancerBot), covering approximately 17,500 real patients and supporting trial matching against 19,500 actively recruiting trials.
• Clinical Reasoning Integration: Demonstration that decision-readiness requires embedded clinical reasoning (e.g., line-of-therapy inference) rather than mere data transformation, necessitating ongoing maintenance of the projection as a "living artifact."

Results

• Scalability: The system successfully operates in production for ~17,500 patients, handling fragmented, heterogeneous real-world data sources.
• Query Efficiency (Analytical): A representative 20-criterion clinical trial eligibility search that requires 27–39 joins over raw OMOP tables (scanning millions of rows) reduces to zero joins against the PatientRecord projection (scanning a single 10,000-row table). This yields an estimated effective speedup of 30×–200×.
• Query Efficiency (Empirical): A controlled benchmark on a synthetic Synthea-generated breast-cancer cohort (n=100) run on local hardware measured a mean speedup of 23.9× (95% CI: 23.3–24.4×). The eligibility screening averaged 0.92 ms using PatientRecord versus 20.7 ms using raw OMOP with standard indexing.
• Application Versatility: The shared substrate supports diverse workloads including population analytics, per-criterion trial matching, standard-of-care evaluation, and potential patient-facing conversational agents without maintaining divergent copies of patient state.

Significance and Claims
The paper positions PRomop not as a novel data model, but as a viable, deployed infrastructure pattern for turning fragmented data into actionable infrastructure. Its primary significance is economic rather than purely technical: by computing the "hard part" (clean, decision-ready clinical derivation) once, it drastically lowers the marginal cost of adding new downstream applications.

The authors emphasize that the projection is a "living artifact" requiring continuous maintenance to align with evolving clinical demands (e.g., new trial criteria). They explicitly state that the value lies in the discipline of computing clinical decision-readiness once and removing that error-prone step from every downstream team, rather than in the specific materialization technology used. The work serves as an existence proof that a flattened projection over a standards-based record can effectively bridge the gap between holding data and acting on it, while remaining conformant with OMOP and contributing back to the broader OHDSI ecosystem.

Limitations Noted by the Authors

• The empirical benchmark was conducted on a synthetic cohort (n=100) on local hardware, not the production deployments directly.
• The speedup metrics are illustrative of the pattern's effect for specific query shapes and may vary based on index coverage and hardware.
• Current validation is limited to oncology; extensions for other disease domains are not yet validated.
• The production deployments are operated by independent organizations; the authors do not hold or analyze the patient-level data, limiting the scope of reported operational evidence to deployment shape and scale rather than clinical outcomes.