A headless EHR for modern clinical teams
A headless EHR keeps your clinical data as FHIR behind an API, so you own the interface. Last EHR is the open-source AI agent layer you run on top: it reads the chart and makes approval-gated writes, scoped by your access controls.
What is a headless EHR?
A headless EHR is an electronic health record system where the clinical data layer is separated from the user interface. The backend stores patient records as standard FHIR resources and exposes them through APIs, while you build the frontend, screens, and workflows yourself.
Because EHR and EMR are commonly used interchangeably, you'll also see this called a headless EMR. The concept is identical. The point is the same either way: own your product experience, and let the platform handle the storage, standards, and compliance.
Headless EHR vs. a traditional EHR
Traditional EHR
Headless EHR
Why teams build on a headless EHR
FHIR-native and interoperable
Own your experience
Add AI agents
Compliance at the platform
Headless EHR options: open source and commercial
The category is small but real, and the options differ more in philosophy than in feature lists. A non-exhaustive map:
- Medplum: an open-source, FHIR-native headless backend with hosted and self-hosted options; authentication, access policies, subscriptions, and audit come built in. This is the backend Last EHR runs on today.
- Aidbox (Health Samurai): a commercial FHIR server platform aimed at teams building products on FHIR.
- HAPI FHIR: the long-standing open-source Java FHIR server. A bare FHIR API; you assemble auth, tenancy, and tooling around it.
- Firely Server: a commercial FHIR server from one of the major FHIR tooling vendors.
- Canvas Medical: a developer-first EMR with APIs; closer to a full EMR with a programmable surface than a bare headless backend.
- Oystehr: an API-first healthcare platform, known for the open-source Ottehr telehealth project built on it.
- OpenEMR: a mature open-source EMR. Not headless-first, but it has APIs and a large installed base.
Offerings change; verify current capabilities and terms directly with each project. Last EHR runs on Medplum or locally on HAPI FHIR, and the FHIR calls are the seam where other backends could slot in later.
Adding an AI agent to a headless EHR
A headless backend changes what an AI agent can be. Because the chart is already structured FHIR behind an API, an agent can read it as data rather than scraping a UI, and its writes can be bounded by the backend's own access control instead of trust.
That is exactly what Last EHR does: a chat agent with four FHIR tools where every write stops at an approval card before it touches the chart. Read how approval-gated writes work, how the agent turns FHIR resources into chart context, or how to add it to a Medplum project.
Frequently asked questions
What is a headless EHR?
A headless EHR is an electronic health record system where the clinical data layer (patient records, FHIR resources, authentication, and compliance) is decoupled from the user interface and exposed through APIs. Instead of a fixed application, your team builds the exact frontend and workflows you need on top of a managed, standards-based backend.
Is a headless EHR the same as a headless EMR?
In practice, yes. The terms EHR (electronic health record) and EMR (electronic medical record) are often used interchangeably, so a 'headless EHR' and a 'headless EMR' describe the same idea: an API-first clinical backend you build your own experience on. Last EHR is the AI agent layer you run on top of one.
What's the difference between an EHR and an EMR?
An EMR is essentially the digital version of a single practice's paper chart, used internally. An EHR is broader: designed to share a patient's record across providers and organizations. For modern, interoperable systems the two terms are frequently used as synonyms.
How is a headless EHR different from a traditional EHR?
A traditional EHR ships a monolithic application with a fixed UI and workflows you have to adapt to. A headless EHR gives you the data, APIs, and compliance, and lets you own the interface. You build the frontend your team needs and add AI without waiting on a vendor's roadmap.
Is a headless EHR HIPAA compliant?
A good headless EHR handles the heavy compliance work (HIPAA-oriented infrastructure, audit logging, access controls, and data residency) at the platform layer, so your application inherits it. Overall compliance still depends on how you build and operate the experience you put on top.
Can I add AI agents to a headless EHR?
Yes. Because the data is API-first and FHIR-native, you can connect AI agents that read and write structured clinical data. Last EHR is one such layer: it searches patients, opens a chart, and makes approval-gated writes (add a note, record an observation) scoped by your access controls.
Are there open-source headless EHR options?
Yes. Medplum is an open-source, FHIR-native headless backend with hosted and self-hosted options. HAPI FHIR is a long-standing open-source FHIR server you can build on. OpenEMR is open source but a full EMR rather than headless-first. Commercial options include Aidbox, Firely Server, Canvas Medical, and Oystehr. Last EHR is not a backend at all: it is an open-source AI agent layer that runs on top of one. Medplum is the supported authenticated path; HAPI, Firely Server, and Aidbox adapters ship for synthetic evaluation only.
Build on Last EHR
Last EHR is open source and self-hosted. Run it on your Medplum, bring your own model key, and add an approval-gated AI agent to the chart.