Changelog

Credential access levels

When creating a workspace credential you now choose an access level: Read or Read & Write. The server enforces the corresponding OAuth scope on every request — a Read credential is rejected with HTTP 403 on any endpoint that writes data (ingest, sessions, patient delete), and receives a WWW-Authenticate: Bearer error="insufficient_scope" header in the response.

Use Read credentials for AI agents and read-only integrations; use Read & Write credentials for server-side ingest workers. The access level is fixed at creation — delete and recreate a credential to change it.

See Manage Credentials and API Overview for the full scope breakdown.

Account profile and sign-in management

A new Profile page under Account lets you edit your display name. The Security page now also manages your linked sign-in methods: you can add or change a password, and connect or disconnect Google sign-in from the same screen.

Improvements

• Entity resolution no longer runs a second LLM pass after Layer 4 adjudication. Condition pairs that Layer 4 leaves ambiguous now persist as two separate facts instead of being re-evaluated through a context-aware merge step. This reduces ingestion cost and keeps the pipeline's decisions auditable at a single decision point.
• Passwords found in known breach databases are rejected at sign-up and password change.

Sessions API

Patient Memory now treats a conversation as a living object instead of a single batch job. You can upsert a session and append messages as the conversation unfolds, then generate memories from it on demand through a dedicated endpoint, decoupled from any particular lifecycle event. Memory generation is no longer tied to closing a session either: come back to an existing conversation later, add new turns, and generate memories from just what's new — without reprocessing everything that came before. Generation runs through a durable background job queue for reliable extraction, and you can list a session's memories with pagination and sorting to see exactly what it has produced so far.

Improvements

• Insurance and device entities normalize more robustly during ingestion, producing complete, well-formed records across a full batch.
• Active conditions lists now reflect only confirmed diagnoses, keeping encounter reasons and other non-condition entries out of the picture.
• Condition stories link medications based on clinical relevance rather than how closely their start dates align in time, giving a more accurate picture of what's related to a condition.
• A medication's status, dose, frequency, and route now resolve to the most recently documented value, so a patient's current state reflects the latest recorded change rather than whichever value was documented most often.

Memories

Patient Memory now learns from your agents' work. When a patient session closes, it automatically extracts and persists memories, building a memory graph that accumulates over time instead of resetting with every session. Those accumulated memories feed relationship inference between the concepts in a patient's context graph, so agents get connected context rather than isolated facts. And because memories surface directly in the Virtual File System alongside a patient's other documents, they're reachable through the same REST API and MCP server paths you already use — no new plumbing to write.

A richer resolved record

Ingestion now captures more of what's in a patient's documents. Social-history facts — things like smoking status, occupation, and living situation — are resolved and exposed in the Virtual File System, and every lab observation in a bundle is retained per LOINC code instead of collapsing repeated results. A patient's clinical picture stays complete instead of losing detail on the way in.

Improvements

• Clinical events are now searchable through the existing search API, so you can query across a patient's timeline, not just their documents.
• VFS path conventions are now consistent between the REST API and the MCP server, so you no longer need to translate paths when switching between them.

OAuth authentication

Patient Memory now authenticates every request with OAuth, across the entire app — the REST API and the MCP server alike. Patient data sits behind proper access control from the very first call, so you can build on top of it without standing up your own auth layer first.

Improvements

• Deleting a patient now cascades to all of their associated records, so removal is clean and doesn't leave orphaned data behind.
• Entity resolution produces fewer duplicate entities across repeated FHIR and CDA ingestion, so re-ingesting a patient's documents sharpens their resolved record instead of cluttering it.

Ingest and register patients through the REST API

Send FHIR R4 or CDA documents and Patient Memory parses and normalizes them for you, then makes the structured result available for retrieval — no manual mapping, no format wrangling. Register a patient, hand over their documents, and the resolved record is ready to read back.

Patient context graph

Clinical entities are resolved across all of a patient's documents, so overlapping or repeated records collapse into a single coherent view instead of piling up as duplicates. Patient Memory also infers relationships between those resolved entities, connecting them into a graph rather than leaving them as a flat list — so an agent reasoning over a patient gets context that's linked, not just deduplicated. Both run automatically on ingestion and keep improving as more documents come in.

Virtual File System

Every patient's resolved record is exposed as a structured, navigable Virtual File System, reachable through both the REST API and the MCP server. Instead of reasoning over raw documents, you (or your agent) can browse a patient the way you'd browse a filesystem — walking straight to the conditions, medications, or encounters you care about.

Workspaces

Workspaces give you tenant-scoped isolation out of the box, so every workspace's patient data stays fully separated from every other's — multi-tenant from day one, with no setup required.