Headless EHR vs traditional EHR: who owns each layer of your product?
A headless EHR is a backend without its own clinician screens: your team builds the interface on its APIs. A traditional EHR ships interface, workflow and data as one product. The useful comparison is not the feature list but who owns each layer, which certification your code inherits and what you must prove before you sign.
Who owns each layer in a headless EHR vs a traditional EHR?
Quick answer
A headless EHR comparison should start with layer ownership: with a traditional EHR the vendor owns the interface, workflow, data and certification; with a headless EHR backend you own the interface and workflow and must prove its APIs cover what you need. Agnotic Technologies builds that interface layer and runs the proof before you sign.
| Criterion | Traditional EHR | Headless EHR |
|---|---|---|
| Clinician interface | Vendor | You build and maintain it |
| Workflow engine (tasks, orders, routing) | Vendor, configured by you | Usually you; check what the backend provides |
| Clinical data store | Vendor | Backend vendor |
| FHIR read API for patients and populations | Vendor, where certified to 170.315(g)(10) | Backend vendor; confirm the certification listing |
| Write APIs | Vendor-specific and often limited | The backend's main surface; prove each one you need |
| Certification scope | The vendor's certified product | The backend's certified modules only; screens you build are outside its certification |
| EHI export (170.315(b)(10)) | Vendor's export function | Backend's export, exposed through your interface or admin tools |
| E-prescribing | Built in | Backend service, a third-party module or your integration |
| Billing hooks | Built in or vendor modules | Your integration to billing and clearinghouse systems |
| Terminology | Vendor-managed | Backend-managed or your terminology service; confirm which |
| Audit log | Vendor's log and reports | Backend's log for API calls, plus your log for UI actions |
| Upgrades | Vendor's release schedule | Backend API versions plus your own release schedule |
What they are
What is Traditional EHR
A traditional EHR is a complete product: clinician screens, workflow, clinical data store, billing hooks and e-prescribing from one vendor, certified as that vendor's product. You configure it and integrate with it, but you do not replace its interface.
What is Headless EHR
A headless EHR backend, also called an API-first EHR, stores clinical data and runs core services behind FHIR and vendor APIs, and leaves the clinician and patient interfaces to you. You own the product experience; the backend vendor owns the data platform and whatever it has certified.
Key differences
What does the backend's certification cover, and what falls on your interface?
ONC certification applies to the Health IT Module that was certified. When your interface replaces the vendor's, the criteria that describe user actions still need a way for users to perform them. 45 CFR 170.315(b)(10), for example, requires that a user can create an export of all of a single patient's electronic health information at any time, without further developer help. Ask the vendor how each certified criterion is exercised when their screens are not in use.
Why are write APIs the first thing to test?
45 CFR 170.315(g)(10) requires certified APIs to respond to requests and searches for single and multiple patients using US Core, register apps and connect them securely. It does not require writes. Charting, orders and task updates in a headless build depend on the backend's own write APIs, so list every write your workflow needs and prove each one in a sandbox.
What does US Core coverage tell you?
The (g)(10) criterion points to the mandatory capabilities in the US Core Server CapabilityStatement, and the current US Core release published by HL7 is 9.0.0. A backend that advertises a recent US Core version gives your interface a predictable read model; check which version and which profiles its capability statement actually declares.
Where does a fully custom EHR fit?
A fully custom EHR owns every layer, including the data store and any certification you need. It is the most control and the most work. Most teams that reach for it really need a custom interface and workflow on a backend they do not run; for the full build, extend or buy question, see our custom EHR software development page.
Should you build on an open source headless EHR platform yourself or with a partner?
Build on an open source headless EHR platform yourself only if your team can run FHIR servers in production, configure profiles and SMART scopes, and patch and upgrade the platform for years; otherwise split the work with a build partner. Agnotic Technologies takes on the build and operating tasks your team cannot staff. When you self-host, your team or partner owns hosting, patching and backups, and you need a BAA with the cloud provider that hosts the ePHI. If you use the platform vendor's hosted service, the vendor runs hosting and signs the BAA for it. Platform version upgrades follow the open source releases either way, and someone must test your interface against each one. FHIR profile and SMART scope setup, and the clinician interface itself, are build work for your team or a partner. Certification gaps, the criteria your product needs that the platform has not certified, stay with you whoever writes the code. For the general staffing choice, see our in-house development vs outsourcing comparison.
When to use each
When to use Traditional EHR
- Your clinicians' workflow is close to the vendor's standard workflow.
- You need certified functions on day one and do not want to own any of them.
- Your differentiation is in services or care model, not in the clinician software.
- You will extend through apps and integrations rather than rebuild screens.
When to use Headless EHR backend
- Your care model needs screens and workflows no packaged EHR offers.
- You want one data platform behind several products or channels.
- You have, or will hire, a team to own the interface layer long term.
- You can verify the backend's APIs cover every write your workflow needs.
What should an API-first EHR proof of concept test?
1. Write APIs. Create and update the records your first release writes, such as encounters, notes, orders, problems and tasks, and read them back through FHIR.
2. US Core coverage. Compare the backend's capability statement with the profiles and search parameters your interface needs.
3. SMART launch. Run an EHR launch and a standalone launch with the scopes your apps will request, using the HL7 SMART App Launch framework.
4. Bulk export. Run a group export for a test population and time it on realistic data.
5. Audit log access. Confirm you can read API audit events for a patient and join them with your own interface log.
6. Business associate agreement. Get the BAA terms and the hosting details in writing before any ePHI is loaded.
7. Data export on exit. Run the single-patient and population EHI export, then load the result into a test system to prove you can leave.