Open source · Alpha
Search patients, read their charts, and draft notes, observations, and follow-up tasks. Review each proposed change before it is saved to your FHIR backend.
Last provides the chart tools and review workflow. Connect an assistant such as Grok Bot through MCP, or use the web app.
Browser demo: synthetic patients, no sign-up. Grok setup requires your own deployment or operator-approved pilot access.
Approve one write. Decline the next.
A 90-second edited recording of the fixed local synthetic walkthrough. Approve one proposed Observation, decline the next, and compare separate FHIR reads: one resource added after approval, and no further change after cancellation. No external model is called. Patient data is invented.
Read
The agent reads from your FHIR backend. Your backend controls access and remains the system of record.
Read results flag truncated searches, unsupported filters, and records that could not be retrieved, so the agent has context about what it has and has not read.
23 chart sections cover 25 of 27 readable resource types in US Core 9.0.0, including reference lookups. Medication and PractitionerRole remain gaps in verified coverage.
See chart coverageWrite
A request from the model is a proposal; approval is a separate step. Review in the web app, in a compatible chart MCP client, or in Last’s separate inbox for Assistant Work.
Draft a note, record a measurement, or create a follow-up task for a patient.
Check the patient and exact fields. Approve to continue, or reject to leave the chart unchanged.
An approved proposal creates a resource in your backend, subject to its permissions.
Current writes create notes, observations, and tasks. They do not edit or delete existing records. Web app and chart MCP writes carry the FHIR AIAST label. Assistant Work records the approval and a verified save receipt for its follow-up Task.
How approval worksThe approval step controls writes. In external model modes, chart reads are sent to your configured provider as context.
Use it
A chat interface with patient cards and write previews. Sign in with Medplum or launch from a patient’s chart through SMART on FHIR. Bring your own backend and model credentials.
To inspect the approval flow first, the local HAPI walkthrough uses synthetic data and needs no model API key.
Set up the web appGive Claude Code, Cursor, or another MCP client the same 4 chart-reading tools. The package is read-only by default. Enable writes separately; each proposal requires a client that supports human approval prompts.
npx -y @lastehr/mcp init --client claude-codeSupports Medplum and this repo’s local synthetic HAPI stack.
Configure MCPCompare FHIR MCP serversLet an external assistant draft a follow-up from a synthetic chart. You review the exact proposal in Last’s inbox. After approval, Last saves the Task and verifies the result; the assistant can check the receipt.
Tested with the Grok Bot desktop app over HTTPS MCP and OAuth. Self-host the synthetic lab or arrange access with the pilot operator. There is no public self-service enrollment yet.
Connect Grok BotGrok Bot
A 43-second edited walkthrough from actual Grok Bot and Last screenshots. Grok drafts a follow-up from a synthetic chart, a person approves it in Last, and Grok retrieves the saved Task receipt. The request needed a connector-name clarification. Patient data is invented. No one was contacted.
Support today
Last EHR is an alpha project. Medplum is the supported authenticated setup; the other adapters are for evaluation.
Read the support matrixThe repo includes an approval protocol draft and a conformance suite to test approval and persistence behavior. These checks do not establish clinical correctness or compliance.
Apache-2.0
Self-host Last EHR with your own FHIR backend and model. The source, setup guides, tests, and known limitations are public.
There is no managed service yet. Leave your email for updates if that changes.
FAQ
Run npx -y @lastehr/mcp@0.5.4 init --client claude-code, or npx -y @lastehr/mcp@0.5.4 init --client cursor. The Claude Code command prints a claude mcp add line. The Cursor command prints JSON for ~/.cursor/mcp.json or .cursor/mcp.json, including type stdio. Point that server at a FHIR backend you operate: a Medplum access token (MEDPLUM_ACCESS_TOKEN), or MEDPLUM_CLIENT_ID and MEDPLUM_CLIENT_SECRET, or this repository's local HAPI stack with FHIR_BACKEND=hapi and FHIR_BASE_URL such as http://localhost:8080/fhir. Claude or Cursor supplies the model. The MCP server talks to the FHIR server. Start with synthetic records. Setup: https://www.lastehr.com/docs/mcp
Only the public Epic FHIR sandbox, and only with the experimental adapter flag LASTEHR_EXPERIMENTAL_FHIR_ADAPTERS=1. The MCP package selects that sandbox with LASTEHR_BACKEND=epic. The web app selects it with FHIR_BACKEND=epic and the same flag. A write still waits for a person to approve it. The sandbox does not support delete, so an approved Observation stays on that shared sandbox. This is not a connection to a production Epic system. Setup: https://github.com/cbetz/last-ehr/blob/main/docs/adapters/epic-cerner.md
Writes are off until LASTEHR_MCP_WRITES=proposal. That profile can create a note (Communication), a measurement or a linked correction (Observation), or a follow-up task (Task). Each write pauses until a person approves it in a client that supports MCP elicitation. Approve sends that proposal to the FHIR server. Cancel, or no answer, saves nothing. A client that cannot show the prompt is not offered the write tools. The web app shows the same decision on an approval card. The FHIR server can still reject the write. Approving saves the proposal. It does not review the proposal for clinical correctness.
No. The public demo and the local HAPI walkthrough use synthetic patients. The Epic and Oracle Health paths use those vendors' public sandboxes and their synthetic sandbox patients. Do not point this alpha software at real patient records while you are evaluating it.