Empowering patients, enabling clinicians, and unlocking the full potential of healthcare data

When Your Health Story Lives in Four Systems

When I was diagnosed with follicular lymphoma, my medical information proceeded to be scattered across four healthcare systems and three countries.

My initial labs were done in France, follow-up appointments with my private GP in Scotland, diagnostic work and treatment through NHS Scotland, and then a consultation request with MD Anderson Cancer Center in Houston.

Each institution held part of my story — but none had the complete picture.

When MD Anderson asked for my records, the NHS Subject Access Request could only produce DICOM images of CT and PET-CT scans. There was no structured electronic data for labs, diagnostics, or biomarkers. Despite everything being "digital," the information couldn't actually move.

Even if each provider had given me a data file, I still would have had to collate and interpret dozens of test results, medications, and reports to create a consistent record. Which version of my labs should be considered the truth? How could I ensure continuity of care across systems that don't talk to each other?

That experience crystallized something for me: we need a patient-controlled, centralized repository for health data — one that aggregates structured information from all sources, so both patients and clinicians can make informed, confident decisions.

The Missing Link: A Home for Patient Data

The healthcare industry has spent years working on data interoperability — and progress has been real. The FHIR standard (Fast Healthcare Interoperability Resources) has made it easier for systems to talk to each other.

But FHIR doesn't define where data should live or how it should be assembled into a single, coherent patient record. It standardizes the pipes — not the container.

That's why, despite decades of investment, patients still find themselves chasing PDFs, CDs, or portals that only hold fragments of their health history.

Regional Health Information Exchanges (HIEs) attempt to solve part of this problem, but they remain fragmented by geography and policy. There's an opportunity now — especially with modern privacy controls and cloud architecture — to design something strategic, global, and patient-centric from the ground up.

At HealthKey, we're deeply interested in consuming this kind of unified data repository (with patient authorization) for clinical trial matching. Having a trustworthy, structured record would make it vastly easier to match patients to precision medicine studies quickly and safely.

The Harvard-Radcliffe Initiative

Last week, I joined a Harvard Radcliffe Institute working seminar on building a long-term patient data repository — an effort led by Yuri Quintana, who assembled an extraordinary group of experts in clinical informatics, patient advocacy, and data standards.

Several patients shared their personal experiences. I hadn't expected to tell mine, but Yuri invited me to speak about the challenges of assembling my fragmented records.

The most powerful story came from Betsy Lowe, a mother who maintains Excel spreadsheets to curate the medical histories of several of her children living with chronic illness. Betsy's experience drove home how far we still have to go — and how urgently we need tools that make this easier.

Among the participants were:

• Alexa McCray, creator of clinicaltrials.gov, the first clinical trials registry, decades ahead of its time
• Dave deBronkart ("e-Patient Dave"), a pioneer in patient data rights
• Cait Desroches, who for years has steered the OpenNotes initiative to the success it is today

Their presence underscored the goal: this must be a patient-first repository — something that gives individuals agency over their complete health record and enables clinicians to provide better, safer care.

What a Patient-Centered Repository Could Enable

Our workgroups identified two key principles:

1. Patient Control of Data Creation

• Patients can grant write access to their providers.
• They can collate and reconcile records from multiple sources.
• They decide which version of overlapping data to treat as authoritative.
• They can enrich their record with lifestyle, environment, and wearable data (diet, exercise, Apple Watch, Fitbit, etc.).

2. Patient Control of Data Usage

• Patients choose who can see what — providers, caregivers, peers, or navigators.
• They can delegate access rights to a trusted clinician or family member.

Why It Matters

Imagine a world where your entire medical record simply exists — securely updated by each provider through FHIR feeds, automatically organized, and available when you need it.

For Patients

• No more managing binders or chasing records.
• A complete view of your history, medications, and results.
• Control over what's shared and with whom.
• The ability to opt in to share anonymized data for research — even earning royalties when your data contributes to discoveries.

For Clinicians

• More complete data at the point of care.
• Better diagnostic accuracy and continuity.
• Less administrative overhead.
• Stronger patient relationships built on transparency.

For Researchers and AI Developers

• High-quality, structured data that accelerates discovery.
• Ability to train models responsibly using consented, representative datasets.
• When data is complete, AI assistants and navigators can meaningfully support patients and clinicians alike — from interpreting lab results to identifying trial matches or care pathways.

Barriers We Must Overcome

The hardest problems are not technical — they're institutional and cultural. We identified several major barriers:

1. Provider trust: Clinicians hesitate to use data from other institutions (or patients) for liability reasons. Potential fix: regulations that recognize verified, patient-controlled repositories as trusted sources.
2. Data ownership: Some institutions resist sharing data for fear of losing patients. Patient-centered systems can strengthen continuity, not weaken it.
3. Billing and incentives: Providers may prefer repeating diagnostics they can bill for. Solution: policy incentives for data reuse and interoperability compliance.
4. Error correction: Institutions are reluctant to correct legacy data. Solution: feedback mechanisms that log corrections transparently and return them to source systems.

Our collective answer to skepticism that "patients aren't competent to manage their own records" was simple: if not the patient — who?

Defining Success: SMART Goals

We converted our vision into specific, measurable goals. Among them:

• Patient signups: 13 million within five years of launch (about 5% of U.S. adults — a proven tipping point for adoption).
• Engagement: Each user logs at least one session per year within two years.
• Referrals: 5% of users refer peers within two years.
• Satisfaction: Two-thirds of users rate the service as valuable.
• Institutional participation: 20% of FHIR-adopting providers push data within five years.
• Carer enablement: 5% of users have linked caregiver accounts.

Speaking to Stakeholders

Different audiences have different motivations, and we defined simple, focused messages for each:

• Motivated Patient: "Optimize your health with the full picture of your data. Choose what's shared, to whom, and for what."
• Caregiver: "Helping someone manage their health is hard enough. We simplify the information part."
• Clinician: "Caring for the whole patient just got easier."
• Hospital: "More complete data, better outcomes."
• Funder (Tech/Data): "Accelerate an ecosystem built on high-quality, consented patient data."
• Funder (Social Good): "Empower patients and families to take charge of their health."

Milestones Toward Delivery

We proposed a phased roadmap — each milestone is immediately useful and adds tangible value over the previous one:

1. FHIR-Importing Mobile App: A smartphone app that aggregates data from providers via FHIR push feeds. Data can live only on the device if patients prefer.
2. Web-Based Portal: Adds a hosted version for patients comfortable with cloud access.
3. Patient-Provided Data: Support for device data, PDFs, and manual uploads.
4. AI Assistant Integration: An LLM-powered assistant helps patients structure, reconcile, and correct data.
5. Bidirectional Data Exchange: Patients can send updates or corrections back to providers (optional for acceptance).
6. Anonymized Data Sharing: Patients can opt to share de-identified data for research — and receive royalties when used by for-profit entities, funding sustainability for the non-profit repository.

Building It: Open and Collaborative

Such a repository should be built and governed by a trusted non-profit, ideally within the Harvard DCI Network.

At HealthKey, we've already begun developing a foundation for this through our open-source project PRomop — available on GitHub.

PRomop extends the OMOP schema to include richer genomic data (such as assay information) and provides a flattened table structure optimized for clinical trial matching and predictive modeling. It's fully open source and designed for community collaboration through the DCI Network.

While our initial use case is trial matching, the schema supports broader applications: building predictive models for standard-of-care outcomes, powering AI research, and supporting long-term population health studies.

The Road Ahead

A unified, patient-controlled data repository isn't just a technical challenge — it's a moral and practical imperative. Every day, patients lose time, clarity, and even treatment opportunities because their data lives in silos.

We now have the standards, the technology, and the collective will to fix that. What we need next is collaboration — across patients, clinicians, technologists, and policymakers — to make it real.

The future of healthcare data belongs to those who share it responsibly. Let's build the infrastructure that makes that possible.

What a unified, patient-centric data model could look like for breast cancer trial matching

We talked in a recent post about centralized patient data repositories. Let's dig deeper into what such a common repository might actually look like. CancerBot, as a clinical trial matching product, is deeply focused on the structured data required for accurate clinical trial eligibility. That scope gives us a concrete testbed for assessing whether a given data schema is sufficient for real-world matching.

Of course, a broader ecosystem will eventually need far more: patient-generated health data, imaging, genomics beyond trial eligibility, quality of life metrics, wearable feeds, and more. But for now, the breast cancer trial-matching use case gives us a clean, bounded first iteration. Future versions will extend naturally to follicular lymphoma, multiple myeloma, and other blood cancers supported by CancerBot.

With that in mind, here is what a patient information schema could look like for breast cancer clinical trial matching.

1. Core Demographics

The foundation of any patient schema begins with the universal identifiers and sociogeographic context that trials commonly use in eligibility logic:

• Age, gender, ethnicity
• Country, region, postal code
• Latitude/longitude (for distance-to-trial-site calculations)

These may seem mundane, but they have real implications. Many trials restrict enrollment to specific countries or regions. Others score travel burden or require reasonable proximity to a clinical site. Even ethnicity can sometimes influence eligibility when germline risk or pharmacogenomic variants are relevant.

2. Physiologic Measurements

Real, quantifiable values that describe the patient's physiology — almost always required for baseline safety assessments:

• Height, weight, BMI
• Blood pressure, heart rate
• Ejection fraction (cardiac function)
• QTc interval (cardiac conduction risk)
• Pulmonary function test summaries

These values ensure a patient can safely receive the investigational therapy. QTc is crucial for certain targeted therapies; ejection fraction is mandatory for HER2-directed therapy trials.

3. Clinical Status

This category describes the cancer itself and the patient's functional ability to undergo treatment:

• Disease (breast cancer subtype or diagnosis code)
• Stage (AJCC staging)
• ECOG and Karnofsky performance status

This is where most trial logic starts. Nearly every breast cancer trial is written around stage (e.g., metastatic vs. early) and functional status (e.g., ECOG ≤ 1).

4. Medical History

Trial protocols depend heavily on past and existing health conditions, because comorbidities directly affect safety:

• Other active malignancies
• Pre-existing conditions (cardiac, autoimmune, neurologic)
• Neuropathy grade
• HIV, hepatitis B/C status
• Prior interstitial lung disease (ILD), prior pneumonitis, and ILD grade
• Geographic and infectious exposure risks

Breast cancer trials increasingly exclude patients with prior ILD or pneumonitis due to the pulmonary toxicity risks of antibody–drug conjugates (ADCs). Viral infection status remains essential for immunotherapy safety.

5. Hematology, Renal, and Hepatic Diagnostics

The backbone of systemic therapy eligibility — these values appear in nearly every inclusion/exclusion section. The schema must store not only the values but also the units, since matching logic commonly breaks when unit conversions are missing:

• Hematology (CBC): ANC, platelets, WBC, RBC, hemoglobin
• Renal function: creatinine clearance, serum creatinine, eGFR
• Hepatic function: AST, ALT, ALP, total and direct bilirubin, albumin
• Electrolytes & minerals: serum calcium

6. Treatment History

Breast cancer therapy is highly line-dependent; trial matching must know exactly what a patient has received and whether they responded:

• Treatment lines: first-line, second-line, later-line therapies with dates and outcomes (PR, PD, intolerant)
• Supportive care: bisphosphonates, steroids, G-CSF — important but not counted as systemic lines
• Disease course: relapse count, remission duration
• Refractory status: endocrine-refractory, CDK4/6-refractory, ADC-refractory
• Safety & washout: washout duration, persisting toxicity grade (per CTCAE)
• Prior ADC exposure — a major eligibility gate for modern trials

Without a structured, accurate treatment history, matching is guesswork.

7. Behavioral & Reproductive Safety Factors

Often overlooked, but central to trial safety and compliance:

• Consent & cognitive status: consent capability, mental health considerations, caregiver availability
• Reproductive safety: pregnancy or lactation, pregnancy test results, contraception use
• Substance use: tobacco, alcohol or other substances
• Exposure risk: geographic exposure (TB, fungal diseases), occupational exposure (healthcare, lab, industrial toxins)

Putting It All Together

What emerges is a coherent, structured, interoperable patient information schema that supports breast cancer trial matching at a level of precision that older approaches simply cannot achieve. A schema like this:

• Captures the full clinical picture needed for safe and accurate matching
• Maps cleanly to OMOP and FHIR
• Is extensible to additional cancers
• Can support broader patient-data repositories beyond trial matching
• Enables true eligibility filtering — not guesswork or vignette-based ranking

We have discussed earlier a vision for centralized patient database repositories. One of the many use cases for a truly comprehensive common patient record is doing the precision trial matching that CancerBot performs. So we built PRomop, which builds on the solid foundation of OHDSI OMOP's relational database schema but adds things necessary for true precision clinical trial matching, and starts to add many of the other things needed by other use cases such as evaluating standard of care options and capturing a truly global picture of the patient. The "PR" in PRomop stands for "Patient Record". This post presents a summary of the architecture of PRomop and describes how it can be used as a solid underlying patient data store for other use cases you may have in mind.

Why Start With OMOP?

The Observational Medical Outcomes Partnership (OMOP) Common Data Model, stewarded by OHDSI, is the de facto standard for normalizing observational health data. It gives us a battle-tested relational schema, a rich set of standardized vocabularies (LOINC, SNOMED CT, RxNorm, ICD-O-3), and an enormous ecosystem of analytical tooling. Starting from OMOP means we inherit interoperability with that entire ecosystem for free — any cohort analysis, phenotyping, or population-level study that runs on OMOP runs on PRomop.

But OMOP was designed primarily for retrospective, population-scale research. It does a beautiful job of answering questions like "how do patients on drug X compare to patients on drug Y over time?" What it doesn't do quite so gracefully is answer the question CancerBot has to answer every day: "Given everything we know about this specific patient, right now, which clinical trials could they qualify for, and which would be best for them?"

That question is transactional (it has to be answered in seconds, not hours), longitudinal (it depends on the complete arc of the patient's disease and treatment), and precision-oriented (it turns on dozens of specific biomarker, staging, and behavioral attributes that OMOP doesn't surface directly). PRomop is our attempt to make OMOP answer that question without breaking its compatibility with the broader OMOP world.

The Architectural Idea

PRomop is organized around a simple principle: all clinical data lives in standard OMOP tables, using standard vocabularies. We don't create a parallel universe of custom tables for biomarkers, treatment lines, or social factors. Instead:

• Biomarkers (ER, PR, HER2, PD-L1, Ki-67, genetic mutations) go in the standard Measurement table, keyed by LOINC concepts.
• Lab values (hemoglobin, creatinine, calcium, AST/ALT, and the rest) go in Measurement, also keyed by LOINC.
• Vital signs and anthropometrics go in Measurement.
• Social determinants and health behaviors go in Observation, keyed by SNOMED CT.
• Cancer staging — T, N, M, stage group, grade, primary site, histology — goes in Observation with ICD-O-3 and SNOMED concepts, using the CDM v6.0 observation_event_id to link back to the underlying ConditionOccurrence.
• Treatment response goes in Observation with SNOMED concepts.
• Treatments go in DrugExposure, and treatment lines are derived from drug exposure patterns rather than stored as a separate denormalized entity.
• Cancer episodes use the official OMOP Oncology Extension: Episode, EpisodeEvent, CancerModifier, Histology, StemTable.

The net effect is that every clinical fact in PRomop is readable by any off-the-shelf OMOP tool, and any dataset already in OMOP can be loaded into PRomop without transformation. The project has been explicitly refactored to remove earlier non-standard extension tables in favor of standard tables with the right vocabulary concepts.

The PatientRecord Projection

This is the workhorse of PRomop for transactional use cases. PatientRecord is a wide, denormalized, single-row-per-patient view — over 100 fields — that aggregates the information a trial-matching engine actually needs to reason about a patient, pulled from the standard OMOP tables underneath. It is explicitly not a new place to store clinical data. Nothing lives only in PatientRecord. It is a materialized, research-friendly projection populated by a management command (populate_patient_info) that walks Person, Measurement, Observation, DrugExposure, ConditionOccurrence, and the oncology extension tables.

Why bother? Because joining across six or seven OMOP tables and resolving LOINC/SNOMED/ICD-O-3 concepts every time CancerBot evaluates a patient against a trial's eligibility criteria is slow and query-heavy. When a patient loads their dashboard and we score them against thousands of candidate trials in real time, we need single-row, indexed access to their clinical profile. PatientRecord gives us that, without sacrificing the source-of-truth status of the OMOP tables.

What's Actually In There

The PatientRecord shape is expressed as a set of tabs in the front-end admin portal:

• General — demographics, geography, language, disease, stage, performance status (Karnofsky and ECOG), comorbidity flags.
• Disease-specific tabs (e.g., Multiple Myeloma, Follicular Lymphoma) — cytogenetic markers, disease-specific staging, CRAB/SLiM criteria, progression markers.
• Treatment — prior therapy, first/second/later-line therapies with dates and outcomes, stem cell transplant history, refractory status, relapse count.
• Blood / Liver / Labs — the full complement of lab values with proper units, computed derived values like eGFR, and disease-relevant composites like serum free light chains.
• Behavior — consent capability, caregiver availability, contraceptive use, pregnancy/lactation status, language skills, tobacco and recreational drug use, occupational and environmental exposure risk.

Every one of those fields is, underneath, an aggregation over standard OMOP rows with standard concept codes. That's the whole architectural trick.

Getting Data In: FHIR

OMOP is great for analysis but it's not the format in which patient data typically arrives. Modern EHRs and health information exchanges speak FHIR R4. PRomop ships with a FHIR Bundle upload endpoint: you POST a FHIR R4 Bundle, the loader walks the resources (Patient, Observation, Condition, MedicationStatement, MedicationAdministration, DiagnosticReport, etc.), maps each to the appropriate OMOP table, resolves or creates the right concept IDs, and then triggers a refresh of the patient's PatientRecord row. There's also a synthetic FHIR patient generator for testing, which produces realistic oncology bundles including biomarker panels and treatment histories.

How PRomop Supports Precision Trial Matching

The payoff is that eligibility evaluation becomes tractable. A typical oncology trial eligibility rule — "ECOG ≤ 1, hemoglobin ≥ 9 g/dL, adequate renal function (creatinine clearance ≥ 60 mL/min), HER2-positive, no active Hep B, at least one prior line of therapy, able to consent in English or Spanish" — translates to a query over a handful of indexed fields on PatientRecord. We can score thousands of trials against a patient in real time, present the results, and let the patient and their care team explore why they matched or didn't match each one. When we need the audit trail — "where did this HER2 status come from, exactly?" — we drop back to the OMOP tables underneath and pull the source Measurement row with its date, provider, and concept.

Beyond Trial Matching

Trial matching is the forcing function, but the architecture generalizes. A few use cases PRomop serves well out of the box:

• Standard-of-care evaluation. Given a complete, coded treatment history and disease state, you can check a patient against evidence-based guideline trees (NCCN, ESMO) in the same way you check them against trial criteria. The required data is the same; only the rule base differs.
• Longitudinal patient journey visualization. Because episodes, drug exposures, measurements, and observations all carry dates, you can reconstruct the full arc of a patient's disease and treatment for display, summarization, or LLM input.
• Cohort discovery and phenotyping. This is OMOP's native strength, and PRomop inherits it — any existing OHDSI phenotype library or cohort tool works against the standard tables.
• Clinical decision support. The coded, denormalized PatientRecord is a natural feature vector for ML models and a natural input for retrieval-augmented LLM workflows.
• Patient-facing summaries. Because the data is coded rather than just transcribed, you can generate grounded, non-hallucinated patient summaries where every claim traces back to a structured source row.

A Few Practical Notes

PRomop is a Django 5 + Django REST Framework backend with a React/TypeScript front-end, backed by PostgreSQL, with Docker and Render deployment configurations included. The codebase is organized into three Django apps:

• omop_core — standard OMOP CDM core tables plus the PatientRecord integration model.
• omop_oncology — the standard OMOP Oncology Extension models.
• omop_genomics — a placeholder for future genomic-extension work; genomic data currently lives in Measurement and Observation with LOINC concepts.

Migrations use the SeparateDatabaseAndState pattern with idempotent IF NOT EXISTS SQL, which has proven necessary when managing a production database that drifts from Django's migration state — a realistic concern for any long-lived health data system. The project is open source at github.com/healthkey-ai/promop.

Closing Thought

A lot of what goes wrong in health data tooling is the temptation to throw away the standard and build something bespoke because the standard doesn't fit your specific use case perfectly. PRomop is our argument for the opposite move: keep the standard, use its vocabularies religiously, add the minimum extension surface your use case genuinely requires, and solve the performance problem with a well-defined denormalized projection rather than a parallel schema.

The result is a patient record that is simultaneously a first-class OMOP citizen and a fast, transactional substrate for precision applications like CancerBot — and, we hope, for whatever you want to build on top of it next.

Matching a cancer patient to a clinical trial sounds like it ought to be a solved problem. In reality, most matching systems are either (a) proprietary black boxes buried inside a sponsor's CTMS, or (b) brittle keyword searches over ClinicalTrials.gov that miss the clinical nuance that determines whether a patient is actually eligible. EXACT — the open-source matcher maintained at github.com/healthkey-ai/exact — takes a different approach: it treats eligibility matching as a structured-data problem against a patient model that was designed, from the ground up, to be matchable.

This article walks through what EXACT does, the data substrate it sits on, and why the combination produces results that a keyword matcher can't.

The core idea

EXACT is an eligibility-matching engine. You give it a patient (a structured clinical record) and a set of trials (structured eligibility criteria), and it returns which trials the patient qualifies for, which they don't, and — critically — why.

The "why" is the part most matchers skip. A useful match result isn't a ranked list; it's a per-trial trace: this criterion passed because the patient's ANC is 1.8 × 10⁹/L and the threshold is ≥1.5; that criterion failed because the patient has had three prior lines of therapy and the trial caps at two; this other one is indeterminate because we don't have a current ECOG score on file. Patients and navigators act on reasons, not scores.

To produce that kind of output, the matcher has to reason over the same vocabulary that the eligibility criteria use. That is where the rest of the stack comes in.

The patient model: PRomop

EXACT does not parse patient records. It is a stateless matching engine: it receives a structured patient profile — the same field set that the PRomop project defines — and the trial catalog it matches against, then returns verdicts. Nothing about the patient is persisted inside EXACT itself; the only local state it keeps is authentication. PRomop (Patient Record OMOP) is the patient database that produces those structured profiles. It's built on the OMOP Common Data Model v6.0, extended with oncology-specific tables and a denormalized projection called PatientRecord that flattens the clinical picture into the 266 fields an eligibility engine actually needs.

The split matters. OMOP is excellent for storage, interoperability, and longitudinal analytics — conditions, drug exposures, measurements, observations, all coded against SNOMED / LOINC / RxNorm. But eligibility criteria aren't written in OMOP. They're written in statements like "ECOG performance status ≤ 2," "no more than two prior lines of therapy," "triple-negative breast cancer," "absolute neutrophil count ≥ 1.5 × 10⁹/L," or "measurable disease per RECIST 1.1." To evaluate those, you need both the raw coded events and derived clinical judgments that roll up from them.

PRomop does both. The underlying OMOP tables hold the ground truth: condition_occurrence, measurement, observation, drug_exposure, plus oncology extensions (omop_oncology.Episode, EpisodeEvent, AILineOfTherapySummary). The PatientRecord model exposes a flattened, eligibility-ready view of that ground truth, with a number of fields computed automatically on save:

• therapy_lines_count — count of non-empty first / second / later therapy fields.
• prior_therapy — categorical, in the exact vocabulary EXACT matches against: "None," "One line," "Two lines," or "More than two lines of therapy."
• treatment_refractory_status — derived from the sequence of per-line outcomes: zero negative outcomes means "Not Refractory"; one means "Primary"; two means "Secondary"; three or more means "Multi-Refractory."
• relapse_count — counts successful outcomes (CR / sCR / VGPR) followed by a new line of therapy, unless manually overridden.
• measurable_disease_imwg — applies IMWG criteria on M-protein and free light chains to decide whether the patient has measurable disease by the myeloma standard.
• tp53_disruption — true iff any entry in the patient's genetic_mutations list has gene = TP53 and interpretation = pathogenic.
• lymphocyte_doubling_time — log-linear fit on serial absolute lymphocyte counts.
• bmi, patient_age — unit-aware derivations from weight/height and date of birth respectively.

These aren't cosmetic conveniences. Every one of them corresponds to a phrasing that appears in real oncology eligibility criteria. By computing them once, in the patient database, with explicit rules that clinicians can audit, EXACT gets to do simple field comparisons instead of re-deriving clinical judgments inside the matcher. The derivation logic lives in one place; the matcher stays boring (in the best possible way).

The eligibility substrate

On the other side of the match is a structured trials database — one row per trial, with columns for every eligibility attribute the matcher knows how to evaluate. Each column corresponds to a PatientRecord field or a derived one, so matching becomes a per-criterion comparison rather than a per-trial free-text read.

Concretely, the trials table carries columns for:

• Cancer type and subtype — histology (e.g., IDC vs. ILC for breast), disease-specific constraints.
• Receptor and biomarker status — ER, PR, HER2, HR, TNBC, PD-L1 (tumor cells, IC%, CPS), HRD. Most of these are tri-valued (positive / negative / unknown), because eligibility routinely requires "unknown" to be resolved before enrollment.
• Staging — T, N, M, overall stage, and disease burden flags like measurable_disease_by_recist_status, bone_only_metastasis_status, metastatic_status.
• Prior therapy — allowed / required / excluded lines, specific agent exposures (prior_exposure_flags), and categorical line counts in the EXACT vocabulary above.
• Refractory / relapse state — required or excluded values of treatment_refractory_status and relapse_count.
• Lab thresholds — hematology (ANC, platelets, hemoglobin), renal (creatinine, eGFR), hepatic (AST, ALT, bilirubin, albumin), electrolytes, coagulation, LDH, inflammation markers, cardiac markers. Each threshold is stored with its unit so UCUM conversions happen explicitly.
• Genomic requirements — specific mutations or mutation classes (BRCA1/2, PIK3CA, ESR1, TP53 disruption, etc.), using the same structured mutation schema the patient model uses.
• Performance and eligibility status — ECOG, Karnofsky, consent capability, cognitive status, reproductive safety.
• Exclusions — concurrent malignancies, active infections (HBV / HCV / HIV status), washout requirements.
• Administrative constraints — age range, geography (trial sites within a reachable radius), language.

The trials table is the schema-side mirror of PatientRecord. That symmetry is what makes the matcher tractable.

What the matcher actually does

Given that substrate, EXACT's job decomposes into four things:

1. Attribute-level evaluation

For each (trial, criterion) pair, EXACT compares the trial's stored requirement against the patient's field. Numeric thresholds use unit-aware comparison (a threshold expressed in ×10⁹/L matches a patient value stored as cells/µL). Categorical fields use the trial's allowed-set semantics. Boolean flags get straightforward logic. Missing patient data produces an indeterminate result, never a silent pass.

2. Criterion-level composition

Real eligibility is rarely a single field. "ANC ≥ 1.5 AND platelets ≥ 100 AND no prior anti-PD-L1 exposure" is three attribute comparisons ANDed together; "measurable disease by RECIST OR bone-only metastatic disease with evaluable marker" is a disjunction over two derived flags. EXACT composes attribute results with explicit boolean logic, and propagates indeterminacy correctly — an AND with any fail is a fail, but an AND with a pass and an indeterminate is still indeterminate.

3. Trial-level verdict

EXACT assigns each (patient, trial) pair one of three states: Eligible if all inclusion criteria pass and no exclusion criterion triggers; Ineligible if any inclusion fails or any exclusion fires; Potential if the only thing blocking the verdict is missing data on a small number of criteria. The Potential state is the one that matters most in practice — it's the matcher's way of saying "you would qualify for this trial if you also had a recent ECOG score on file," and it's what turns a match engine into a useful data-collection prompt rather than a binary gate.

4. Explanation

Every verdict comes with the criterion-by-criterion trace that produced it. This is what makes EXACT auditable: a patient navigator can see exactly which criterion knocked the trial out, point at the underlying PatientRecord field, and decide whether it's wrong (data quality issue), stale (need a fresh lab), or correct (genuinely ineligible).

The vocabulary contract

One detail deserves its own mention. The categorical fields — prior_therapy, treatment_refractory_status, relapse states, receptor statuses — all use controlled vocabularies that are shared between the patient model (PRomop) and the trials model. The schema documentation explicitly calls these "EXACT & CB matcher vocabulary" values.

This is the boring infrastructure work that makes the whole thing go. Without it, you end up with patient records saying "2 prior lines" and trial records saying "≤2 prior lines of therapy" and a matcher desperately trying to bridge them with regex. With it, both sides store the same enum values, comparison is a dictionary lookup, and the code stays short.

FHIR as a boundary, not a pivot

EXACT matches against PRomop, not FHIR. But PRomop itself ingests from FHIR — the documented ETL pipeline validates, deduplicates, and lands FHIR resources into the OMOP tables that back PatientRecord. The schema spreadsheet carries the FHIR mapping for every field, which means a partner system can stream FHIR bundles in at the boundary, and EXACT can match against the resulting structured record without ever itself parsing a Bundle or traversing a Patient.telecom[system=email] path.

The separation of concerns is the point. FHIR is the interchange format. OMOP is the storage and analytics substrate. PatientRecord is the eligibility projection. EXACT is the matcher. Each layer does one job, so each layer stays debuggable.

Running EXACT

EXACT ships as a Django application that can run in two modes: as a REST API server, or as a one-shot batch matcher driven by a shell script. Both modes share the same matching core; they differ only in how the patient profile gets in and how the results come out.

Server mode

Clone the repo, install dependencies, migrate the local auth database, and point it at your trials catalog:

pip install -r requirements.txt
python manage.py migrate
export TRIALS_DATABASE_URL=postgresql://readonly:secret@trials-db.example.com:5432/trials
python manage.py runserver

In this mode, patient profiles are passed inline with each API request — nothing patient-related is persisted by EXACT. Authentication tokens are the only local state. The full REST reference lives in docs/api.md.

If no external trials database is configured, EXACT falls back to a single local database for everything, which is handy for development. Seed reference data with python manage.py seed_reference_data before running.

Batch mode

To match a batch of patients directly from the patient database against the trial catalog — no web server, no HTTP — use the trials4patients.sh script:

export TRIALS_DATABASE_URL=postgresql://...
export PATIENT_DATABASE_URL=postgresql://...
bash scripts/trials4patients.sh

The useful environment variables:

• TRIALS_DATABASE_URL (required) — remote trials PostgreSQL database.
• PATIENT_DATABASE_URL (required) — patient database (PRomop).
• PERSON_IDS (default: all) — comma-separated PRomop person IDs to process.
• PATIENT_LIMIT (default: all) — cap on number of patients.
• SEARCH_LIMIT (default: 20) — top N trials returned per patient.
• RESULTS_CSV — if set, writes an evaluator-ready CSV to this path.

Evaluating results

EXACT ships with an evaluator that scores a run's output against a ground-truth CSV. Both files use the same four-column schema:

PRomop Patient ID,Trial,Eligible/Potential,Suitability Score
20291,NCT03452774,potential,81
20291,NCT07038785,eligible,79

Trials that EXACT considers ineligible are simply absent; the CSV records only the positive-verdict trials, ranked. The typical evaluation run has three steps:

1. Extract the patient cohort from the ground truth:

   PERSON_IDS=$(tail -n +2 scripts/evaluator/ground_truth.csv \
     | cut -d',' -f1 | sort -u | tr '\n' ',' | sed 's/,$//')

2. Run the matcher and write a results CSV:

   PERSON_IDS="$PERSON_IDS" \
   SEARCH_LIMIT=5 \
   RESULTS_CSV=results.csv \
   bash scripts/trials4patients.sh

3. Score the results:

   bash scripts/evaluator/evaluate.sh \
     scripts/evaluator/ground_truth.csv \
     results.csv

The evaluator computes recall, precision, F1, type_match_rate, score_match_rate, score_MAE, score_bias, MRR, and avg_rank — micro-averaged across the cohort. Add --output /tmp/comparison.json to get the full per-trial breakdown.

One nuance worth noting: SEARCH_LIMIT is not just a performance knob — it changes the shape of the penalty metric. A lower top_n makes the penalty for missing trials harsher, because a trial ranked just outside the returned window is treated the same as one EXACT doesn't return at all.

When recall drops, the cause is one of two things. If the expected trial exists in the catalog but ranked below top_n, it's a ranking problem — raise SEARCH_LIMIT. If the expected trial isn't in the catalog at all, it's a coverage gap. The quick check:

python manage.py shell -c \
  "from trials.models import Trial; print(Trial.objects.filter(code='NCT03452774').exists())"

Why this design holds up

Trial eligibility is unforgiving in a very specific way: a false positive means a patient is told they qualify for a trial they don't, which wastes everyone's time and erodes trust; a false negative means a patient never hears about a trial that could have helped. Both failure modes trace back to the same root cause: mushy data. Free-text eligibility, scraped keywords, inferred labs, uncontrolled vocabularies — any one of them is enough to make the output unreliable.

EXACT's answer is to push the mushiness out of the matcher. The matcher only does comparisons. The clinical derivations happen in PRomop, with explicit rules. The vocabulary is controlled on both sides. The thresholds are unit-aware. The explanation is first-class. The whole system is open source, which means the derivations are inspectable by the clinicians whose judgments they encode.

For an oncology population where eligibility criteria run thirty lines deep and a single missing lab can flip the verdict, that discipline is the difference between a trial matcher that clinicians actually use and one that gets demoed twice and quietly retired.

EXACT and PRomop are maintained at github.com/healthkey-ai under open-source licenses. The patient schema described in this article — including FHIR and OMOP mappings for all 266 PatientRecord fields — is published alongside PRomop as the interoperability reference.

At a recent pre-conference roundtable on clinical trial matching, hosted as part of Harvard's Patient-Powered Digital Health Conference, we did something we try to do as often as possible at HealthKey: we stopped talking and listened. The room was full of patients and advocates who had lived the experience of searching for a trial — and what they told us reshaped how we think about the problem.

It also clarified something about the matcher we build in the open, EXACT. EXACT already does the hard part well: it reads a trial's eligibility criteria, evaluates them against a patient's longitudinal record, and returns a per-criterion verdict — eligible, potential, or ineligible — with the reasoning attached. That transparency is deliberate, and it's a real advance over the opaque, ranked-list approach most matchers take. But the roundtable made one thing unmistakable: matching a patient to an eligible trial, done perfectly, still leaves a large part of the patient's actual problem unsolved.

This post is about that gap, and about why we think the next chapter of trial matching — the one we're building toward — looks very different from what the category contemplates today.

The real problem isn't discovery. It's the decision.

The sharpest insight from the room was that finding eligible trials is necessary but nowhere near sufficient. One participant described enrolling in a trial without ever comparing it to standard of care or comprehensively searching for alternatives — not out of carelessness, but because nothing in the system is built to help a patient make that comparison. The information needed to decide well is scattered across portals, PDFs, and conversations, and no tool brings it into one place where a patient and their clinician can weigh it together.

This is the part of the problem most trial matchers don't even attempt. They answer "which trials could I join?" The patients in that room were asking a harder question: "given everything I value, which of my options — trials and standard of care — is right for me?"

For EXACT, this points to a clear direction. Eligibility is the foundation, not the finish line. The same patient record that EXACT uses to evaluate trial criteria can evaluate standard-of-care options on identical footing — which means the natural next step is presenting trials and standard of care side by side, as comparable choices rather than separate searches. We're fortunate that the architecture underneath EXACT already evaluates both against one structured record, so this is an extension of what we've built, not a departure from it.

Values are not a footnote. They're the rubric — and the community should write it.

Everyone agreed that the right choice depends on the patient's own priorities — and then they pushed further, in a way that genuinely sharpened our thinking. The usual framing of "risk, benefit, and burden" is too coarse. Burden, one participant pointed out, isn't even a fixed quantity: what counts as burdensome varies enormously from one patient to the next. The true cost of travel is routinely underestimated by the trials industry. Preferences seem to carry less weight for older patients. And benefits get undersold too — the value of traveling to join a community of patients facing the same disease is real, and almost never communicated.

The most important thing anyone said all afternoon was this: the patient voice has to help define the rubric itself, not merely answer it.

EXACT already takes patient values seriously. It performs patient-centered multi-criteria decision analysis — weighing risk, benefit, and burden — to turn a set of eligible options into something a patient can actually reason about. That's a meaningful step beyond a yes/no eligibility list. But the roundtable convinced us those rubrics can be much better, and that the people who can make them better aren't us.

The dimensions that matter — what burden really means, how travel weighs against benefit, when community and cohort value tip a decision, how preferences should be honored regardless of a patient's age — are not best decided in a vacuum by engineers. They're best decided by patient support groups and advocates who live the disease, optimized per disease, with all the factors that came up in that room, and with the care and attention only those communities can bring. So the direction we're committed to is this: rubrics co-developed with patient foundations and advocacy groups, tuned disease by disease, and published openly so that anyone can use them — in a digital tool or with a pen and a conversation. A good rubric shouldn't be locked inside one piece of software.

Where we'll keep leading is integration. We'll take these community-optimized rubrics and build them directly into EXACT's recommendations as suitability scores, so the matcher doesn't just tell a patient what they're eligible for — it reflects what their own community has decided matters most. And because the primary users of EXACT are exactly those foundations and patient support groups, we're positioned to do something no general-purpose matcher can: foster fast feedback and rapid iteration with the very groups authoring the rubrics, refining the scoring continuously as they learn. The rubric improves, the scores improve, the matches improve — in a loop that runs at community speed.

No trial matcher we know of is building toward this. We are.

Ask for the right thing, at the right time

A practical insight reshaped how we think about sequencing. A long preferences instrument is a burden if you hand it to someone before they know whether any trial is even open to them. The better order is the obvious one once you hear it: determine eligibility first — cheap, structured, fast — and then do the deeper, more personal work of weighing options only across the trials that are genuinely viable.

This fits EXACT naturally. Eligibility filtering is exactly the kind of fast structured pass EXACT already performs; the preference work belongs downstream, on the smaller surviving set. It keeps the heavier instrument off the critical path and respects the patient's time.

There's a deeper principle underneath this, which one participant captured better than we could have: utility drives trust, trust drives more information, and more information drives better matches. Patients share data when they can see it improving their care. This is why EXACT's "potential" verdict matters — when a match hinges on one missing piece of information, telling the patient exactly what's missing and why it matters turns a dead-end into a reason to engage. Branching, purpose-aware data collection that visibly unlocks better answers is the mechanism that earns the trust the whole system runs on.

Transparency about data is a feature, not fine print

One of the most actionable observations was about data itself. A participant described being asked for far more data than a trial could plausibly need, with no explanation of what was actually required — and a consent document that didn't even state her data would be de-identified. The opportunity here is real and largely unexploited: scoped, transparent data-usage agreements that say plainly what a study needs, limit use to the agent or procedure in question, and are explicit about de-identification — while still leaving room for the legitimate science of novel sub-cohort analysis.

This sits squarely inside HealthKey's founding conviction that patients should own and control their health data. It's an area we're actively thinking through as the patient-facing side of trial matching matures. We'd rather treat data scope as something a patient understands and controls than as something buried in a form.

Communities, not just individuals

Finally, the room kept returning to the power of patient disease communities. The idea that resonated most was patient groups banding together on a per-disease basis to define what good looks like — what the priorities are, what burden means, what benefit looks like for their disease. This maps directly onto how we already work: our deepest deployments live inside disease communities, and we think the right operating model is one where HealthKey builds the framework and the communities themselves populate the priorities that matter to them. The rubric, in other words, gets written by the people it serves.

There's also an honest boundary worth naming. Today the system is largely not set up for patients to drive their own trial search — enrollment usually still routes through a physician, and the friction is significantly worse for patients outside the United States. We don't have a complete answer to that yet. But building an open, patient-facing matcher is a deliberate step toward a world where patients have far more agency than they do now.

A note on rare disease

One caution shaped everything above. In rare disease, there often isn't an accepted standard of care to compare against — which means the whole "trial versus standard of care" framing can break down. Any comparison we build has to degrade gracefully when there's no comparator, never assuming standard of care exists. It's a reminder that the patients with the fewest options are often the ones the tooling serves worst, and they're exactly the ones we most want to serve well.

Where this leaves us

None of this is a critique of where EXACT stands today. Transparent, per-criterion, open-source trial matching with patient-centered MCDA across multiple cancers is already further than most of the field has gone, and we're proud of it. What the roundtable gave us is a map of the territory beyond it — the trial-versus-standard-of-care decision, the right-time data ask, scoped and transparent consent, and above all community-authored, per-disease rubrics that anyone can use and that we integrate into our suitability scores through a fast feedback loop with the foundations we serve.

That territory is where trial matching is going, and very little of the category is even looking in that direction. We are. We're building it in the open, and we're building it with patients — because, as that afternoon made clear, they understand the problem better than anyone.

EXACT is open source and available at github.com/healthkey-ai/EXACT. If you're a patient advocate, clinician, or researcher who wants to help shape the work described here, we'd like to hear from you.

A data scientist's guide to patient-centered health infrastructure.

If you work with patient data — as an informaticist, a data scientist at a research foundation, or an engineer building health tooling — you already know the shape of the problem. The records are fragmented across providers. The standards are real but the mappings are manual. And the gap between "we have data" and "we can act on it for an individual patient" is wide and mostly hand-built.

PHRAME is an open-source suite from HealthKey designed to close that gap. It is infrastructure, not an end-user product: a set of components you assemble into a longitudinal, standards-based patient record and then build on. This post walks through how to go from a pile of patient data to working trial matching, outcomes analytics, and standard-of-care suggestions — using five projects that fit together.

Everything is available at github.com/healthkey-ai. The projects are designed to be adopted incrementally: you can start with the database alone and add the rest as you need them.

The Shape of the Suite

Before the steps, the mental model. PHRAME is organized as a pipeline with a storage layer in the middle and a serving layer on top:

• PRomop — the patient database. A standards-based longitudinal store built on the OMOP Common Data Model (CDM 5.4), with oncology extensions. This is where every patient record lives.
• PRism — the analytics platform that sits over PRomop, for population and cohort-level insight.
• EXACT — the clinical trial matcher, which evaluates patients against trial eligibility criteria.
• SoC — the standard-of-care service, which evaluates guideline-based care options for a patient.
• fhir_importers — the ingestion path for pulling additional records in from EHRs via FHIR.

The key architectural idea worth internalizing up front: everything serves off the same patient record. Trial matching, outcomes analytics, and standard-of-care evaluation all read from PRomop rather than each maintaining its own copy of the truth. That is what makes the suite coherent rather than five disconnected tools.

Step 1 — Load Patients with PRomop

Start with the database. PRomop gives you a standard OMOP CDM 5.4 schema — the familiar tables like person, condition_occurrence, drug_exposure, measurement, observation, procedure_occurrence — plus oncology-specific extensions for episodes and lines of therapy that the base CDM doesn't cover well.

The first task is getting your source data mapped into that schema. If you come from the OHDSI world this will feel native: PRomop is designed to work with the standard tooling (WhiteRabbit and Rabbit-in-a-Hat for profiling and source-to-OMOP mapping, Usagi and Athena for vocabulary mapping to LOINC, SNOMED CT, RxNorm, and ICD-O-3). You profile your source, author the field mappings, and load.

What makes PRomop more than "just an OMOP database" is PatientRecord — a flattened, denormalized projection of each patient into a single wide row of ~266 fields. The transactional CDM tables are the source of truth and capture everything that ever happened; PatientRecord is the decision-ready view of what is true now: demographics, staging, treatment lines, biomarkers, labs, derived fields like prior-therapy and current status. You populate it with a management command after loading.

This projection is the load-bearing piece for everything downstream — it is what lets analytics, trial matching, and care evaluation all run on the same substrate without re-deriving patient state each time. By the end of this step you have a queryable, standards-conformant longitudinal record for your patient population.

Step 2 — Analyze Aggregate Outcomes with PRism

With patients loaded, PRism gives you the population view. It is the analytics layer over PRomop, built for the questions a research foundation or informatics team actually asks: what are the outcomes across this cohort, how do treatment patterns shift over time, what does survival look like for a given subgroup.

Out of the box you get standard oncology analytics — Kaplan-Meier curves for overall survival, progression-free survival, and event-free survival; treatment-sequence visualizations (a sunburst of how therapy changes line to line); cohort definition and saving; and the data-characterization and quality metrics you'd expect from an OHDSI-style stack.

Because PRism reads the same PatientRecord projection, defining a cohort and computing an outcome on it is fast — you are querying a flat structure, not reassembling longitudinal state on every run.

A live demo running on synthetic data is at prism.healthkey.ai — you can create an account and explore the chart types against synthetic multiple myeloma and breast cancer patients to see the shape of what you'd get on your own cohort. This is the step where most teams get their first "we couldn't see this before" moment: aggregate outcomes across a fragmented population, computed on a standardized record.

Step 3 — Find Trials for Patients with EXACT

EXACT is the open-source clinical trial matcher. Where most matchers return an opaque ranked list, EXACT evaluates each patient against trial eligibility criteria one criterion at a time and returns a tri-valued verdict per trial:

• Eligible — all inclusion criteria pass and no exclusions fire.
• Potential — the only thing standing between the patient and a verdict is missing data; EXACT tells you exactly what is missing.
• Ineligible — an inclusion failed or an exclusion triggered.

That middle state is the one that matters operationally. In real cohorts, "potential — need one more data point" is often the largest group, and surfacing precisely what's missing turns a dead-end into an action: go collect that value, or import it (see Step 5).

EXACT runs against a structured trials database — for example a continuously updated feed of oncology trials from ClinicalTrials.gov, EU-CTR, and ISRCTN — using the same PatientRecord fields you populated in Step 1, so no patient re-modeling is required to start matching.

Because the verdicts are per-criterion and explained, EXACT's output is also auditable: you can show a clinician or a patient navigator why a trial matched or didn't, rather than asking them to trust a score.

Step 4 — Suggest Standard-of-Care Options with SoC

Trial matching answers "what research could this patient join." The SoC service answers the equally important question patients and clinicians face: "what are the established care options right now."

SoC evaluates guideline-based standard-of-care pathways against the patient's record, with cancer-type-specific logic, and produces the care options applicable to that patient's current state.

Running trial matching and standard-of-care evaluation on the same substrate is deliberate. A patient deciding what to do next needs both in view — a trial is rarely the right frame in isolation, and the most useful systems present research options and established care side by side. Because EXACT and SoC both read PatientRecord, you get that side-by-side view without integration glue.

One caution worth carrying: in rare disease there may be no accepted standard of care to compare against, so don't assume SoC always returns a comparator.

Step 5 — Import Additional EHR Records via FHIR

Steps 1–4 work entirely on the data you started with. But patient records are never complete, and the fhir_importers project is how you enrich them. It ingests FHIR R4 resources — Patient, Condition, Observation, MedicationRequest, and the rest — and routes them into PRomop, where they land in the same CDM tables and flow back into the PatientRecord projection.

This is the step that turns a static cohort into a living one. As you connect EHR sources (including via networks like TEFCA/QHIN), new labs, diagnoses, and treatments arrive, the projection updates, and every downstream capability sees the richer picture automatically: outcomes analytics get more complete, trial matches that were "potential — missing data" can resolve to "eligible," and standard-of-care evaluation reflects the patient's current state.

The importers are FHIR-native, so FHIR Bundles route in directly; non-FHIR formats like C-CDA go through conversion first.

A practical note on sequencing: many teams deliberately start without EHR import — a manual or research-loaded cohort is enough to stand up the whole pipeline and prove value — and add fhir_importers once the data-sharing permissions are in place. The architecture supports either order.

Putting It Together

The whole loop, in one breath: load your population into PRomop and populate PatientRecord; see aggregate outcomes with PRism; match individuals to trials with EXACT; evaluate established care with SoC; and keep the records growing with fhir_importers — each new record flowing back through the same projection so every capability improves at once.

The reason it hangs together is the single shared record. You model patient state once, in a standards-based way, and four different kinds of value — population analytics, trial matching, care evaluation, ongoing ingestion — all read from it. That is the whole thesis of PHRAME as infrastructure: do the hard part (a clean longitudinal record) once, and make everything else a query against it.

Where to Start

Clone the projects from github.com/healthkey-ai and stand up PRomop first against a small cohort — even synthetic or research-loaded data is enough to see the pipeline work end to end. Explore the analytics live at prism.healthkey.ai before you load your own. From there, add EXACT, SoC, and fhir_importers in whatever order matches your priorities.

It's open source because patient-centered infrastructure should be something the whole field can build on. If you're an informaticist or data scientist working on this problem, we'd like to see what you build with it.

Specific setup instructions, dependencies, and supported versions are in each project's repository README.

Abstract

Health systems and biopharma face a persistent gap between holding patient data and acting on it. Records remain fragmented across providers, standards-conformant but manually mapped, and structured for storage rather than decision-making. Every downstream application — analytics, trial matching, clinical decision support — re-derives patient clinical state from scratch, multiplying effort and inconsistency.

We present PRomop, an open-source longitudinal patient health record built on the OMOP Common Data Model (CDM 5.4) with oncology extensions. Its keystone is PatientRecord, a flattened, denormalized projection that collapses each patient's complete longitudinal history into a single decision-ready row of 286 columns. While the transactional CDM tables preserve everything that ever happened, PatientRecord represents what is true now, computing patient-state derivations once rather than repeatedly per consumer. This lets population analytics, clinical trial matching, and standard-of-care evaluation operate on one shared substrate rather than maintaining divergent copies of the truth.

PRomop is deployed in production across the HealthTree Foundation (~14,000 blood-cancer patients) and CancerBot (~3,500 patients), supporting trial matching against ~6,000 actively recruiting trials across five cancer types. A 20-criterion eligibility search that requires 27–39 joins over raw OMOP reduces to zero joins against the projection — an estimated ~30×–200× speedup.

Keywords: longitudinal patient record, OMOP CDM, OHDSI, clinical trial matching, real-world data, oncology informatics, decision support, open-source health infrastructure.

Introduction

Across health systems and biopharma, the hardest problem in applied health AI is rarely the model — it is the data beneath it. Patient records are scattered across providers, electronic health records, laboratories, and registries. Even where data is captured in standards-conformant form, the mappings are manual, the structure is optimized for storage rather than decision-making, and the distance between holding patient data and acting on it for an individual remains wide and largely hand-built.

A consequence of this gap is repeated, redundant effort. Each downstream application — a cohort analytics pipeline, a clinical trial matcher, a clinical decision support rule engine — must independently reconstruct the patient's clinical state from the underlying transactional record: resolving lines of therapy, determining current disease status, normalizing biomarkers, reconciling conflicting source values. This re-derivation is expensive, error-prone, and a frequent source of inconsistency between applications that should agree.

This paper presents PRomop, an open-source longitudinal patient health record designed to close that gap. PRomop makes two commitments simultaneously: it is standards-based, building on the OMOP Common Data Model so that it interoperates with the broader OHDSI ecosystem; and it is decision-ready, exposing a flattened projection of each patient that downstream applications can consume directly without re-deriving clinical state.

The central architectural idea is a deliberate separation between a transactional record and a decision-ready projection. The transactional layer — standard OMOP tables with oncology extensions — preserves everything that ever happened to a patient. A computed projection we call PatientRecord collapses that history into a single wide row representing what is true now. Patient-state derivation is performed once, during projection, and materialized; every consuming application reads the same projection rather than reconstructing state.

Our contributions are:

• An architecture that separates a standards-based transactional record from a flattened, decision-ready projection (PatientRecord), enabling multiple application classes to serve from one substrate.
• Oncology extensions to OMOP CDM 5.4 (episodes, lines of therapy) developed as a proposed upstream contribution to OHDSI rather than a proprietary fork.
• Operational evidence from production deployment across two independent oncology organizations totaling ~17,500 patients, including an analysis showing a 20-criterion eligibility search reduced from 27–39 joins over raw OMOP to zero joins against the projection (an estimated ~30×–200× speedup), and trial matching across ~6,000 actively recruiting trials in five cancer types.
• Candid deployment lessons, particularly the inadequacy of purely structural approaches for inferring lines of therapy and the ongoing maintenance burden of a demand-coupled projection.

Background and Related Work

The OMOP Common Data Model and OHDSI

The OMOP CDM is a widely adopted standard for representing observational health data in a common relational schema, maintained by the OHDSI community. Its strength is interoperability: standardized vocabularies (SNOMED CT, RxNorm, LOINC) and a shared schema allow analyses written once to run across institutions. OMOP is, however, a model optimized for storage and population-level observational analysis. It is normalized and event-oriented; answering a question about an individual patient's current clinical state typically requires substantial joins and derivation. PRomop adopts OMOP as its foundation precisely to inherit this interoperability, and adds a projection layer to address decision-readiness for the individual patient.

Oncology Extensions

Base OMOP represents oncology concepts such as cancer episodes and lines of therapy only partially. The OHDSI Oncology Working Group has developed extensions to the CDM, including the Episode and Episode_Event tables that model disease episodes and treatment regimens. PRomop builds on this direction and contributes additional oncology columns, which we intend to submit upstream.

Flattened and Feature-Oriented Patient Representations

The tension between normalized clinical models and flattened, analysis- or ML-ready representations is well known; feature stores and denormalized "patient-level" tables are common in practice. PRomop's contribution is not the idea of flattening per se, but the discipline of computing a single canonical decision-ready projection once, materializing the derivations, and serving all downstream workloads — analytics, matching, and clinical decision support — from it.

Clinical Trial Matching

Automated trial matching has seen substantial recent work, much of it using large language models — TrialGPT, TrialMatchAI, and OncoLLM. Much of this work returns ranked lists of candidate trials. PRomop's companion matcher, EXACT, instead evaluates eligibility criterion-by-criterion against the PatientRecord projection and returns a tri-valued verdict (eligible / potential / ineligible) per trial.

Method and Architecture

PRomop's design rests on a two-layer separation between a transactional record and a decision-ready projection, implemented on open standards and validated through production deployment.

Storage Layer

We adopt OMOP CDM 5.4 as the foundation, populating its standard clinical tables (person, condition_occurrence, drug_exposure, measurement, observation, procedure_occurrence) and extending it with oncology-specific structures for episodes and lines of therapy that the base model represents poorly. Source data is ingested via OHDSI-standard practice: profiling source schemas, authoring explicit field mappings, and mapping vocabularies to LOINC, SNOMED CT, RxNorm, and ICD-O-3.

Projection Layer: PatientRecord

The architectural core is PatientRecord: a flattened, denormalized projection that collapses each patient's full longitudinal history into a single wide row of 286 columns. Where the transactional tables preserve everything that ever happened, PatientRecord is computed to represent what is true now: demographics, staging, treatment lines, biomarkers, laboratory values, and derived clinical state such as prior therapy and current disease status.

Derivation logic that would otherwise be re-implemented in every downstream consumer — computing lines of therapy, resolving current status, normalizing biomarkers — is performed once, at projection time, and materialized. Projection refresh is event-driven: changes to a patient's underlying record trigger regeneration of that patient's projection, keeping the decision-ready view current. Refresh can also be invoked on demand, and event-driven refresh can be disabled during bulk operations (e.g., large backfills), with a single rebuild at batch end.

Serving Layer

Because every consuming workload reads the same projection, three distinct application classes operate on one substrate rather than maintaining divergent copies: (i) population and cohort analytics; (ii) per-criterion clinical trial matching; and (iii) guideline-based standard-of-care evaluation. This shared-substrate design is the method's central efficiency claim: the join surface and state-derivation cost that normally scale with the number of applications are collapsed into a single shared step.

Ingestion and Currency

Records are enriched over time through FHIR-native ingestion: FHIR R4 resources are routed into the CDM tables, while non-FHIR formats (C-CDA) are converted upstream. As new clinical events arrive, the projection updates and downstream capabilities reflect the richer record automatically, including the resolution of previously incomplete states.

Results and Outcomes

Existence Proof at Scale

PRomop's primary result is an existence proof at scale: a standards-based longitudinal record with a decision-ready projection, operating in production rather than in prototype. The architecture is deployed across two independent oncology organizations — the HealthTree Foundation (~14,000 blood-cancer patients) and CancerBot (~3,500 patients) — totaling roughly 17,500 real patients drawn from fragmented, heterogeneous, real-world sources.

Decision-Readiness in Practice

The PatientRecord projection collapses each patient's longitudinal history into a single 286-column decision-ready row across both deployments. Consider a realistic 20-criterion eligibility search over raw OMOP — roughly 8–10 laboratory criteria, 5 condition criteria, 3 prior-therapy criteria, and 2 procedure criteria. This requires on the order of 27–39 joins, spanning person, condition_occurrence, measurement, drug_exposure, episode, and procedure_occurrence, with a concept lookup for nearly every criterion.

Laboratory criteria are the dominant cost: because measurement stores one row per test per date, each lab criterion needs not only a table join and a concept join but a correlated subquery (effectively GROUP BY with MAX(date)) to recover the most-recent value. The query cost grows roughly as O(n_criteria × n_measurement × log n_concept).

Table 1. Approximate table cardinality. The measurement table dominates: a 20-criterion query with ~10 laboratory criteria must scan it repeatedly, filter on concept_id, and aggregate to the latest value before joining back to person.

Against PatientRecord, the same 20-criterion search requires zero joins: every criterion resolves to a predicate on a single 10,000-row table, because the latest values, concept resolutions, and derived states have already been computed at ingest. Adding a criterion is linear in patient count rather than in criteria count.

Table 2. Join count and estimated query-time comparison for a 20-criterion eligibility search at 10,000 patients. The gap widens with each added criterion.

One Substrate, Multiple Workloads

The shared-substrate claim held: population analytics, clinical trial matching, and standard-of-care evaluation all run against the same projection without maintaining separate copies of patient state. Trial matching operates against approximately 6,000 actively recruiting trials spanning follicular lymphoma, multiple myeloma, breast cancer, chronic lymphocytic leukemia, and mantle cell lymphoma, evaluated for the full ~17,500-patient population. Adding a new application became a matter of querying an existing record rather than rebuilding patient state, lowering the marginal cost of each new capability.

Operational Lessons

Inferring lines of therapy. This proved a particular challenge. Purely structural normalization was insufficient for real-world oncology data; we supplemented the OHDSI ARTEMIS approach with our own rules and the ability to read from physicians' notes to derive therapy lines reliably from incomplete and inconsistent sources. This suggests a broader principle: the decision-ready projection is where clinical reasoning, not merely data transformation, must live.

The projection is a living artifact. Decision-readiness is not a stable end state. As new trial eligibility criteria and clinical decision support rules emerged, additional fields had to be added to the projection, requiring ongoing vigilance to keep the decision-ready view aligned with downstream demand. Teams adopting this pattern should plan for projection maintenance as a continuous obligation.

Discussion

The central lesson of PRomop is that the hardest part of applied health AI is not the model or even standardization — it is making a standardized record decision-ready, and doing so once rather than repeatedly. Eliminating the 27–39 joins of a raw-OMOP eligibility query down to zero is striking, but its real significance is economic rather than technical: it changes the marginal cost of every new application. When patient state is derived once at projection time, adding a trial matcher, an analytics view, or a clinical decision support rule becomes a query against an existing record rather than a fresh state-reconstruction effort. The architecture's value compounds as applications accumulate.

The lines-of-therapy experience complicates any claim that decision-readiness is purely a structural problem. The fields hardest to derive are precisely those most valuable downstream, and they resist tidy extract-transform-load; they require embedded clinical reasoning, including reading unstructured notes. A second lesson tempers the architecture's appeal: the same property that makes PatientRecord powerful — pre-computing what consumers need — makes it a living artifact coupled to evolving clinical demand, with a continuous maintenance cost.

These results carry limitations worth stating plainly. Our evidence is operational and analytical rather than benchmarked: we demonstrate that the architecture works at scale and quantify its join savings from OMOP cardinality and query structure, but we do not yet report controlled end-to-end timing against alternatives. Both deployments are in oncology; the OMOP foundation is disease-agnostic, but the oncology extensions and derived fields are not yet validated outside this domain. The ~30×–200× speedup is an estimate over a representative eligibility workload and should be read as illustrative of the pattern's effect rather than a universal benchmark.

Situated against the field, PRomop's contribution is deliberately not novelty in the data model — it builds on OMOP precisely to avoid fragmenting the standards ecosystem and returns its oncology extensions upstream. The novelty is the projection layer and the discipline of computing decision-readiness once.

Conclusion

PRomop demonstrates that a flattened, decision-ready projection over a standards-based longitudinal record is a viable, deployed pattern for turning fragmented patient data into infrastructure that AI applications can act on. By computing patient state once and serving analytics, trial matching, and standard-of-care evaluation from a single shared record, PRomop collapses the redundant derivation that burdens conventional pipelines — reducing a 20-criterion eligibility search from 27–39 joins over raw OMOP to zero against the projection, an estimated ~30×–200× speedup — while remaining conformant with OMOP and contributing its oncology extensions back to OHDSI.

Deployed across ~17,500 real oncology patients, it offers a concrete, open-source pattern for moving from proof to practice. Future work includes validation beyond oncology, formal end-to-end benchmarking, and completion of the upstream OHDSI oncology contribution.

Availability

The PRomop project and related PHRAME components are open source and available at github.com/healthkey-ai. A live analytics demonstration on synthetic data is available at prism.healthkey.ai.

Acknowledgments

Thank you to HealthTree for funding and feedback. Thank you to advisors Steve Labkoff and Yuri Quintana for guidance and insight.

References

1. Observational Health Data Sciences and Informatics. The Book of OHDSI. 2021. ohdsi.github.io/TheBookOfOhdsi
2. OHDSI Oncology Working Group. OMOP CDM Oncology Extension. ohdsi.github.io/CommonDataModel/oncology.html
3. Zong N, et al. Deep learning-based feature extraction for clinical phenotyping using EHRs. Int J Mol Sci. 2022;23(19):11834.
4. Jin Q, et al. Matching patients to clinical trials with large language models (TrialGPT). Nature Communications. 2024;15:6342.
5. Smith A, et al. TrialMatchAI: AI-driven patient-to-trial matching platform. Nature Communications. 2026;17:1024.
6. CI4CC. Large Language Models for Clinical Trials (OncoLLM). CI4CC Workshop Proceedings, 2024.
7. Golozar A, et al. Introducing ARTEMIS: Advanced Regimen Detection. OHDSI Symposium, 2023.