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 (PRogram for visually authored structural mapping, source-code-to-OMOP-concept mapping against the OMOP vocabulary tables, 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.
Clinical Data Extraction Workflow — admin tooling and AI flows for cleaning, extracting, and validating clinical data from documents. Documents enter from FHIR clinical notes, PDFs, or uploads, get parsed and classified, then have structured attributes extracted by an LLM with provenance back to the exact source span. A human reviewer verifies and corrects extractions in an admin UI before validated records are committed to the OMOP store. Covers NGS, FISH, cytometry, immunohistochemistry, and general phenotype testing.
Ingest pipelines for structured and unstructured clinical records. FHIR R4 pipelines pull from EHRs, labs, pharmacies, and TEFCA/QHIN sources with vocabulary mapping via Usagi conventions and structure mapping via Rabbit-in-a-Hat patterns. Paper pipelines handle faxes, scans, mailed lab reports, and patient-uploaded documents — OCR'd, structured, and mapped into the OMOP store with provenance preserved. Pluggable per data source.
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.
The stage between raw ingest and the PROMOP store, in three moves. PRogram is the visual mapper and code generator: structural mappings are drawn against the source schema and compiled into transformation code that routes FHIR resource paths to the right OMOP domain tables. Codes to OMOP concepts resolves every source code — ICD, SNOMED, LOINC, RxNorm, local lab codes — against the OMOP vocabulary tables, using Concept for standard targets, ConceptAncestor for hierarchy rollup, and ConceptSynonym for the strings that never match cleanly. 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, and DataQualityDashboard. 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.