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.
PHRAME is organized in four tiers: ingest (FHIR, PDF/paper, wearables & devices, and patient-reported importers), ETL pipeline (PRofile for data characterization, PRogram for vocabulary mapping, PResolution for patient-involved conflict resolution), store (PROMOP, with PatientRecord as its consumer-facing projection), and serve (EXACT for trial matching, the SoC service for clinical decision support, PRism 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.
Patient Record insights, statistics and measurement — 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.
Three components that sit between raw ingest and the PROMOP store. PRofile performs data characterization directly off incoming FHIR bundles — profiling resource completeness, value-set conformance, and data quality before any transformation occurs. PRogram generates the structural and vocabulary mappings from Rabbit-in-a-Hat (RIAH) specs, translating FHIR resource paths to OMOP domain tables and applying Usagi-derived concept mappings. PResolution surfaces conflicting data being ingested — e.g. contradictory diagnoses or overlapping medication records from different sources — and routes these conflicts to the patient for adjudication before the record is written.
The consumer-facing application layer — the surface where patients actually interact with their longitudinal record. Built on PatientRecord projections from PROMOP, the portal provides a unified view of diagnoses, medications, labs, and care history across every connected source. Includes conversational AI for navigating the record in plain language, trial-match results surfaced from EXACT, and care guidance from the SoC service. Designed as a reference implementation: deploy as-is or fork it as the foundation for a disease-specific PHR.
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. PROMOP 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.
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.