A physician in 2026 can still find it easier to fax a patient record than to share it electronically with a colleague across town.1
That sentence is worth sitting with for a second, because it sounds like a joke and isn't one. Healthcare has spent the last few decades developing diagnostics, therapies, and procedures that would have sounded like science fiction a generation ago. And somewhere underneath all of that progress, a hospital's computer system frequently cannot simply hand a patient's chart to the hospital three blocks away. The reason why is a genuinely interesting infrastructure story, and the standard built to fix it is worth understanding.
The problem isn't that hospitals don't have computers
Nearly every hospital in the country has long since digitized. Close to 95 percent of hospitals and 90 percent of office-based physicians use some form of electronic health record system.2 The data exists. It's stored, searchable, backed up, all the things you'd expect from modern software.
The problem is that "digitized" and "able to talk to each other" turned out to be two completely different achievements. Despite billions of dollars invested in electronic records and health information exchange programs, interoperability (the ability of different systems to actually exchange and use each other's data) remains one of healthcare's biggest operational bottlenecks.3 Only 55 percent of hospitals can even find a patient's information electronically from an outside organization, and just 40 percent of those can pull that information directly into their own system without someone manually re-entering it.4
That second number is the one that actually matters. Even when the data successfully crosses from one hospital's system to another, less than half the time can it just slot into place. The rest of the time, a human is retyping it.
It's worth picturing what that actually looks like in practice. Imagine two countries that both have excellent, modern postal services, fast trucks, reliable carriers, sturdy envelopes, but they use completely different addressing systems, different paper sizes, and different languages on the label. A letter can absolutely travel from one country to the other. It just can't be automatically sorted, read, or filed once it arrives, because nothing about its format makes sense on the receiving end. Someone has to manually translate it by hand before it's actually useful. That's roughly the state of most hospital-to-hospital data exchange. The delivery problem got solved decades ago. Nobody fully agreed on the label.
Why this isn't simply a technical oversight
It would be easy to assume nobody thought hospital software needed to talk to other hospital software, but that's not quite right either. Two genuinely structural obstacles are doing most of the damage.
The first is historical. Each hospital, over decades, picked its own electronic health record vendor, often years before any of today's standards existed, and built years of workflows, custom fields, and internal logic on top of whatever that vendor's system happened to support. Ripping that out and replacing it is enormously disruptive and expensive, so most hospitals simply don't, even when a better standard becomes available.5 It's the same reason nobody tears out a building's plumbing just because a better pipe material got invented after the building was already finished. The new material might genuinely be better. Replacing everything behind the walls is still a renovation nobody wants to live through.
The second is more subtle and arguably more interesting: even identifying that two records belong to the same person across two different systems is a real, unsolved-at-scale problem. Matching patient records accurately across and within different healthcare settings is one of the biggest barriers to real interoperability, separate from the question of whether the systems can technically transmit data to each other at all.6 A hospital across town might have you listed under a slightly different spelling of your name, an old address, a maiden name, or a different format for your date of birth, and there's no universal patient ID tying all of that together the way, say, a Social Security number ties together tax records. Two systems can be perfectly capable of exchanging data and still not be sure they're talking about the same human being. It's less like a broken phone line and more like two people trying to figure out if they went to the same wedding, except neither of them is allowed to just ask the obvious question, and the only clues they have are a slightly misspelled name and an address from six years ago.
What the old way of exchanging health data actually looked like
To understand why the fix is truly clever, it helps to see what it replaced.
The older HL7 standards, versions 2 and 3, are still running underneath most U.S. health systems today.7 HL7 version 2 moves information as pipe-delimited messages, meaning data fields are separated by literal vertical pipe characters in a flat block of text, a format that predates the modern web entirely and was never designed with something like a REST API or JSON in mind.7 Version 3 tried to formalize things further using a complex underlying reference model, but it became notoriously difficult to implement consistently, which meant different vendors interpreted and extended it in subtly incompatible ways.
Think of an HL7 v2 message like a grocery list scrawled on a single line of receipt paper: milk, comma, eggs, comma, bread, with no further structure beyond the order things happen to appear in. It works fine if you wrote it and you're the one reading it back. It works considerably worse the moment you hand that same scrap of paper to someone else and expect them to correctly understand which item was a quantity, which was a brand, and which was just a note to self, because nothing about the format tells them. Two systems could both technically read HL7 v2 and still disagree about what a given pipe-separated value actually meant in context, because the standard left enough room for interpretation that compatibility was attempted more than it was guaranteed.
So for years, the "standard" way for two health systems to exchange a patient's data was a message format roughly as old as fax itself in spirit, even when it was technically running over modern infrastructure.
The fix: treating health data like any other modern API
This is where FHIR comes in, pronounced like the word "fire," standing for Fast Healthcare Interoperability Resources.
The core idea is refreshingly simple once you see it: instead of one giant, rigid message format trying to represent an entire patient encounter at once, FHIR breaks healthcare data into small, modular building blocks called Resources, like Patient, Encounter, Observation, and MedicationRequest, each with a defined structure that any system implementing FHIR agrees to follow.8 A request can ask for just one piece, say, a patient's current medication list, rather than retrieving and parsing an entire monolithic document just to extract one fact buried inside it.9
This is the difference between mailing someone your entire filing cabinet because they asked for one receipt, versus handing them a labeled folder that contains exactly the receipt they wanted and nothing else. The filing cabinet technically contains the answer. The labeled folder is the answer. FHIR is healthcare data finally getting labeled folders instead of filing cabinets.
The genuinely clever part is what FHIR is built on top of. Rather than inventing another bespoke healthcare-only protocol the way earlier HL7 versions did, FHIR uses RESTful APIs, the same HTTP verbs, the same JSON formatting, the same web technology that powers an ordinary weather app or a ride-share app.10 A request to read a patient's record looks, structurally, almost identical to a request you'd send to any modern web API. This single decision matters more than it sounds like it should, because it means the enormous pool of developers who already know how to build and consume REST APIs can work on healthcare interoperability without learning an entirely separate, healthcare-specific way of moving data.11 It's the engineering equivalent of designing a new currency that happens to use the exact coin slots every vending machine on the planet already has, instead of inventing a brand new slot shape and hoping every vending machine manufacturer eventually retools for it.
Authentication and patient consent get handled through a companion piece called SMART on FHIR, which layers standard OAuth 2.0, the same authorization protocol behind "log in with Google" buttons everywhere on the internet, onto the FHIR data layer.12 A patient's phone app, a specialist's office, and a hospital's main system can all request access to specific FHIR resources, with the patient's consent enforced through familiar, modern authorization machinery rather than something healthcare-specific and unfamiliar to most engineers. You've already used the exact mechanism behind this, probably this week, every time you let some app log into your Google account instead of making a brand new password just for that one app.
Why this still doesn't fully solve the problem
Adoption of the actual API layer has moved remarkably fast for healthcare's usual pace. More than 95 percent of certified health IT developers had implemented the federally required patient access APIs by the end of 2022.13 By most measures, FHIR has won as the standard.
And yet only 43 percent of U.S. hospitals routinely meet the actual four-part definition of true interoperability, despite that near-universal technical certification.13 Having the API exposed and having the data genuinely, reliably, usefully flow between systems turned out to be two different milestones.
This gap makes more sense once you stop thinking of FHIR as a finished bridge and start thinking of it as a universally agreed-upon bolt size. Everyone now knows what size bolt to use. That doesn't mean every bridge has actually been built, or that the older bridges built decades ago with completely different bolts have been retrofitted to match. FHIR solves the format problem: two systems can now structurally understand each other's messages in a way HL7 v2 never reliably guaranteed. It does not, on its own, solve the patient-matching problem, the workflow problem, or the simple fact that countless hospitals are still running older systems that were never built around it in the first place.6
This is a pattern worth recognizing in any large legacy system, not just healthcare. A better standard arriving doesn't retroactively fix every system built before it existed. It just gives everyone building going forward a much better foundation to build on, while the slow, expensive work of migrating everything that came before continues in the background, often for decades.
Why this matters beyond the hospital
The actual cost of all of this isn't abstract. Poor interoperability drives duplicate testing, denials, and administrative waste across hospitals and physician practices.3 An analysis of cyberattacks on interoperable health record systems found the average hospital outage afterward lasted 24 days, at an average cost of roughly 10 million dollars per incident, partly because of how deeply intertwined and fragile these connections between systems can be once they exist at all.3
There's a real engineering lesson underneath all of this, one that applies just as much outside of healthcare. The hardest part of connecting two systems is rarely the wire format. It's agreeing on what a piece of data actually means, making sure both sides are confidently talking about the same real-world thing, and accepting that whatever standard you ship today will spend the next twenty years coexisting with everything that came before it. FHIR is a genuinely good answer to the first problem. The second and third are still, slowly, being solved one hospital at a time.
Footnotes
1 On the persistence of fax-based record sharing despite decades of EHR investment. Medical Economics: The dirty secret — why your EHR still can't talk to other systems
2 On EHR adoption rates among U.S. hospitals and physicians. Rhapsody: 4 Reasons Why EHR Interoperability Is a Mess
3 On the operational and financial costs of poor interoperability, including outage data after cyberattacks. CertifyHealth: Healthcare Interoperability Challenges & Practical Solutions
4 On the share of hospitals that can locate and actually integrate outside patient data. Certinal: Interoperability of Electronic Health Records
5 On the cost and disruption of replacing legacy EHR infrastructure. MyMedicalRecords: Healthcare Interoperability — Why Systems Can't Connect
6 On patient record matching as a distinct, unsolved obstacle separate from data format compatibility. Rhapsody: 4 Reasons Why EHR Interoperability Is a Mess
7 On HL7 v2's pipe-delimited message format and why FHIR was developed as its modern successor. Commure: What Is HL7 FHIR? A Practical Overview
8 On FHIR's modular Resource-based data model. Wikipedia: Fast Healthcare Interoperability Resources
9 On granular data retrieval as a specific advantage of FHIR's resource model over older document-based exchange. ONC: What Is HL7 FHIR? Fact Sheet
10 On FHIR's use of REST APIs and JSON, the same web technologies used outside healthcare. BGO Software: HL7 FHIR and APIs — The Full Interoperability Guide
11 On FHIR tapping into the existing developer talent pool already familiar with REST and JSON from outside healthcare. Commure: What Is HL7 FHIR? A Practical Overview
12 On SMART on FHIR and its use of OAuth 2.0 for authorization and patient consent. HL7: SMART App Launch Framework, Official Specification
13 On near-universal certified FHIR API adoption alongside the much lower rate of hospitals meeting true interoperability standards. Commure: What Is HL7 FHIR? A Practical Overview
Top comments (0)