The Case Against the Commercial EHR: When Healthcare Mistook Innovation for Infrastructure

I have spent a substantial portion of my career working with electronic health records. Not merely documenting in them as a nurse, but working behind them — building, maintaining, troubleshooting, integrating, upgrading, and trying to understand the enormous information ecosystem that exists behind the screen a clinician sees.

After enough years doing that, I have developed what may be an unpopular opinion: I am no longer convinced the electronic health record should be a commercial product.

At least, not in the way we have come to think of it.

This is not an argument against Epic, Oracle Health, MEDITECH, or any particular vendor. I have worked with multiple EHR environments, and every mature platform has things it does well. Nor is this nostalgia for paper. I have absolutely no desire to return to deciphering a physician's handwriting while wondering whether the medication ordered is metoprolol or something capable of summoning a demon.

Electronic records are here to stay. My question is different.

What if we have spent the last several decades innovating the wrong layer of healthcare technology? What if the foundational electronic health record should have become infrastructure rather than a product?

Sometimes We Replace the Plumbing to Get a New Faucet

Anyone who has worked behind a major EHR implementation knows how extraordinary a conversion actually is. From the clinician's perspective, the obvious things change: the login, screen, navigation, medication workflow, documentation tools, order-entry process, shortcuts, and countless other details. Years of muscle memory can disappear overnight.

But that is merely the visible portion.

Behind the screen, teams of analysts, interface engineers, informaticists, trainers, developers, database administrators, project managers, and clinical subject-matter experts may spend years preparing for the transition. Interfaces are rebuilt or remapped. Historical data are converted. Orders are redesigned. Downstream systems are tested. Reports are recreated. Devices are reintegrated. Workflows are reconstructed, and thousands of users are trained.

Then the new system goes live.

After all of that, something rather peculiar has happened. The laboratory still needs to send a potassium result. Registration still needs to communicate that a patient has been admitted. Radiology still needs an order. Pharmacy still needs medication information. Another hospital still needs to know what happened to the patient.

It would be too simplistic to say that an ADT message is merely an ADT message and leave it there. Considerable portions of healthcare's exchange layer have, in fact, been standardized. HL7 v2 gave healthcare common ways of moving many kinds of information, and FHIR is extending that work into modern API-based exchange. The deeper problem is that the information models, persistence, workflow configuration, application behavior, mappings, reporting, and dependencies surrounding those exchanges can remain deeply tied to particular implementations.

That is why changing the clinician-facing platform can propagate through so much of the enterprise.

The fundamental information problem, however, remains remarkably stable: get the right clinical information from A to B, preserve its meaning, and put it in front of the person who needs it.

We have somehow designed health information technology so that replacing the faucet can require replumbing portions of the building.

The Prestige-System Fallacy

There is another phenomenon I have watched for years. A prestigious health system uses EHR X. That organization has excellent outcomes, sophisticated operations, and a national reputation. Another organization looks at it and reasons, consciously or otherwise: They use X. They are excellent. If we use X, perhaps we will become more like them.

I think of this as the Prestige-System Fallacy.

A great healthcare organization may be great while using a particular EHR. That does not mean it is great because it uses that EHR. Research on EHR implementations repeatedly identifies leadership, governance, organizational culture, training, workflow design, user involvement, resources, and implementation strategy as important determinants of success.

A disciplined organization with strong clinical informatics, good governance, and engaged clinicians can make a competent EHR perform remarkably well. A dysfunctional organization can spend hundreds of millions of dollars implementing the market leader and emerge as a dysfunctional organization running a more expensive EHR.

Technology is an amplifier. Poor workflows become electronic workflows, redundant documentation becomes electronic redundant documentation, bad communication becomes another inbox, and poorly designed alerts become automated alert fatigue. A sophisticated EHR can digitize excellence. It can also digitize dysfunction.

Conversion Is an Intervention

One reasonable objection is that major EHR transitions do not necessarily produce measurable increases in mortality or catastrophic patient-safety events. A multicenter study of 17 hospitals undergoing EHR transitions, for example, found no significant short-term increase in mortality, readmissions, or measured adverse safety events compared with control hospitals.

That finding matters. It also establishes a rather low threshold for deciding whether replacing a major clinical information system was worthwhile.

Other research has documented deterioration in efficiency, increased documentation and ordering burden, workflow disruption, and increased task switching surrounding EHR implementations and transitions. Anyone who has lived through one is unlikely to find that surprising.

A major EHR conversion is not simply an IT project. It is an intervention performed on an entire healthcare organization. It changes how nurses document, physicians order, pharmacists verify, laboratory results move, clinicians communicate, records are retrieved, information is displayed, and people think about their work.

The appropriate question therefore should not merely be, Is the new EHR better? It should be: Is it sufficiently better to justify the disruption required to obtain it?

Stability Is a Feature

Healthcare technology loves the word innovation. We have innovation labs, innovation officers, innovation summits, innovative platforms, innovative workflows, and innovative interfaces. Innovation has become such an unquestioned virtue that resisting technological change can make someone sound vaguely Luddite.

Medicine, however, has another value that deserves equal consideration: stability.

The cockpit of an aircraft does not need to surprise the pilot every six months. Neither should the workstation of an ICU nurse. A clinician managing multiple unstable patients does not necessarily benefit because someone has discovered a more innovative location for the medication administration button.

Clinical semantics are admittedly more complicated than electrical outlets or internet protocols. Medicine changes. Terminologies evolve. New kinds of information appear, and our models of disease, treatment, genetics, imaging, monitoring, and decision support continue to develop. A clinical-information infrastructure can never simply be frozen.

But stability does not require stagnation. It requires recognizing that change itself imposes cognitive and operational costs, especially in safety-critical environments. Predictability is not the enemy of innovation. Sometimes predictability is a safety feature.

None of this is an argument against changing technology. It is an argument for deciding which technology ought to change. A stable foundation can make innovation above it easier, not harder. If the clinical information, its meaning, its provenance, and the mechanisms necessary to exchange it are durable, then replacing an interface, introducing a new AI tool, adopting a better specialty workflow, or even changing the primary clinical application need not require disturbing as much of the foundation beneath it.

The objective is not technological stasis. It is architectural separation.

The United States Has Already Admitted the Problem

It would be unfair to suggest that the United States has done nothing to standardize health information. Quite the opposite.

HL7, FHIR, USCDI, ONC certification requirements, the 21st Century Cures Act's information-blocking provisions, standardized APIs, health information exchanges, Carequality, CommonWell, and TEFCA represent enormous efforts to make information more portable and interoperable across organizational and vendor boundaries.

That progress matters. It also raises an uncomfortable question: Why has healthcare needed so much regulatory, technical, contractual, and organizational machinery to ensure that information generated in one electronic health record can meaningfully travel to another?

We created proprietary islands and then became extraordinarily good at building bridges between them.

The policy direction itself suggests that we increasingly recognize certain capabilities — exchange, access, portability, and common clinical data — as too important to depend entirely on individual vendor ecosystems. So the question is no longer whether healthcare should standardize portions of the core. We already are.

The question is how far that principle should extend.

This Is Not a New Technical Idea

Nor am I suggesting that health informatics somehow failed to notice this problem.

openEHR is an obvious example. Its architecture uses a stable reference model, clinical content models such as archetypes and templates, and specifications that allow health data to be stored separately from the applications that use it. openEHR itself describes one of its central principles as allowing health data to outlive individual software applications.

But openEHR is not the argument I am making.

I am not proposing that the United States adopt openEHR as its national EHR. Nor am I proposing a particular data model. The larger question is economic, organizational, and architectural: which portions of the contemporary EHR ecosystem should remain objects of commercial competition at all?

A technical architecture can help answer how information might be decoupled from applications. It does not, by itself, resolve switching costs, organizational disruption, governance, market concentration, workflow dependency, national infrastructure, or the institutional incentives that determine how healthcare technology is purchased.

Still, openEHR establishes an important precedent: durable clinical information does not inherently have to belong to the application sitting above it.

VistA Complicates the Argument — As It Should

The Veterans Health Administration provides another precedent, and a particularly useful one because it prevents an easy conclusion.

VistA grew from a publicly developed health information system into one of the most consequential EHR environments in American medicine. The VA has undertaken a modernization program to transition from its legacy VistA-based environment to the Federal EHR supported by Oracle Health. The VA describes that transition as moving from more than 130 VistA instances toward a single Federal EHR, with additional deployments continuing in 2026.

One could reasonably read that history as evidence against my argument. Publicly developed systems can age. They can accumulate technical debt, become difficult to modernize, fragment through local customization, and struggle to keep pace with changing expectations.

All true.

But VistA also raises the inverse question. If a clinical-information environment contains decades of institutional knowledge, workflows, clinical data, and operational dependencies, why must modernization ultimately take the form of replacing so much of the environment?

The lesson from VistA may not be that public EHRs work or that commercial EHRs work. It may be that monolithic clinical-information environments, regardless of who owns them, become extraordinarily difficult to replace precisely because too many layers have become inseparable.

That is closer to the problem I am interested in.

Epic Is Not the Villain

Any serious version of this argument also has to address Epic, and Epic makes a poor villain.

Healthcare organizations generally select Epic because it has built an extraordinarily comprehensive ecosystem. Its integration capabilities, interoperability, customer relationships, scope, and widespread adoption are genuine competitive strengths.

That success has also produced remarkable market concentration. According to KLAS's 2025 acute-care EHR market analysis, Epic gained a net 176 U.S. acute-care hospitals in 2024, bringing its footprint to roughly 42 percent of acute-care hospitals and approximately 55 percent of acute-care beds in that analysis. KLAS also identified switching costs as a barrier for some organizations that considered Epic but did not move to it.

None of that establishes that Epic is an unlawful monopoly, and I am not suggesting that it is. It illustrates something more interesting: EHRs exhibit powerful network effects.

As more organizations use a platform, that platform becomes increasingly attractive. More employees know it. More consultants support it. More third-party products integrate with it. More neighboring organizations exchange information through it. More clinicians have encountered it, and choosing it increasingly looks like the safe institutional decision.

Eventually, one argument for choosing the platform becomes, in effect, everyone else uses it.

American healthcare therefore appears to be moving toward a degree of standardization anyway. We may simply be achieving it through market concentration rather than architecture.

That distinction deserves far more attention than whether Epic itself is good or bad.

If healthcare is going to converge on common infrastructure, should that convergence occur because one company eventually wins enough of the market, or because we deliberately decide which portions of health information should never have depended on proprietary ecosystems in the first place?

Iceland: Useful, but Not a Blueprint

Iceland is often tempting as an international example because its national health-information infrastructure is far more coordinated than that of the United States. But it needs to be understood carefully.

Iceland is a country of roughly 400,000 people with a healthcare system, government structure, and scale profoundly different from ours. Its Saga EHR has historically had a dominant presence, while national infrastructure such as HealthNet Hekla has supported secure information exchange and national health services.

That complicates any simplistic picture of numerous interchangeable EHRs happily riding common national rails. It also makes Iceland more interesting.

Iceland demonstrates that national exchange infrastructure and substantial application concentration can coexist. Its lesson for the United States is therefore not “copy Iceland.” It is that some functions can be approached as national health-information infrastructure rather than recreated independently inside every institutional-vendor relationship.

Scale makes the American problem harder. It does not make the architectural question irrelevant.

Japan Is Asking the Question in Real Time

Japan may be the more useful example because it has not solved this problem and is currently deciding how to approach it.

Japan's Healthcare DX program is pursuing a nationwide healthcare-information platform, standardization of electronic medical record information, cloud-oriented modernization, and nationally defined requirements. In March 2026, Japan's Ministry of Health, Labour and Welfare published version 1.0 of standard EHR and claims-system requirements for clinics and small-to-medium hospitals. Those requirements include support for the national EHR information-sharing service and e-prescriptions, standard APIs, data portability, and cloud-oriented architecture. The ministry is also developing a certification framework around the specifications.

More broadly, Japan's Medical DX policy describes the national government as a hub for infrastructure through which medical information can be linked and shared nationwide.

That is importantly different from simply choosing one national EHR vendor.

Japan is attempting to define portions of the architecture, standards, exchange environment, and requirements nationally while allowing products to operate within that environment.

The contrast with the United States is striking. Much of our health-information infrastructure accumulated incrementally — institution by institution, vendor by vendor, interface by interface. Interoperability was subsequently layered onto systems that were not originally designed as components of a national longitudinal record.

Japan has an unusual opportunity to establish some of those requirements prospectively. It may succeed. It may fail. It will almost certainly discover problems that aren't apparent on a government roadmap.

But the experiment is worth watching because Japan is asking something closer to the question I am asking here: What should be standardized before another generation of systems is built on top of it?

Britain Provides the Necessary Warning

There is, of course, an obvious danger in moving from that observation to “government should build the EHR.”

Britain's National Programme for IT in the NHS should cure anyone of that temptation. Its history is more complicated than a simple story of government technology failure, but its cost, procurement difficulties, implementation problems, and eventual dismantling provide an important warning against assuming that national scale automatically produces good architecture.

Large centralized health IT programs can become cumbersome. Requirements can be imposed from too far away from clinical practice. Massive projects can become difficult to change, politically entangled, expensive, and vulnerable to exactly the sort of monolithic thinking I am criticizing in commercial systems.

Government ownership does not magically produce good architecture, nor does centralization. The goal should not be to replace one enormous proprietary ecosystem with one enormous public ecosystem.

The goal should be decoupling.

Make the Core Boring

Imagine instead that certain capabilities were treated as durable healthcare infrastructure: patient identity, core clinical data structures, terminology, provenance, auditability, portability, exchange, longitudinal continuity, authentication, and perhaps portions of consent and authorization.

Make those things standardized, secure, transparent, portable, and deliberately difficult to disrupt.

Then let commercial companies compete viciously above them.

Let Epic build the best clinician interface it can. Let Oracle Health build a better one. Let MEDITECH build another. Let startups attack specialty workflows. Let companies compete on clinical decision support, analytics, AI, ambient documentation, patient applications, research platforms, population health, visualization, automation, and technologies we have not imagined yet.

Innovation belongs at the edges. Stability belongs at the core.

This is not anti-innovation. It is an argument about where innovation creates the greatest value and where stability creates the greatest value. Standardizing a foundation does not require freezing everything built upon it. In fact, a sufficiently durable foundation can make experimentation above it less expensive because changing one layer does not require replacing the layers beneath it.

The Internet did not stop innovating because its foundational protocols became standardized. Quite the opposite. Stable protocols created a common environment upon which extraordinary competition and experimentation could occur. Clinical information is vastly more complex than internet networking, and the analogy should not be pushed too far, but the architectural principle is worth considering: standardization at one layer can enable innovation at another.

Instead of repeatedly spending enormous engineering effort rebuilding the machinery necessary to move and preserve basic clinical information, vendors could compete more aggressively over what clinicians and patients can actually do with that information.

The Record Must Survive the Application

There is one additional requirement I would put into that boring core because it is routinely overlooked: provenance.

The modern EHR is not simply a digital chart. It is simultaneously a clinical workspace, database, communication platform, billing instrument, compliance mechanism, quality-measurement system, decision-support system, audit system, legal record, interoperability node, research source, and increasingly an AI substrate.

Yet when the record leaves that environment, much of its history can become remarkably difficult to see.

A PDF may show what a note says while telling us much less about how that note became what it is. When was it created? When was it modified? When was it signed? Did information originate locally or arrive through an interface? Was it reconciled from another source? Was content copied forward? Was something generated or suggested by a machine? Which version was actually available to the clinician at a particular moment?

Those questions are increasingly clinical questions, and sometimes they become legal and evidentiary questions.

If we are going to define a durable clinical-information core, then we should not merely decide which facts survive when applications change. We should decide which evidence about those facts survives with them.

A standardized core that preserves a diagnosis but discards its provenance has preserved only part of the record.

The medical record is no longer merely a document. It is a distributed information system from which documents are rendered. Any future architecture should be designed accordingly.

Who Owns the Boring Core?

This is where the argument becomes much harder.

Who defines it? Who governs it? Who pays for it? Who updates it when medicine changes? How do we prevent standards from freezing bad ideas into place? How do we avoid creating a national cybersecurity target? How do we migrate decades of legacy information without producing the very disruption this proposal is intended to reduce?

I do not have neat answers to those questions, and I would distrust anyone who claimed to.

The solution might involve government standards, nonprofit standards organizations, regulated utilities, commercial infrastructure operating under open specifications, public-private governance, or some combination of them. Existing institutions and frameworks — HL7, USCDI, ONC certification, FHIR, TEFCA, and others — mean we would not be starting from zero.

The objective matters more here than pretending I can design the implementation in an essay: the clinical information should outlive the application.

Changing the software through which a clinician interacts with the record should not require rebuilding the informational foundation underneath it.

What Are We Actually Buying?

For decades, American healthcare organizations have repeatedly asked some version of the same question: Which EHR should we buy?

Epic? Oracle Health? MEDITECH? Something else?

I increasingly wonder whether that is the wrong question.

The more interesting questions may be: Which portions of the electronic health record should we no longer have to buy? What belongs to the institution? What belongs to the vendor? What belongs to the patient? And what belongs to the infrastructure of healthcare itself?

Commercial EHR vendors have produced genuine innovation. Epic's success is not an accident. Government-designed technology is not inherently superior, and open standards do not magically eliminate difficult clinical semantics, organizational dysfunction, implementation failures, or bad software.

But none of those observations answers the underlying architectural question.

We have spent decades building, rebuilding, integrating, migrating, mapping, converting, testing, retraining, and eventually beginning discussions about the next replacement. Meanwhile, commercial consolidation may be producing through market forces some of the standardization we were reluctant to design deliberately.

Maybe the future is not another revolutionary EHR.

Maybe it is a durable clinical-information foundation that survives while applications compete above it — one that preserves identity, semantics, provenance, portability, and exchange regardless of which interface happens to be fashionable this decade.

Let Epic innovate. Let Oracle Health innovate. Let MEDITECH innovate. Let companies we have not heard of yet build things that make today's EHRs look primitive.

Just stop making healthcare rebuild the foundation every time we renovate the house.

Because the screen is not the system. The interface is not the information. And the document we eventually render from all of it is not, by itself, the record.

Those are representations — useful ones, necessary ones, and sometimes very good ones. But they are still the face the system presents to us.

Pull off the mask, and what is real is what remains underneath: the data, its meaning, its provenance, its history, and the relationships that make it intelligible.

That is the part that should endure.

Because when the contracts are signed, the interfaces rebuilt, the data converted, the clinicians retrained, and the consultants finally go home, the fundamental requirement will be exactly what it was before:

The potassium result still has to get from A to B.