Previous post on why EHRs suck - good primer before learning about FHIR.
I. A short history of FHIR
FHIR stands for Fast Healthcare Interoperability Resources. It is a specification maintained by HL7 consortium that describes how healthcare data should be represented and exchanged over the web. There used to be HL7v1, that existed for.a brief period of time before being replaced by the favorite child, v2. That was 1989. Judy Faulkner founded Epic in 1979, with slow adoption, and there's a great podcast on this history by the folks at Acquired Podcast (Epic never diluted much, so bit ironic). In 2000s, when v3 was published, with it, it bought along CDA. CDA was adopted for document messaging, but v3 itself failed. Governments this time realized how important EHRs are, and launched the HITECH act to catalyze the mass adoption of EHRs. It is important to note, actual documents mostly lived as free text then in 1989, and in 2009 too. HL7 was mostly used for admin work - pharmacy, lab orders, scheduling etc.. Fax was the workhorse back then, and still is if you're dealing with insurance, hospitals etc.. In 2014, the new kid on the block, FHIR comes around. DTSU1, 2, STU3, and finally, R4. When vendors offer integations now (post-2020s), they mostly offer it via FHIR. But that's mostly for "resources" - Patients, Clinical Notes etc., the scheduling and such are still using 1987's HL7, sometimes wrapped in FHIR-like APIs.
You think we are done talking about inter-organizational standards, we are NOT done. We are not even close to done.
We now should briefly talk about X12, and insurances. I promised as much in our last article. X12 is not HL7. It is completely different. The only part that's similar is both look like gibberish, and depend on very sensitive metalanguages.
It is a completely separate standards body, and it comes from the commerce world - the Accredited Standards Committee X12, chartered by ANSI in 1979 - and it governs the electronic data interchange formats used for insurance transactions in the United States. Where HL7 handles clinical and operational messaging inside the hospital, X12 handles the money. Claims, eligibility checks, prior authorizations, remittances, enrollment - every interaction between a provider and a payer runs on X12.
HIPAA, in 1996, mandated X12 as the standard for these transactions. That mandate is why every EHR, every billing system, and every clearinghouse in the country speaks X12. The specific transaction sets you end up dealing with are a small, predictable list, similar to how WiFi is IEEE 802.11, Claims are X12 837, denials are 835, and so on. Much like HL7, X12 is delimiter-driven. Delimiter driven is easy to parse and fast to transmit. The only non-sensical bit is X12 is extremely complicated to understand and the official spec is hidden behind a paywall. It is a public good, that is hidden behind a paywall. Excellent. (Can you tell I am a bit frustrated with the industry?)
A real 837 looks like a wall of ISA*00*...*00*...~GS*HC*...~ST*837*...~BHT*...~NM1*... and goes on for thousands of lines for a batch of claims. Nobody reads X12 directly. Every integration passes through a clearinghouse - Availity, Change Healthcare (before the breach - yes, we will talk of cybersecurity later), Waystar, Office Ally, Trizetto - whose entire business is translating between the provider's system and the payer's system, because no two payers implement X12 the same way. Some might decide to use some form of patient control number, others might decide something else. Some will tell you if the insurance is self-funded or not, others won't. Some will have location markers, others won't.
Now, there is a modernization of this called FHIR HRex, but I've literally never used it. I don't even know if it's truely an X12 replacement. I'm not pushing for API-fy everything, but at least make things more readable, less fragmented, etc. And lastly, there are some insurance companies who want mails, some have centralized portals, some old, some new, still better than independent portals. This further fragmentation means just checking someone's insurance eligibility is expensive, when it should be free. Young startups are trying to API-fy these clearinghouses and their ever changing policy documents, but it's such a massive task.
Imagine if there was a standardized version that allowed for all of this to happen. Well, at least all other medical providers use the same system.
Nope. Emergency Medicine (not operation rooms, think ambulances) have NEMSIS, and Fire Departments have NFIRS. Imaging is the most consistent, all of it happens over DICOM and everyone generally agrees on how to communicate. But DICOMs are massive. Dentistry EHRs don't talk well to normal EHRs, so if you have periodontitis, and you're diabetic, and your endo asks for more details for it, you should fuck yourself (just kidding, ask your doctor's office to mail your dentist, or call your dentist and ask for your chart, EMS folks do this well at handoffs, but would be easier if it was ALL FHIR). Don't worry, there's a standard (that no one uses) on how to integrate all these different systems, it's called IHE - Integrating Health Enterprise, and like most of healthcare admin, it's either to keep someone in job, or get someone promoted.
Drugmonkey of "Why Your Prescription Takes So Damn Long To Fill" would probably talk to you more about the standards of Pharmacy and how it integrates, but the short of it is, it's another standard.
All standards try to be general, but none of them are to the wider field.
So the real picture of modern healthcare data is:
Clinical side: FHIR in front, proprietary EHR databases behind, HL7 v2 still running the operational plumbing, C-CDA for document exchange, fax for everything that falls through the cracks.
Financial side: FHIR Da Vinci on top for the things CMS has mandated, X12 837/835/270/271 underneath doing the actual work, clearinghouses in the middle monetizing the gap between the standard and its implementations.
A system-of-work startup (introduced in the last essay) that wants to do anything real has to touch both sides. Reading a patient's chart is FHIR. Checking whether a visit is covered is X12 270. Submitting the claim afterward is X12 837. Getting paid is X12 835. If denied, you have to go request C-CDA based (relevant) documents from the EHR. Any application that pretends the FHIR side is the whole story is going to discover, the first time it tries to actually operate in an org, that half the integration work is on the financial side and FHIR does not help you there.
This is why the manifesto's argument cannot stop at "the EHR vendors should expose better APIs." The architectural separation between system of record and system of work is necessary but not sufficient. The system of work also has to traverse the payer boundary, which means absorbing X12 complexity, which means either paying a clearinghouse or becoming one. Neither option is cheap, and both are gated by relationships that are even harder to build than EHR integrations, because payer contracts are longer, slower, and more adversarial than EHR contracts.
The honest framing is that American healthcare has two interoperability problems, not one. The clinical one (FHIR) gets most of the attention because it is the one clinicians complain about directly. The financial one (X12) is invisible to clinicians but just as load-bearing, and it is the reason so many promising healthcare startups die not because their product was wrong but because they underestimated what it takes to get paid.
Modern FHIR uses REST, JSON, and a set of defined resources - Patient, Observation, Encounter, MedicationRequest, Condition, and so on - each with a stable schema and a predictable URL pattern.
The idea is simple and good. Every piece of clinical data becomes an addressable object. Every EHR exposes the same endpoints. An application built against Epic's FHIR API should, in principle, also work against Oracle Health's FHIR API, against Athena's, against Meditech's. The patient is the same patient. The data is the same data. The standard is the same standard.
This, of course, as we've discussed, is aspirational BS despite the law. 45 CFR 170.215 names FHIR R4 as the required API standard for certified health IT, along with the US Core Implementation Guide, SMART on FHIR for authorization, and Bulk Data Access for population-scale queries. 45 CFR Part 171 makes it illegal for vendors or providers to interfere with access to electronic health information except under narrowly defined exceptions. The 21st Century Cures Act, passed in 2016, is the statutory basis for all of this, and the enforcement mechanism - information blocking disincentives - became active in stages through 2024 and 2025.
On paper, the integration problem has been solved. The pipes are open. The data flows. A startup building a new system of work can, in theory, plug into any certified EHR in the country and deliver something better than what the incumbent offers.
Part One ended by saying this is not how it actually works. Part Two is about why.
II. The spec is a collapsing floor
The first thing to understand about FHIR is that the specification is permissive by design. It defines resources, cardinalities, and data types, and it allows vendors enormous latitude in how they implement those resources, which ones they expose, which fields they populate, which search parameters they support, and how they respond when something is missing.
This is not a bug. FHIR was designed to be implementable across a radically heterogeneous industry, and a rigid spec would have been dead on arrival. But the practical consequence is that "FHIR compliant" is a much weaker claim than it sounds.
Consider the Encounter resource, which represents a clinical visit. The spec defines dozens of fields - the type of encounter, the participants, the diagnoses, the location, the period, the class. A certified EHR is required to expose Encounter. But whether you can actually search for encounters in a useful way depends entirely on the vendor. Epic's implementation, historically, has required a patient reference to query Encounter at all. You cannot ask "show me all inpatient encounters at this facility last week." You can only ask "show me this patient's encounters." If you already have a list of patient IDs, you can iterate. If you are trying to build a population view, you are out of luck.
Nothing about any of this violates the letter of 45 CFR Part 171. Each vendor can point to a capability statement, each endpoint returns valid FHIR JSON, each response is dutifully schema-compliant. The information is not being blocked, exactly. It is being gated behind an access pattern that only works if you already know what you are looking for, and as I mentioned, the people at these companies don't know what they're doing either, so you won't know it - and if they happen to know it, they'll charge you 300 an hour for information they should've better provided for the fee which you already pay them --- which is all the opposite of what an interoperability standard is supposed to provide.
III. Three implementations, three different APIs
In practice, integrating with "FHIR" means integrating with a specific vendor's dialect of FHIR, and the dialects are different enough that there is no such thing as a portable integration.
Epic uses SMART on FHIR with a particular flavor of OAuth 2.0. Access tokens are short-lived - on the order of ten minutes - which forces integrators to build aggressive refresh logic. Epic distinguishes between patient-facing credentials (MyChart) and provider-facing credentials (SMART App Launch), and the two surface different data. Epic's ecosystem is optimized for Epic-to-Epic exchange through Care Everywhere, which is a private network, not a public API. If your little clinic is not on EPIC, and the close big hospital is, referrals are going to be extra hard.
Third-party integrations work, but they work as a second-class citizen of the system. Epic's App Orchard (now Showroom) has its own certification process, its own fees, its own contractual overhead on top of the regulatory baseline.
Oracle Health, formerly Cerner, took a different path. Its Ignite APIs were built FHIR-first rather than layered on top of an older architecture, and in some resource categories - care plans, certain observations - the coverage is broader than Epic's. Tokens live longer, typically an hour. Webhook-based event notifications exist, so integrators can subscribe to changes rather than polling. But Oracle Health's footprint is smaller, its documentation is less maintained since the acquisition, and configuration varies significantly across deployments. What works at one Oracle Health site may not work at another. The integration is real but the reference implementation is unstable.
Athena supports FHIR R4 on paper and has expanded its coverage over time, but the implementation is less complete than Epic or Oracle Health, particularly for complex resource types. Most companies figured out how to RPA because it took them so long.
So when a startup says "we integrate with FHIR," what they actually mean is "we have built, are building, or will be building a vendor-specific adapter for each of the four or five major EHRs our customers use, plus a long tail of smaller systems, and the FHIR spec is the loose framework inside which we are doing that work." This is interoperability-shaped labor and my bread-and-butter for the longest time, distributed across every integrator in the market, paid for over and over.
IV. RPAs
Because the official FHIR endpoints are incomplete and inconsistent, production integrations routinely fall back on undocumented behavior, vendor-specific extensions, and outright reverse engineering.
A few examples of what this looks like in practice. Capability statements - the self-description endpoint every FHIR server is supposed to publish - often lie, listing resources and search parameters that do not actually work in production. Documentation will state Scope X is what you need, you wait a month to get Scope X, and turns out, you needed Scope Y, and Scope X does something entirely different. Sandbox environments behave differently from real deployments, which means an integration that passes all tests in the sandbox can fail the first time it touches live data. If this doesn't happen, I will personally put 10$ towards a charity of your choice (10 because EHR integrations likely bankrupted me). Rate limits are often super undocumented; integrators discover them by hitting them, and now you have a grumpy customer in the middle of Buttfuck, NW (Nowhere), and they have 2 hours to think about your shitty product integration in the commute back home. Silent field omissions are extremely common, where a resource is returned with certain fields missing and no error to indicate why, it is all arbitrary. Some are worse than others. Authentication flows are inconsistent, but at the very least consistent within that EHR, thankfully. But it'll also randomly not work. The practical knowledge of how to actually make a large EHR's API work is tribal, held by consultants and integration shops, and it is a direct tax on every new entrant to the market.
Also, most integration shops don't work. Every startup I've worked at had Redox and such in their codebases that was dead code some poor engineer was tasked with removing.
Large companies can afford this tax - barely, but they can. They have teams of integration engineers, direct relationships with vendor support, and the leverage to escalate when something breaks. Small startups cannot. The cost of getting a production-grade Epic integration to work is measured in months and hundreds of thousands of dollars, before a single line of clinical value has been delivered. This is the single largest structural barrier to a healthy system-of-work ecosystem, and it is almost entirely invisible to the regulators who wrote the rules that were supposed to prevent it. The solution to this is either being VC-funded, or buying white labeled services from existing vendors. Existing EHRs do this, I was once tasked with writing the Scribe for one of the oldest EHRs in the industry.
V. The enforcement gap
Fair on both. Acronyms defined, the "not X, not Y, but Z" construction cut.
V. The enforcement gap
The Office of the Inspector General (OIG) investigates developers. The Office of the National Coordinator for Health IT (ONC) and CMS handle the provider side. The process depends on demonstrating intent or constructive knowledge that a practice was likely to interfere with access. The agencies doing this work are staffed with lawyers, not FHIR engineers. Whether a vendor's capability statement meaningfully supports the queries it advertises is not a question they are equipped to answer.
So the regime catches refusals - a vendor flatly refusing to expose an API, charging unreasonable fees for basic access - and misses everything else (TBF it also misses the first part). All of it is friction, and friction is the whole game. Do you know why? Because EHRs think they'll build these system-of-work products one day. They won't, and if they do, it'll be garbage. The Sunohs, the Haikus, and such.
It is a market where new entrants compete on merit and one where incumbents hold position through a thousand papercuts no regulator has the mandate or expertise to notice.
Enforcement needs technical audit capacity. A federal team running real workloads against real endpoints and publishing the results. If a capability statement claims a resource, an audit should be able to exercise that claim. If sandbox and production diverge, that's a finding. Until that capacity exists, the regulation will keep being written as if the pipes are open, and the market will keep operating as if they are not. We need yet another department, The Department of Healthcare Administration - and it has to be on a per state level, because payers, rules for documentation, everything, happens at a state level. My email is public.
VI. What a credible system-of-work layer needs from the system of record
Part One drew the line between the system of record, which is the canonical patient chart, and the system of work, which is what a clinician actually uses to get through a day. The claim was that these layers should be separate and that system-of-work innovation has to come from startups, because the incumbent EHR vendors are the wrong organizations to build it.
For that separation to be real, the system of record has to expose a specific set of capabilities to the system of work. Not the minimum set the law currently requires. The set that would actually make a composable stack possible.
A credible interface needs, at minimum, five things.
First, read access to the full patient record, not just the resources in the US Core IG. US Core is a starting point, not a finish line. A clinical application needs access to notes, flowsheets, attached documents, imaging references, specialty-specific data, and the long tail of fields that actually make up a patient's chart. The current standard covers a subset. The gaps are where clinically meaningful work happens.
Second, population-level queries that actually work. The ability to ask "which of my patients have an overdue A1c" or "which patients on this medication have not had follow-up" is not an exotic use case. It is the core of modern outpatient medicine. An API that requires a patient ID before it will answer any question is not an API that supports population health. Bulk Data Access (Flat FHIR) was supposed to solve this. In practice it is gated, slow, and inconsistently implemented. It needs to be a first-class, real-time capability, not a batch export that takes hours to run.
Third, write access with real workflow integration. Reading data is half the job. A system of work has to be able to write back - orders, notes, problem list updates, medication changes - with the same reliability and the same audit properties as the native EHR interface. Most production FHIR deployments restrict or disallow writes, which means any application that wants to change the chart has to either route through the native UI anyway or accept being a read-only satellite. Neither is acceptable if the goal is genuine separation of layers.
Fourth, event subscriptions. Polling is ugly design, even if it works correctly - spoiler: It doesn't. A clinical application needs to know when a result comes back, when a note is signed, when a patient arrives, when an order is placed. FHIR Subscriptions exist in the spec. They are rarely available in production. They should be universal. Of course, EHRs hold the sword, I'll let them swing on this one.
Fifth, stable identifiers and portability. A patient in Epic has an Epic ID. A patient in Oracle Health has an Oracle ID. Matching them across systems is a research problem, not a solved one. Until there is a reliable cross-vendor identity layer - which almost certainly means a federal patient identifier, a policy the United States has explicitly refused to adopt for decades - every integrator is reinventing patient matching, badly, and every handoff between systems is a risk. The original rationale was privacy concerns. Rand Paul and others have argued that a national patient ID is effectively a national ID card by another name, and civil liberties groups have backed that position. The opposition has been bipartisan and durable enough to keep the rider in place through five administrations. But HIEs need to be more transparent, more accessible, and more complete. Medicare insurance hits and Commercial should not be so far apart.
None of these five requirements is technically exotic. All of them are within the capabilities of the existing standards. What is missing is the incentive, on the incumbent side, to implement them fully, and the enforcement, on the regulatory side, to require it.
Of course, this is all under the umbrella of, FHIR should be more consistent in general, and so should HL7v2 and X12 be.
VII. What comes next
The honest version of the argument so far is this.
EHRs and ePCRs are bad because they are trying to be too many things at once, and the person they are serving least well is the clinician. The regulations that shape them are mostly load-bearing and should not be blamed for the bad user experience. The bad user experience is an architectural choice, not a regulatory necessity. The way out is to separate the system of record from the system of work, to let specialized startups build the latter, and to rely on FHIR as the interface between them.
FHIR, as it currently exists, is not good enough to support that separation. The spec is permissive, vendor implementations are inconsistent, the enforcement regime cannot distinguish genuine interoperability from its technically-compliant imitation, and the practical cost of integration is a tax that only the well-funded can pay. This is not an accident. It is a stable equilibrium that benefits incumbents, and it will not change on its own.
What would change it: a technically competent federal audit function for information blocking, an externalized and verified version of HIPAA, a stricter implementation guide that names specific query patterns as required rather than optional, a cross-vendor identity layer, and - crucially - a generation of system-of-work startups that build against this architecture anyway, that treat the current FHIR situation as infrastructure to be fought with rather than a settled foundation to be built on.
This is not a five-year project. The incumbents have thirty years of accumulated advantage and the regulatory capture to match. But the alternative is another decade of burnout, consolidation, and small clinics disappearing into larger systems because their software could not keep up. The status quo is not neutral. It is actively selecting against the kind of healthcare most people say they want.
The next piece in this series is about what system-of-work startups actually look like when they are built with this philosophy in mind - what they choose to do, what they choose not to do, where they draw the line between themselves and the chart, and how they survive the integration tax long enough to deliver on the promise. I will probably talk about my startup a bit, but it's not marketing.