Clinicians will build their own UX on top of headless EHRs. The vendors will resist, then capitulate.
The EHR-centric architecture loses to API-driven cores with clinician-built UX. Existing EHR vendors will resist, then capitulate, then acquire. The architectural decision a CIO makes today determines whether they capture or pay rent on this shift.
For thirty years, the EHR vendor has owned both the data layer and the user experience layer of the provider organization’s clinical IT. Epic, Oracle Health (Cerner), Meditech, Athenahealth, eClinicalWorks. The user interface was tightly coupled to the underlying data model — clinicians worked inside the EHR’s native screens, typed into the EHR’s native forms, and complained about the EHR’s native workflow design. The complaints were perpetual; the architecture was unchallenged. The vendor controlled the workflow because the vendor controlled the only interface to the data.
That coupling is breaking. Three forces — open APIs (FHIR, USCDI), clinician-grade development tools (Microsoft Power Platform, internal data products), and AI-native interfaces (ambient scribes, voice agents, Copilot in clinical workflow) — are pulling the UX layer apart from the data layer. Within five years, leading provider organizations will run their EHRs as headless data cores, with clinician-facing UX built independently and tailored to specialty workflow. The EHR vendors will resist this, lose the resistance, and capitulate by acquiring or partnering with the UX layer. The CIO who makes the architectural bet correctly today captures the value; the CIO who waits pays rent on it.
Why the EHR-centric architecture loses.
The clinician’s UX requirement is increasingly specialty-specific. The EHR vendor cannot ship 40 specialty UXs.
Cardiology, oncology, pediatrics, primary care, ED, surgery, behavioral health — each has a different workflow, different documentation requirements, different cognitive load. The EHR vendor’s economic logic forces a generic UX across all of them. The decoupled architecture lets each specialty have its own UX without the data fragmentation that previously implied. The clinical adoption math runs in favor of decoupling.
AI-native interfaces are forcing the issue.
Ambient scribes (Abridge, Suki, Nuance DAX), Copilot in clinical workflow, agent-driven documentation — all of these sit alongside the EHR rather than inside it. The clinician’s workflow already crosses the EHR boundary multiple times per encounter. Once the workflow crosses the boundary, the EHR’s claim to own the UX layer is half-broken. Five years from now it will be entirely broken.
Open APIs make the architecture cheap.
FHIR is now mandatory for ONC-certified EHRs. USCDI v3 covers most clinical data elements. The technical lift to build a custom UX on top of an EHR is now closer to a 90-day project than a 90-month one. The cost curve flipped between 2020 and 2026, and the architectural inevitability followed.
The EHR vendors will resist, then capitulate, then acquire.
The first phase is resistance — terms-of-service language restricting third-party UX, certification gating, partner-program walls. The second phase is capitulation — “we are now an open platform,” rebranded API portals, vendor-blessed UX partners. The third phase is acquisition — the leading independent UX vendors get bought by the EHR incumbents at premium valuations. The CIO who built on the open layer in phase one captures the value; the CIO who waited buys the acquired version at the premium.
The strongest argument against this position.
The strongest counter is that the EHR vendor controls the certification, the compliance posture, and the standard of care attestation, and that decoupling the UX creates compliance risk. This is the resistance phase argument and it has real teeth — Epic and Oracle Health do hold significant leverage through certification and compliance integration. The honest response is that the leverage is finite, the regulatory direction is toward more openness, and the CIO who treats the vendor’s certification leverage as permanent will discover in 2030 that it expired in 2028. Time the decoupling carefully; do not refuse to make it.
Three things to do this quarter.
01 · Audit your FHIR API maturity. If your EHR doesn’t expose the data you need through FHIR, that is a procurement conversation now. Do not accept the “custom integration required” answer.
02 · Pilot a specialty-specific UX layer over your EHR’s FHIR APIs. Pick one specialty with high clinician dissatisfaction. Build the UX. Measure adoption and documentation time. The result will inform the broader architectural decision.
03 · Stop letting your EHR vendor define the AI strategy. Their roadmap is their roadmap, and it is structurally optimized to keep the UX layer locked to the data layer. Your roadmap should assume decoupling.