Last EHR

Most AI layers over clinical data store a copy of what they touch — creating a second place where patient records live and a second compliance surface to defend. Last EHR takes the opposite approach: it stores no patient data of its own, runs as the authenticated Medplum user, and delegates all access control to your existing Medplum AccessPolicy. The core workflow is four FHIR tools — search patients, open a chart (conditions, allergies, medications, observations, immunizations, notes), add a free-text note, record an observation — surfaced through a chat interface. Write operations never execute silently: the agent proposes a change, an approval card renders exactly what will be saved, and the record updates only after explicit confirmation.

The approval gate is the design decision that separates this from a generic LLM-over-FHIR wrapper. The agent is visible throughout — you can see every tool call it makes — and the two write tools require a deliberate click before anything reaches the chart. That same constraint is what makes it safe to hand to a clinician during a prototype phase: the agent cannot act faster than the person reviewing it.

Last EHR fits one scenario well: a team already running Medplum that wants to add AI chart assistance without standing up a separate data store or building approval logic from scratch. It does not fit teams that need more than four FHIR operations, a backend other than Medplum, or multi-step workflows where the agent hands off to another agent. The vendor states a managed tier with hosted Medplum and a signed BAA is in development; self-hosting under Apache-2.0 is the path available without waiting.

The same four tools also run as an MCP server, connecting to Claude Desktop, Claude Code, or any MCP-compatible client. The MCP surface is read-only by default, which means chart interrogation without write risk for teams that want AI access but are not ready to gate approvals in a production workflow.