What is Patient Memory?
The infrastructure layer that turns fragmented health data into a connected, reasoning-ready patient story.
What it is
Patient Memory is the infrastructure memory layer that turns fragmented health records into a connected, living patient story agents can reason over reliably.
Health data has never been more available. It's standardized, aggregated, and flowing across networks. And still, it doesn’t show the complete patient picture. A stack of records is not a patient story. A decade of encounters is not a timeline. Standardized is not the same as understood.
Patient Memory closes that gap. It ingests all types of health data, maps it to the clinical standards teams already trust, infers the relationships across it, deduplicates across sources, and structures events in time. It encodes each team's clinical reasoning rules, source-weighting, and trust hierarchies as configurable logic that travels with their product. The result is a full patient story, extended by every new encounter rather than rebuilt from scratch.
Agents built on Patient Memory reason over the same patient story across a multi-agent system. They don't reprocess records on every turn. They retrieve context that is already connected, resolved, and in time. Follow-ups stay cheap. Outputs stay consistent.
Others deliver the data. Patient Memory delivers the story.
Why not RAG or context stuffing?
Stuffing raw records into context: A typical FHIR bundle for a complex patient is 200+ KB of JSON. Even when it fits, the model sees hundreds of duplicate entries and cannot reliably distinguish the current medication dose from an outdated one, or a patient's own condition from their family history.
Vector search (RAG): Chunking clinical documents for embedding loses the relational structure. You can retrieve passages mentioning "diabetes," but you cannot answer "Which medications are prescribed specifically for the diabetes, versus for the hypertension?" That is a graph traversal, not a similarity lookup.
Patient Memory enables questions like:
Is this patient's CKD being adequately monitored, given that it's a complication of their diabetes?
Answering this requires knowing the complication relationship, the relevant monitoring labs, and whether those labs were ordered recently. This relational structure does not exist in fragmented raw data.
Key concepts
| Concept | What it is | Learn more |
|---|---|---|
| Entity resolution | 4-layer cascade that deduplicates clinical entities across sources into one node per real-world concept | Entity Resolution |
| Provenance | Every merge decision is auditable (contributing sources, conflicts, resolution strategy, confidence score) | Provenance and Auditability |
| Virtual File System | Path-based abstraction over the clinical graph; agents navigate it without upfront knowledge of the data structure | Virtual File System |
| Condition stories | Pre-assembled longitudinal narratives per condition: onset, active treatments, monitoring labs, complications | Condition Stories |
| Clinical knowledge base | Curated vocabularies that power relationship inference and concept normalization | Clinical Knowledge Base |