Personal Health Record Architecture for Modular Extension.
A frame & foundation for patient health records. PHRAME is HealthKey.ai's modular technology stack for building patient-controlled, dynamic, longitudinal and complete health records and the applications that run on top of them. Built on open-source core components spanning data ingestion, normalization, identity resolution, and consent management, PHRAME powers patient dashboards, clinical trial matching, treatment navigation, research registries, and AI-enabled health services. PHRAME has been validated through HealthTree Foundation's work with 14,000+ oncology patients and a decade of longitudinal follow-up. It was also used to build CancerBot, a precision trial matching service finding trials for thousands of patients and multiple cancer foundations.
Most "PHR platforms" are either closed commercial silos, EHR add-ons, or research data lakes wearing a patient-facing skin. PHRAME is the opposite: an honest infrastructure stack designed from the ground up around the patient as data custodian, with the consumer-facing components and the research-grade longitudinal store as first-class peers.
CTOMOP is OMOP CDM 5.4 with the columns the standard was missing — validated with OHDSI architects after the existing CDM proved insufficient for individual clinical service against a real patient. You don't have to discover those gaps yourself.
FHIR R4 importers, LOINC/RxNorm/ICD-10/SNOMED/HemOnc vocabularies, SMART on FHIR, TEFCA/QHIN. The translation layers are done.
The PatientInfo projection is a flattened view of OMOP optimized for AI inference — designed for clinical trial matching and conversational interfaces.
Use CTOMOP alone as a longitudinal store. Use EXACT alone as a trial matcher against your own data. Use the FHIR Importers to feed any system. The seams are real.
No open-core bait-and-switch. The components we deploy are the components you get. Contribute back, fork, or vendor — the license is the contract.
Patient similarity via embedding vectors. Tri-valued trial eligibility (Eligible / Potential / Ineligible). Cancer-type-specific scoring plugins. Outcome data from real matches. You're not the first one through.
PHRAME is organized in three tiers: ingest (FHIR, PDF/paper, wearables & devices, and patient-reported importers), store (CTOMOP, with PatientInfo as its consumer-facing projection), and serve (EXACT for trial matching, the SoC service for clinical decision support, Analytics for population queries, plus your own apps). Every seam between them is a documented contract.
The longitudinal patient store. OMOP CDM v5.4 plus the columns we contributed back after validating gaps with OHDSI architects — gaps the standard doesn't cover because OHDSI's focus is analytical lakes, not individual clinical service.
Open-source clinical trial matching engine with tri-valued verdicts: Eligible, Potential, Ineligible. Honest about uncertainty. Outcome data from real matches against blood cancer cohorts.
The Standards-of-Care service — PHRAME's clinical decision support layer. Turns disease-specific guidelines (IMWG, IWCLL, Lugano) into computable phenotypes, and hosts cancer-type plugins for disease-specific scoring (FLIPI, R-ISS, and more). Extensible by design: drop in a plugin for your disease area.
FHIR R4 ingest pipelines for EHRs, labs, pharmacies, and TEFCA/QHIN sources. Vocabulary mapping via Usagi conventions, structure mapping via Rabbit-in-a-Hat patterns. Pluggable per data source.
Because not every record arrives as FHIR. Faxes, scans, mailed lab reports, and patient-uploaded documents get OCR'd, structured, and mapped into the OMOP store with provenance preserved. Critical for older oncology records and cross-system gaps.
Two ingest paths the patient controls directly: device feeds (Apple Health, Fitbit, CGMs) and patient-reported inputs (surveys, PHRofile assessments, narrative uploads). Both flow into the same longitudinal record as everything else — no second-class data.
Population and cohort analytics built on the OHDSI tooling (Achilles, Atlas, DataQualityDashboard) and extended with PHRAME-specific projections — bridging individual clinical service and population research without forking the schema.
Structured quality-of-life and symptom surveys — patient-reported outcomes (PROs) collected longitudinally and stored directly in the OMOP record. Covers disease-specific instruments (FACT-G, PROMIS, MPN-SAF) alongside custom survey kits, so PRO data lives beside lab and treatment data rather than in a separate silo.
PHRAME lives in a gap that nobody else is filling: between OHDSI's research-lake stack, EHR-tethered PHR add-ons, and closed commercial real-world-evidence platforms. Here is the honest map.
PHRAME is built on OHDSI standards. CTOMOP is OMOP CDM 5.4. We use Atlas, Achilles, DataQualityDashboard, Usagi, and Rabbit-in-a-Hat. We contribute back. But PHRAME is not OHDSI, and conflating the two misses the point of both projects.
Population-scale observational research. Analytical data lakes. Network studies across institutions. A schema that intentionally stops where individual clinical service begins.
Individual clinical service for one patient at a time. Patient-custodied data. Real-time consumer applications. The columns OHDSI deliberately left out because they fall outside the network-research mandate — but which any consumer PHR app needs.
| Stack | Patient custody | OMOP-native | FHIR ingest | Trial matching | License | Scope |
|---|---|---|---|---|---|---|
| PHRAME | ● First-class | ● CDM 5.4 + ext. | ● R4 native | ● EXACT, tri-valued | Apache 2.0 | PHR + research |
| OHDSI stack (Atlas, Achilles) | ○ Not the goal | ● Canonical | ◐ Via ETL | ○ Out of scope | Apache 2.0 | Pop. research |
| HAPI FHIR + custom | ◐ If you build it | ○ | ● | ○ Build yourself | Apache 2.0 | FHIR server |
| OpenMRS / OpenEMR | ○ Provider-centric | ○ | ◐ | ○ | MPL / GPL | EHR |
| Flatiron Health | ○ Curator-owned | ◐ | ◐ | ● Internal | Proprietary | Onc RWE |
| Tempus | ○ | ○ | ◐ | ● Internal | Proprietary | Onc + genomics |
| Apple HealthKit | ● Device-bound | ○ | ◐ Limited | ○ | Proprietary | Consumer device |
| CommonHealth | ● | ○ | ● | ○ | Apache 2.0 | Mobile PHR |
● full · ◐ partial · ○ absent. Comparison reflects published scope; capabilities evolve.
Both of these applications run on CTOMOP, EXACT, and the FHIR importers in production — not demos, not pilots. Real patients, real trials, real outcomes.
— AI-powered trial matching for cancer patients.
Only 2% of cancer patients enroll in clinical trials — not because they don't qualify, but because eligibility criteria are scattered across dozens of registries in clinical language most patients can't parse. CancerBot combines CTOMOP patient records with the EXACT matching engine to deliver personalized, jargon-free trial eligibility answers: exactly which criteria a patient meets, which are indeterminate, and why.
— from one diagnosis to infrastructure for 14,000 patients.
Jenny Ahlstrom was diagnosed with multiple myeloma at 43 and treated it like a startup problem. The result is HealthTree Foundation — a nonprofit connecting blood-cancer patients to treatment options, clinical trials, and peer matches across 7,900 hospitals. HealthKey supplies the infrastructure backbone: CTOMOP for structured longitudinal records, EXACT for trial matching, and the FHIR importers pulling from hospital systems nationwide. HealthTree provides what infrastructure can't: patient trust earned through community.
Pick the path that matches how much you want to own. The components are the same in all three — what changes is who runs them and who maintains the operational expertise.
— and contribute back.
— your tenant, your data, our ops.
— but only to push the core forward.
Code on GitHub. Discussion on Slack. Conversation by email.