What a headless EHR gives you

The backend and application have different jobs

Patient records

Your FHIR backend stores and serves the resources.

Identity and permissions

Your backend authenticates users and determines their access.

Interface and workflow

Your application decides how people find, read, and work with those records.

FHIR defines a resource and API format. The backend you choose determines its authentication, tenancy, auditing, and deployment requirements. An API does not supply a complete clinical workflow.

Where Last EHR fits

The agent searches patients, reads chart sections, and proposes notes, observations, and follow-up tasks. A person reviews each proposed write before it is sent to the backend. The records stay in that backend; Last EHR does not maintain a separate chart database.

For example, “Record a heart rate of 72 bpm for Maria Garcia” produces an Observation proposal. The reviewer sees the patient, measurement, and unit before choosing Approve or Cancel.

Choose a starting point

• Medplum: the supported authenticated path, including backend permissions and SMART launch.
• Local HAPI FHIR: a synthetic evaluation stack with a fixed walkthrough that needs no model key.
• Other adapters: Aidbox, Firely Server, and Oystehr have documented synthetic evaluation paths.

Last EHR is alpha software. Start with synthetic data. External model modes send chart context to the configured provider; review the data boundary and the support matrix before choosing a deployment.