I. The state of the field
I have worked on more than twenty electronic health record systems. The story is always the same.
eClinicalWorks is a technical nightmare that would scar a veteran programmer. The APIs are unuseable, the platform is unuseable, and everything is expensive - but and they have good RPA security, but everyone has had to RPA bits and pieces of their workflow to integrate with them. RPA is the process of figuring out how a user uses a platform, and automating it with code - Robotic Process Automation. (Their support is fast, and I appreciate them for it, but they often do not know what's happening, to the point I've had to personally correct them.)
Even newer softwares such as NextGen are redundantly designed with anti-patterns in their APIs - they offer multiple ways on the same page to do the same thing, and none of them work as expected because the API anti-pattern will expect you to hit save on information instead of saving as you type, and this API pattern will send the entire data block in one go.
Athena cannot handle simple URL routing - a page refresh sends you back to the dashboard, so you have to frame refresh. I built out Chrome Extensions while working on Athena to help me do this, and to poll. I do not work at or with Athena.
Epic is called the gold standard, and it is also the single largest contributor to clinician burnout in the country after dealing with insurance.
Smaller and newer systems are not categorically better. Kipu loads every patient image at once. Phoenix ships a desktop app that feels like it was compiled in 1992. Elation has its own quirks that reveal themselves the first time you try to do something non-obvious. Though their patient facing products are often better.
These are not isolated failures. They are the predictable output of a category that has lost its way.
II. The real diagnosis
It is tempting to blame the user interface. Some interfaces are worse than others, but the interface is a symptom, not the disease. The disease is that electronic health records are trying to do too much for too many masters, and the person sitting in front of the screen - the provider - is the last person served.
Every mature EHR is, simultaneously: A clinical documentation tool. A billing engine. A compliance reporting system. A scheduling application. A pharmacy interface. A lab interface. A legal record. A population health dashboard. A patient portal. A messaging system. An analytics platform. A credentialing database. A revenue cycle tool.
This results in one of three patterns: Frankestinian models of aquiring smaller startups and stiching them on poorly (eg. I can't name examples because they're all friends, but maybe I can name a more archaic systems, Allscripts acquiring Eclipsys for inpatient, Practice Fusion for outpatient, dbMotion and Jardogs), building massive modules inhouse (eg. Epic), or building Version Twos of everything (WebPT has two versions I think, or HelloPatient. ESO has ESO billing and Logis. CentralSquare has like 5 versions of their TriTech platform.)
This is because no single application can be all of these things well. So none of them are. The result is what users experience every day: software that is feature-rich and utility-poor, where every screen has been negotiated into existence by a different stakeholder, and no stakeholder is the clinician. And TBF, with massive QA teams it is fairly simple to just go on and remove apparent bugs, but a poor UX is still a bug.
Don't get it twisted: Epic did not become dominant because it is pleasant to use. It became dominant because it is the only system that can absorb the full weight of the American healthcare regulatory stack at the scale of a large health system. That and Judy Faulkner being a genius who was both early, and eventually brutal. This is all a real accomplishment, but it comes at a real cost. The cost is that small clinics and NGOs cannot afford Epic, so they are either pulled into the orbit of larger systems that can, or they get left behind on inferior software from which something as simple as referrals can be hard.
Either way, the EHR market is functioning as a consolidation mechanism in American healthcare in one or few directions. Every cohort of startups have a few working on EHRs, but few succeed, either by focusing on a speciality, or focusing on a part of the workflow current EHRs don't do well (so could be anything, really).
Software is deciding which clinics survive as independent institutions. That is not a UX problem anymore, no. I propose this is a structural problem, and it is downstream of how we have chosen to build these systems. As these expand, with Amazon One Medical-esque Starbucks-y models, and Sollis Health-esque Boutique models, we're at a crossroads where EHRs, PE, Big Corps, and Funds are all forcing healthcare to unite. Will this mean Health Record Exchange becomes easier? What about scheduling Interfacility Transfer? Organ Donations? If so, is it so bad? If it's not bad, why do providers generally dislike it? Why do these companies fire local staff? Cost cutting, btu at what cost? Staff is unhappy, both new and old, patients lose their PCPs and familiar faces, and staff has to deal with overhead of taking care of a massive transition. Lifepoint, Steward, Summit etc. are popular examples, but these happen everywhere. The system is slowly becoming hostile to care. And we've not even talked yet about insurance.
III. Essential complexity versus accidental complexity
The most dishonest thing we could do here is pretend the regulations are the problem. They are not, or at least most of them are not. And some of them (I will argue for this despite it increasing the grunt work for my startup), are extremely lax and need to tighten up, a la in the case of compliance automation startup, <redacted> - but practically all healthcare software companies, and compliance startups.
Look, HIPAA exists because patient information is sensitive and people have been harmed by its exposure. I think HIPAA is too lax for software, it needs tightening. It is completely self-audited currently. It needs third party, same state auditing. A bit European of me, but I believe patient data should be held with highest regard. People don't know the dangers of it leaking - it can range from fraud, to death, to companies illigitemetly acquiring it and using it for advertisements.
The information blocking rule under 45 CFR Part 171 exists because vendors and health systems were actively hoarding patient data and charging rent on access to it. We will talk more about this.
MIPS and MACRA exist because fee-for-service medicine created perverse incentives that value-based payment is at least attempting to correct. Audit trails exist because a medical record is a legal document and will be subpoenaed. E-prescribing rules for controlled substances exist because of a decade of prescription drug deaths.
These are load-bearing regulations. Remove them and people get hurt.
The problem is not that compliance is required. The problem is how compliance shows up in the clinician's workflow. MIPS does not force an EHR to interrupt a physician with a popup about smoking cessation in the middle of a note. The rule requires that the measure be captured and reported. How it gets captured is an architectural decision, and almost every current EHR has made that decision badly - by pushing compliance burden onto the clinician's screen instead of absorbing it into the system's own documentation pipeline. This results in a string of hiring. For every provider, there are 1.6 admin staff. For every provider, there are 2.7 billing staff. These are poorly dervied numbers, but directionally correct. Shouldn't this number be way down?
I propose that this is the distinction that the entire rest of this argument hangs on:
Essential complexity is complexity the world actually has. HIPAA rules. Billing codes. Controlled substance requirements. The fact that a chart is a legal record. The fact that healthcare involves dozens of specialties with genuinely different documentation needs. You cannot reasonably design this away. Any honest system must carry it.
Accidental complexity is complexity we invented. Monolithic architectures that force every function through the same interface. UIs designed by committees. The assumption that one application must do everything. The conflation of the system of record with the system of work. The belief that a clinic of four has to run the same software as a health system of forty thousand. The practice of surfacing every regulatory checkbox to the user rather than handling it in the pipeline. The idea that compliance is something a human does, one field at a time, instead of something a system produces as a byproduct of good documentation.
Almost every complaint a clinician has about their EHR is a complaint about accidental complexity that the vendor has convinced them is essential. It is not. It is a choice.
IV. HIPAA should be verified, not attested
A related point on the regulatory stack itself: HIPAA is currently self-attested, and it should not be.
Compare the way SOC 2 Type II works. An independent auditor (sometimes even an outsourced company abroad) reviews your controls against a defined framework over a period of months, produces a report, and the market treats that report as meaningful. It is not perfect - far from it, but it is a real external check. A SOC 2 report means something because an auditor's name is on it.
HIPAA does not work this way. A covered entity or business associate signs a BAA, implements controls it believes are adequate, and carries on. Enforcement happens reactively, after a breach, via the Office for Civil Rights. The incentive structure rewards organizations for looking compliant rather than being compliant, because nobody is actually checking until something goes wrong.
HIPAA should be verified the way SOC 2 Type II is verified — ideally by an agency of the U.S. government rather than a patchwork of private auditors - and it should be tax-funded, because patient data protection is a public interest rather than a commercial one. Make the audit real, make it recurring, make it binding. That single change would do more for patient privacy than another decade of breach notifications.
V. AI belongs in the compliance pipeline, not in the exam room
If compliance is the tax, AI is the mechanism for paying it without the clinician noticing.
Most regulatory reporting is not creative work. It is structured extraction from unstructured documentation. Did the visit include depression screening? Was tobacco use assessed? Was a care plan updated? Was the diagnosis coded correctly? A modern language model can answer these questions from a visit note with high accuracy, populate the required fields, mark the positive and negative attestations, and present the completed package to the clinician for a single approval step at the end.
This is not a speculative capability. The models are good enough now. What is missing is the architectural will to use them as the filter between the clinician and the bureaucracy, rather than as another feature bolted onto the same overloaded interface. The correct pattern is: clinician documents the visit in natural language, the system extracts everything compliance needs, the clinician reviews and approves, done.
The human stays in the loop for the part that matters - approval - and is released from the part that does not - filling boxes. This could be a Scribe integrated to the EHR, but I will define and defend external Scribes rather than internal ones later.
VI. System of record versus system of work
This is the architectural claim the rest of the manifesto depends on, and it is worth saying plainly.
A system of record is the authoritative store of truth. For a patient, it is the longitudinal chart: every encounter, every diagnosis, every medication, every lab. It has to be durable, auditable, legally defensible, and canonical. It is the thing that gets subpoenaed. It should be boring, stable, and slow-moving.
A system of work is what a human uses to get a task done. For a clinician, the task might be seeing a patient in clinic, reviewing a panel of inbox results, running a group visit, doing a telehealth follow-up, or writing an appeal letter. Each of these tasks has a different optimal interface. A great interface for an in-person visit is a terrible interface for inbox triage.
Current EHRs collapse these two layers into a single application. The system of record and the system of work are the same piece of software, with the same UI, sold by the same vendor. This is the original sin. It is why the interface is always a compromise, why no single workflow is excellent, and why switching vendors means rebuilding your entire clinical operation.
These layers should be separate. The system of record should be one thing -- ideally something close to a utility, with strong guarantees about data integrity, portability, and standards compliance. The system of work should be many things, built by many teams - sometimes not even from the same company, specialized to different clinical contexts, and free to iterate rapidly without putting the chart at risk.
The current EHR vendors are the wrong organizations to build the system of work. They are too large, too slow (even when fragmented into teams - for fuck's sake, eClinicalWorks has two different teams for clinical and scheduling, and neither care about each other), too entangled with enterprise sales cycles, and too committed to the revenue model that treats every new workflow as an upsell. System-of-work innovation will come from startups. It has to, because the incumbents cannot move fast enough, and the clinicians they are supposedly serving cannot wait another decade.
VII. The integration problem, which is where this goes next
If system-of-work tools are going to be built by startups, and if the system of record is going to remain where it is for the foreseeable future, then the entire game comes down to the interface between them. That interface is supposed to be FHIR.
FHIR is the standard. It is mandated. 45 CFR Part 171 makes information blocking illegal, 45 CFR 170.215 specifies FHIR R4 with the US Core Implementation Guide as the API standard that certified health IT must support, and every major EHR publishes a FHIR endpoint. On paper, the integration problem is solved.
In practice, it is not. The FHIR implementations across major vendors are inconsistent, incomplete, and in some cases actively hostile to the third parties that depend on them. The spec allows enough flexibility that two compliant implementations can be mutually unusable. Rate limits, authentication quirks, undocumented behaviors, and silent field omissions are common. Integrators end up reverse-engineering the endpoints, maintaining vendor-specific adapters, and building compatibility layers that should not need to exist. The law says the pipes are open. The pipes are, at best, intermittently open, and nobody in a position to enforce the law has the technical depth to tell the difference.
Next Post: The FHIR storm consumes us all