FHIR: The Universal Language of Health Data
FHIR: The Universal Language of Health Data
The Quiet Crisis in Your Medical Records
Picture this.
You move to a new city. You find a new doctor. You sit in a sterile waiting room, filling out the same forms you’ve filled out a hundred times before—your allergies, your medications, your surgeries, your family history, the time you broke your arm in third grade. You write it all down. Again. The nurse takes your clipboard. She types it into a computer. A computer that cannot talk to the computer at your old doctor’s office. A computer that cannot talk to the computer at the hospital where you had your appendix out. A computer that cannot talk to the computer at the pharmacy where you pick up your prescriptions.
This is not a bug.
This is the architecture of modern healthcare.
And it is, by almost any reasonable standard, completely insane.
Every year, the United States alone spends something in the neighborhood of thirty billion dollars on healthcare administration—much of it on the manual shuffling of information between systems that refuse to speak to one another. Patients die because their allergy information is trapped in a database their emergency room cannot access. Doctors order redundant tests because they cannot see the results of tests ordered last week by a colleague in a different building. Researchers cannot study diseases at scale because the data they need is locked in proprietary formats, guarded by vendors who profit from keeping it that way.
This is the world that FHIR was born to fix.
FHIR—pronounced “fire,” like the thing that destroys and the thing that warms—stands for Fast Healthcare Interoperability Resources. It is a standard for exchanging healthcare information electronically. It is also, arguably, the most important and least understood technology in modern medicine. It is the invisible scaffolding beneath a revolution that most patients will never see, never name, and never thank—but that will, if it succeeds, save their lives.
Let us begin at the beginning.
What Is FHIR, Really?
At its most basic, FHIR is a set of rules.
More precisely, it is a standard developed by Health Level Seven International—HL7, a not-for-profit organization that has been building healthcare data standards since 1987. FHIR was first released in 2014, though its conceptual roots stretch back further, and it has been evolving ever since. The current version, FHIR R4 (Release 4), was published in 2019 and remains the most widely implemented. FHIR R5 followed in 2023, and the standard continues to mature.
But “a set of rules” is a dry description for something so consequential. Let us try again.
FHIR is a way of describing health information—patients, medications, allergies, lab results, diagnoses, appointments, insurance claims, genomic sequences, wearable device readings, social determinants of health, and on and on and on—in a format that any computer system can understand, regardless of who built it, what language it was written in, or what database it uses underneath. It is a lingua franca for medical data. It is the Esperanto of the emergency room, the Rosetta Stone of the radiology department.
The core innovation of FHIR is its use of resources—discrete, standardized packets of information, each representing a specific concept in healthcare. A Patient resource contains demographic information: name, birth date, gender, address, contact details. An Observation resource contains a single piece of clinical data: a blood pressure reading, a body temperature, a lab result, a smoking status. A MedicationRequest resource contains—well, a request for medication. A Condition resource contains a diagnosis. An Encounter resource contains a visit.
Each resource is a self-contained, structured data object, formatted in a way that is both human-readable and machine-parseable. FHIR supports multiple formats, but the most common are JSON (JavaScript Object Notation, the lingua franca of modern web development) and XML (Extensible Markup Language, the venerable elder statesman of structured data). A FHIR resource in JSON looks, to the untrained eye, like a neatly organized text file with lots of curly braces and colons. To a computer, it is a precise, unambiguous instruction set.
Here is a simplified example of a Patient resource in JSON:
{
"resourceType": "Patient",
"id": "example-patient-001",
"name": [
{
"use": "official",
"family": "Hernandez",
"given": ["Maria", "Isabel"]
}
],
"gender": "female",
"birthDate": "1985-03-12",
"address": [
{
"use": "home",
"line": ["742 Evergreen Terrace"],
"city": "Springfield",
"state": "IL",
"postalCode": "62704"
}
]
}This is not merely a text file. This is a contract. Any system that speaks FHIR can read this resource and know, with mathematical certainty, that Maria Isabel Hernandez was born on March 12, 1985, and lives at 742 Evergreen Terrace in Springfield, Illinois. The structure is rigid enough to ensure consistency and flexible enough to accommodate the glorious, maddening complexity of real-world healthcare.
And this is where FHIR begins to distinguish itself from its predecessors.
The Long, Winding Road to Interoperability
To understand why FHIR matters, one must understand what came before. And what came before was, to put it charitably, a mixed bag.
Healthcare data standards have existed since the 1980s, when HL7 released its first version of what is now called HL7 v2. HL7 v2 was—and remains—a workhorse. It is a messaging standard: a way of sending packets of clinical information from one system to another, typically over a network connection. If you have ever had blood drawn at a hospital and received the results in your patient portal, there is a decent chance an HL7 v2 message carried that information from the lab system to the portal system.
But HL7 v2 has problems. It is a pipe, not a platform. It sends messages in a rigid, pipe-delimited format that is difficult for humans to read and painful for developers to work with. It is a “push” model: System A pushes a message to System B, and if System B is not listening, or if the message format is slightly different than expected, the data falls into the void. It is, in the words of one informaticist, “a standard with 2,000 optional fields and no required ones,” which is another way of saying that two systems can both claim to support HL7 v2 and still be unable to communicate with each other.
Then came HL7 v3, released in 2005 after years of development. V3 was ambitious—too ambitious, as it turned out. It was based on a rigorous, top-down modeling approach called the Reference Information Model (RIM), which attempted to describe every possible healthcare concept in a single, unified framework. The RIM was intellectually elegant and practically catastrophic. Implementing HL7 v3 required navigating a labyrinth of abstract models, complex mappings, and ontological debates that would make a philosophy professor weep. It was, in the end, too heavy, too slow, and too expensive. It never achieved widespread adoption in the United States, though it found some traction in Europe and Canada.
And then, in the early 2010s, something changed.
The internet had happened. Smartphones had happened. RESTful APIs—Representational State Transfer Application Programming Interfaces, the architectural style that powers Google, Facebook, Twitter, and virtually every modern web service—had happened. A generation of developers had grown up building applications that consumed and produced JSON over HTTP, the same protocol that delivers cat videos and news articles to your browser. They looked at HL7 v2 and v3 and saw ancient, creaking machinery. They looked at the web and saw a better way.
Grahame Grieve, an Australian informaticist with the patient demeanor of a man who has spent decades explaining complex things to skeptical audiences, led the charge. Grieve had been involved in HL7 standards development for years and had seen the limitations of v2 and v3 firsthand. He proposed something radical: a healthcare standard built on the same technologies that powered the modern web. REST. JSON. HTTP. OAuth for security. Simple, modular resources that could be combined like LEGO bricks to represent any clinical scenario.
This was FHIR.
The name was a deliberate choice. “Fast” was a promise. “Resources” was a architectural decision. “Interoperability” was the goal. And “Healthcare” was the domain. The acronym was cute, but the ambition was enormous: to make healthcare data exchange as easy, as fast, and as ubiquitous as sending an email or checking a bank balance on your phone.
FHIR was not the first attempt to bring web technologies to healthcare. But it was the first to do so with the institutional backing of HL7, the credibility of a rigorous standards-development process, and the pragmatic sensibility of developers who had actually built things that people used.
The Architecture of a Revolution
Let us open the hood.
FHIR is built on a few foundational principles that distinguish it from everything that came before. Understanding these principles is essential to understanding why FHIR works—and why, in some cases, it still struggles.
Resources: The Atoms of Health Data
The resource is the fundamental unit of FHIR. Think of it as an atom: indivisible, self-contained, with a defined structure and a specific identity. Every resource has a resourceType (Patient, Observation, Medication, etc.), an id (a unique identifier within its system), and a set of elements (the individual data fields that make up the resource).
Resources are designed to be small enough to be manageable and large enough to be meaningful. A Patient resource does not contain every piece of information about a patient in the universe—it contains the core demographic and administrative information that most systems need to identify and contact a patient. If you need clinical information, you link to other resources: Observations for vital signs, Conditions for diagnoses, MedicationRequests for prescriptions.
This modularity is crucial. It means that systems can exchange only the information they need, without dragging along massive, monolithic records. It means that developers can build applications that consume only the resources they care about—a fitness app might only need Observation resources, while a billing system might only need Encounter and Coverage resources. It means that the standard can grow incrementally: new resources can be added, and existing resources can be extended, without breaking everything that came before.
RESTful APIs: The Web, But for Your Blood Pressure
FHIR is designed to be accessed via RESTful APIs, which is a fancy way of saying that it works like the web.
When you type a URL into your browser, you are making an HTTP request. The server responds with HTML, which your browser renders as a web page. FHIR works the same way, except the URLs point to healthcare resources, and the responses are JSON or XML instead of HTML.
Here is how it works in practice. A developer building a patient-facing app wants to show a user their recent lab results. The app makes an HTTP GET request to a FHIR server:
GET https://api.hospital.example.org/fhir/R4/Observation?patient=12345&category=laboratoryThe server responds with a Bundle—a FHIR resource that contains a collection of other resources. In this case, the Bundle contains Observation resources representing the patient’s lab results. The app parses the JSON, extracts the relevant data, and displays it to the user.
This is not science fiction. This is how Apple Health works, more or less, when it pulls your health records from participating hospitals. This is how Epic’s MyChart works. This is how countless startups are building the next generation of healthcare applications.
The RESTful approach brings several advantages. It is stateless: each request contains all the information the server needs to fulfill it, which simplifies scaling and reliability. It is cacheable: responses can be stored and reused, improving performance. It is layered: clients do not need to know anything about the server’s internal architecture, only the API it exposes. And it is uniform: the same HTTP methods (GET, POST, PUT, DELETE) are used for all resources, which means that once a developer learns how to interact with one resource, they know how to interact with all of them.
Profiles, Extensions, and the Art of Compromise
Healthcare is not uniform. A pediatric hospital has different data needs than a psychiatric clinic. A genomic research institute has different data needs than a rural primary care practice. A country with a national health service has different administrative requirements than a country with a fragmented insurance market.
FHIR addresses this variability through profiles and extensions.
A profile is a customization of a FHIR resource for a specific use case. It might define which elements are required, which are optional, and what values they can take. For example, the US Core Profile, developed for use in the United States, specifies that Patient resources must include race and ethnicity information (to support health equity reporting) and that certain identifiers must follow specific formats. A system that claims to support the US Core Profile must adhere to these rules.
An extension is a way of adding information to a resource that is not defined in the base standard. FHIR defines a mechanism for extensions that ensures they are structured, identifiable, and interoperable. If a hospital wants to track a patient’s preferred pronouns, and the base Patient resource does not have a field for that, they can add an extension. If a research study needs to capture a specific biomarker that is not in any standard resource, they can add an extension.
This flexibility is FHIR’s greatest strength and its most dangerous weakness. Used well, profiles and extensions allow FHIR to adapt to local needs without fragmenting into a thousand incompatible dialects. Used poorly, they allow vendors to claim FHIR compliance while implementing proprietary extensions that lock data into their ecosystems—a practice known, with weary irony, as “FHIR-washing.”
The tension between standardization and flexibility is as old as standards themselves. FHIR navigates it better than most, but the navigation is never complete.
When FHIR Became Inevitable
FHIR did not emerge in a vacuum. It emerged at a particular moment in the history of healthcare, technology, and policy—a moment when several forces converged to make interoperability not merely desirable but unavoidable.
The HITECH Act and the Great Digitization
In 2009, the United States Congress passed the Health Information Technology for Economic and Clinical Health Act—HITECH—as part of the American Recovery and Reinvestment Act. HITECH provided billions of dollars in incentives for hospitals and physicians to adopt electronic health records (EHRs). The goal was to drag American healthcare, kicking and screaming, into the digital age.
It worked, after a fashion. EHR adoption skyrocketed. By 2017, more than 95% of hospitals and 80% of office-based physicians had implemented certified EHR technology. But the digitization was shallow. Most EHR systems were proprietary, siloed, and designed primarily for billing and regulatory compliance rather than clinical care and data exchange. Doctors complained—loudly, famously, sometimes bitterly—about systems that slowed them down, cluttered their screens with irrelevant alerts, and made the simple act of writing a prescription feel like navigating a labyrinth designed by a sadist.
The data was digital, but it was not liquid. It was trapped.
The 21st Century Cures Act: The Regulatory Hammer
In 2016, Congress passed the 21st Century Cures Act, a sprawling piece of legislation that included, buried among its many provisions, a mandate for healthcare interoperability. The law directed the Office of the National Coordinator for Health Information Technology (ONC) to prohibit “information blocking”—the practice of deliberately preventing or discouraging the sharing of electronic health information.
In 2020, the ONC released its final rule implementing these provisions. The rule required certified health IT developers to provide standardized APIs for patient access, using—specifically, explicitly—FHIR. It set deadlines. It established penalties. It made FHIR not merely a good idea but a legal requirement for any vendor that wanted to sell EHR systems in the United States.
This was the inflection point. Before the Cures Act, FHIR was a promising standard with growing adoption. After the Cures Act, it was the law of the land. Vendors who had been dragging their feet suddenly found religion. Epic, Cerner, Meditech, Allscripts—the giants of the EHR market—announced FHIR support. Apple launched its Health Records feature, built on FHIR. Google, Microsoft, and Amazon began offering FHIR-compliant cloud services.
The market had spoken. And the market had been spoken to, rather firmly, by the government.
COVID-19: The Stress Test Nobody Wanted
Then came the pandemic.
COVID-19 was, among many other things, a brutal test of healthcare infrastructure. Hospitals were overwhelmed. Public health agencies needed real-time data on cases, hospitalizations, ventilator usage, and vaccine distribution. Researchers needed to share genomic sequences, clinical trial results, and treatment protocols at a speed that legacy systems could not support.
FHIR was not ready for everything the pandemic threw at it. But it was ready for some things, and it proved its value in ways that accelerated adoption dramatically. The CDC used FHIR to standardize COVID-19 case reporting. The Vaccines.gov website used FHIR to help people find vaccination appointments. Telehealth platforms used FHIR to integrate with EHRs. Researchers used FHIR to build large-scale datasets for studying long COVID.
The pandemic did not create FHIR. But it validated, in the most urgent and visceral way possible, the argument that healthcare data needs to flow freely, quickly, and reliably—and that FHIR was the best tool available to make that happen.
The Science Beneath the Standard
FHIR is not merely a technical specification. It is the product of decades of research and practice in medical informatics, computer science, and cognitive engineering. To understand why it is designed the way it is, one must understand the intellectual traditions from which it emerged.
Information Models and the Problem of Meaning
At the heart of healthcare interoperability is a deceptively simple question: what does this data mean?
When a doctor records that a patient has “diabetes,” what exactly is being asserted? Is it a diagnosis? A suspicion? A history? A risk factor? Is it Type 1 or Type 2? Is it controlled or uncontrolled? Does it involve complications? The word “diabetes” is a label for a vast, heterogeneous, evolving constellation of biological states and clinical judgments.
Medical informaticists have grappled with this problem for decades. One approach is the use of controlled vocabularies and ontologies—formal systems for defining and organizing medical concepts. SNOMED CT (Systematized Nomenclature of Medicine—Clinical Terms) is the most comprehensive clinical terminology in the world, with more than 300,000 concepts. LOINC (Logical Observation Identifiers Names and Codes) standardizes lab tests and clinical observations. RxNorm standardizes medications. ICD-10 (International Classification of Diseases, 10th Revision) standardizes diagnoses for billing and epidemiology.
FHIR does not replace these systems. It integrates them. Every coded element in a FHIR resource—every diagnosis, every lab test, every medication—can be bound to one or more of these terminologies. A Condition resource does not just say “diabetes”; it says “diabetes, coded as 73211009 in SNOMED CT, or E11.9 in ICD-10-CM, or both.” This binding ensures that when System A says “diabetes,” System B knows exactly what System A means.
This is harder than it sounds. Terminologies evolve. Codes change. Mappings between terminologies are imperfect. A code that means one thing in one context may mean something slightly different in another. The work of maintaining and improving these bindings is endless, tedious, and absolutely essential.
The Semantic Web and Linked Data
FHIR also draws on the tradition of the semantic web—Tim Berners-Lee’s vision of a web of data that machines can understand and reason about. The semantic web is built on technologies like RDF (Resource Description Framework), OWL (Web Ontology Language), and SPARQL (a query language for RDF data).
FHIR’s use of resources with unique identifiers, linked by references, mirrors the linked data principles of the semantic web. A Patient resource has an ID. An Observation resource references that ID in its subject field. A DiagnosticReport resource references the Observation in its result field. This creates a graph of interconnected data that can be traversed, queried, and analyzed.
FHIR even has an RDF serialization, though it is less commonly used than JSON or XML. The RDF representation allows FHIR data to be integrated with other semantic web datasets, enabling sophisticated reasoning and inference. This is not merely academic: it enables applications like clinical decision support systems that can automatically detect drug interactions, contraindications, and care gaps by reasoning over linked patient data.
Human Factors and the Design of Cognitive Tools
Finally, FHIR reflects a growing awareness in medical informatics that technology must be designed for the humans who use it. This is the domain of human factors engineering and cognitive systems engineering—disciplines that study how people interact with complex systems and how to design those systems to support human cognition rather than hinder it.
The FHIR specification is vast—thousands of pages across multiple implementation guides—but it is organized with a clarity that reflects an understanding of how developers think and work. Resources are documented with clear definitions, examples, and mappings to real-world clinical concepts. The RESTful API is intuitive to anyone familiar with web development. The JSON format is readable and debuggable.
This matters because the ultimate users of FHIR are not computers. They are doctors, nurses, patients, researchers, and public health officials. If FHIR is too complex, developers will not implement it correctly. If it is implemented incorrectly, the data will be wrong or incomplete. If the data is wrong or incomplete, clinicians will not trust it. If clinicians do not trust it, they will not use it. And if they do not use it, the standard fails, no matter how elegant its architecture.
The history of healthcare IT is littered with elegant architectures that failed because they ignored the humans in the loop. FHIR’s designers have tried, with considerable success, to avoid that fate.
Where FHIR Lives and Breathes
FHIR is not a product. It is not a company. It is not a single piece of software that you can download and install. It is a standard—a set of agreements—that enables products, companies, and software systems to work together.
But where, exactly, does it operate?
In the Electronic Health Record
The most visible home of FHIR is the EHR. Epic, Cerner (now Oracle Health), Meditech, athenahealth, eClinicalWorks, and virtually every other major EHR vendor in the United States now supports FHIR APIs. This means that a hospital running Epic can, in theory, exchange data with a clinic running Cerner using FHIR as the common language.
In practice, this is still harder than it should be. Vendors have implemented FHIR with varying degrees of completeness and enthusiasm. Some support only the minimum required by regulation. Others have embraced FHIR as a platform for innovation, building extensive app ecosystems around their FHIR APIs. The gap between “supports FHIR” and “interoperates seamlessly” remains wide, but it is narrowing.
In the Patient’s Pocket
Perhaps the most transformative application of FHIR is patient access. The 21st Century Cures Act requires that patients be able to access their health information using FHIR-based APIs. This has enabled a new generation of patient-facing applications.
Apple Health Records is the most prominent example. Using FHIR, iPhone users can pull their health records from participating hospitals into the Health app, creating a unified, portable health record that follows them wherever they go. The data is encrypted, stored locally on the device, and under the patient’s control. It is, in a very real sense, a step toward the long-promised, long-delayed dream of patient-centered health information exchange.
Other apps have followed. Google Health (now defunct, a cautionary tale about the difficulty of this space), Microsoft HealthVault (also defunct, see previous cautionary tale), and a host of startups have attempted to build patient-controlled health record platforms on FHIR. Some have succeeded. Many have failed. The space is difficult, competitive, and fraught with privacy concerns. But the technical foundation—FHIR—remains.
In the Cloud
The major cloud computing providers—Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure—have all launched FHIR-compliant health data services. AWS HealthLake, Google Cloud Healthcare API, and Azure API for FHIR allow healthcare organizations to store, query, and analyze health data in the cloud using FHIR as the native format.
This is significant for several reasons. First, it lowers the barrier to entry for FHIR adoption. Organizations that lack the technical expertise to build and maintain their own FHIR servers can use managed cloud services instead. Second, it enables advanced analytics and machine learning at a scale that would be impossible with on-premises infrastructure. Researchers can query millions of FHIR resources, train AI models on de-identified patient data, and derive insights that were previously inaccessible.
Third, and most consequentially, it positions the cloud providers as central hubs in the emerging health data ecosystem. This raises profound questions about data ownership, privacy, and market concentration that have not yet been fully addressed.
In the Research Laboratory
FHIR is increasingly used in clinical and translational research. The National Institutes of Health (NIH) has incorporated FHIR into its All of Us Research Program, which aims to collect health data from one million Americans to advance precision medicine. The FDA has explored using FHIR for regulatory submissions and adverse event reporting. The HL7 FHIR Accelerator Program supports a growing number of implementation guides for research use cases, from genomics to clinical trials to real-world evidence generation.
The appeal for researchers is clear. FHIR provides a standardized way to represent the messy, heterogeneous data of clinical practice in a format that can be aggregated, queried, and analyzed. It bridges the gap between the structured data of the research database and the unstructured, narrative data of the clinical record.
In Public Health
The COVID-19 pandemic exposed the fragility of public health data infrastructure in the United States and around the world. State health departments were receiving case reports by fax. The CDC was relying on manual data entry. The lack of real-time, standardized data flow hampered the response at every turn.
FHIR is now being positioned as a foundational technology for the modernization of public health informatics. The CDC has developed FHIR-based standards for case reporting, immunization tracking, and syndromic surveillance. The Argonaut Project, a private-sector initiative, has developed implementation guides for public health use cases. The goal is to create a national, real-time, interoperable public health data network that can detect outbreaks, track disease trends, and coordinate responses with a speed and precision that was impossible in 2020.
Whether this vision will be realized depends on funding, political will, and the ability to overcome the institutional inertia that has plagued public health IT for decades. But the technical pathway exists. FHIR is the road.
The Technologies That Make FHIR Possible
FHIR did not emerge from nothing. It stands on the shoulders of a vast technological infrastructure that took decades to build. To appreciate FHIR, one must appreciate the tools that make it possible.
HTTP and the Architecture of the Web
The Hypertext Transfer Protocol—HTTP—is the foundation of the World Wide Web. It is a simple, text-based protocol for requesting and transmitting resources across a network. When you visit a website, your browser sends an HTTP request to a server; the server sends back an HTTP response containing the web page.
FHIR uses HTTP as its transport layer. A FHIR server is, at its core, a web server that understands a specific set of URL patterns and response formats. This means that FHIR inherits all the advantages of the web: ubiquity, scalability, reliability, and a massive ecosystem of tools, libraries, and expertise.
It also means that FHIR can leverage web security technologies. HTTPS—HTTP over TLS (Transport Layer Security)—encrypts data in transit, protecting it from eavesdropping and tampering. OAuth 2.0, an authorization framework originally developed for social media login, is used in FHIR to control access to patient data. SMART on FHIR (Substitutable Medical Applications, Reusable Technologies) is a profile that defines how OAuth 2.0 should be used in healthcare, enabling a single sign-on experience where patients can authorize third-party apps to access their EHR data.
JSON and the Democratization of Data
JavaScript Object Notation—JSON—is a lightweight data format that has become the de facto standard for web APIs. It is human-readable, easy to parse, and supported by virtually every programming language.
FHIR’s use of JSON was a deliberate choice to lower the barrier to entry for developers. Before FHIR, healthcare data standards were often encoded in obscure, verbose formats that required specialized libraries and expertise. JSON is familiar to any web developer. A software engineer who has built a weather app or a social media feed can, with minimal training, start building healthcare applications with FHIR.
This democratization is not merely a matter of convenience. It expands the pool of people who can innovate in healthcare. It allows startups to compete with established vendors. It allows patients and advocates to build their own tools. It allows researchers to prototype ideas without waiting for IT departments to allocate resources.
OAuth 2.0 and the Problem of Trust
Healthcare data is among the most sensitive information that exists. A leak of financial data is embarrassing and costly. A leak of health data can be life-destroying. It can reveal mental illness, substance abuse, sexual history, genetic predispositions, and a thousand other secrets that people have powerful reasons to keep private.
FHIR addresses this through a security model based on OAuth 2.0 and, increasingly, the User Managed Access (UMA) protocol. The basic idea is that access to data is controlled by the patient (or their designated representative). When a third-party app wants to access a patient’s EHR data, it must obtain an access token from an authorization server. The patient authenticates themselves—typically through a web-based login—and grants specific permissions. The app receives a token that it can use to access only the data the patient has authorized, for a limited time.
This is the same model used by Facebook when you log into Spotify using your Facebook account, or by Google when you grant a calendar app access to your Google Calendar. The difference is that the stakes are higher, the regulations are stricter (HIPAA, the Health Insurance Portability and Accountability Act, imposes severe penalties for unauthorized disclosure of health information), and the technical requirements are more demanding.
SMART on FHIR refines this model for healthcare. It specifies how apps should be registered, how patients should be authenticated, how scopes of access should be defined, and how tokens should be managed. It is not perfect—no security model is—but it provides a framework that balances accessibility and protection in a way that is workable for real-world systems.
Terminology Services and the Management of Meaning
We have already touched on the importance of controlled vocabularies. But managing these vocabularies at scale is a technical challenge in its own right.
FHIR defines a set of terminology services—APIs for querying, validating, and translating coded values. A FHIR terminology server can answer questions like: “What is the current version of SNOMED CT?” “Is this code valid in this context?” “What is the equivalent code in LOINC?” “What are all the subtypes of this diagnosis?”
These services are essential for maintaining data quality across large, distributed systems. They allow EHRs to validate codes at the point of entry, preventing errors that would otherwise propagate through the system. They allow researchers to map between terminologies, enabling meta-analyses that span multiple datasets. They allow public health agencies to standardize reporting, ensuring that a case of COVID-19 in California is coded the same way as a case of COVID-19 in New York.
The FHIR specification includes a comprehensive set of resources for terminology management: CodeSystem (defines a set of codes), ValueSet (selects a subset of codes for a specific purpose), ConceptMap (maps between code systems), and others. This is not the most glamorous part of FHIR, but it is among the most important. A standard for data exchange is worthless if the data itself is ambiguous.
The People Behind the Protocol
Standards do not write themselves. FHIR is the product of thousands of hours of volunteer labor by a global community of informaticists, clinicians, developers, and policy wonks.
Grahame Grieve and the FHIR Core Team
Grahame Grieve is the product director for FHIR and the chair of the HL7 FHIR Management Group. An Australian by birth and temperament—understated, dryly humorous, implacably patient—Grieve has been the driving force behind FHIR since its inception. He has a background in clinical medicine, software engineering, and standards development, and he brings to the work a rare combination of technical depth, clinical sensibility, and political acumen.
Grieve is not a household name, and he would probably prefer it that way. But his influence on the architecture of modern healthcare is difficult to overstate. He has steered FHIR through the treacherous waters of vendor politics, regulatory pressure, and academic debate with a steady hand and a clear vision. He is, in the words of one colleague, “the person who actually makes this stuff work.”
The core FHIR team at HL7 includes a rotating cast of experts from around the world: Lloyd McKenzie, a Canadian informaticist who has contributed to virtually every resource in the specification; Ewout Kramer, a Dutch developer who built some of the earliest and most influential FHIR implementations; James Agnew, a Canadian who created HAPI FHIR, the most widely used open-source FHIR server; and many others.
The Argonaut Project
In 2014, a group of EHR vendors, healthcare systems, and technology companies formed the Argonaut Project to accelerate the adoption of FHIR. The founding members included Epic, Cerner, athenahealth, McKesson, Meditech, Surescripts, and The Advisory Board Company, along with several large health systems.
The Argonaut Project was a pragmatic response to a practical problem: FHIR was promising, but it was not yet ready for prime time. The specification was incomplete. Implementation guides were missing. Vendors were uncertain about what to build and how to build it. The Argonaut Project brought the key players together to define a core set of FHIR capabilities, develop implementation guides, and conduct interoperability testing.
The project was remarkably successful. It produced the Argonaut Data Query Implementation Guide, which defined a minimal set of FHIR resources and operations for patient access. This guide became the basis for the patient access requirements in the 21st Century Cures Act. It demonstrated that competitors could collaborate on standards when the incentives were aligned, and it established a model for public-private partnership in healthcare IT that has been emulated since.
The ONC, CMS, and the Regulatory Apparatus
Government agencies have played an outsized role in FHIR’s adoption. The Office of the National Coordinator for Health Information Technology (ONC), part of the Department of Health and Human Services, has been the primary driver of interoperability policy in the United States. The Centers for Medicare & Medicaid Services (CMS) has used its regulatory leverage—control over the vast flows of federal healthcare dollars—to mandate FHIR adoption for specific use cases.
Dr. Donald Rucker, who served as National Coordinator from 2017 to 2021, was a particularly forceful advocate for FHIR and API-based interoperability. Under his leadership, the ONC’s Cures Act Final Rule established FHIR as the mandatory standard for patient access and set aggressive timelines for implementation. The rule was controversial—vendors sued, deadlines slipped, the pandemic intervened—but it fundamentally altered the trajectory of the market.
Regulatory pressure is not a substitute for technical excellence, but it can accelerate adoption in ways that market forces alone cannot. FHIR’s success is a case study in how standards, technology, and policy can reinforce each other.
How FHIR Actually Works: A Walkthrough
Let us get concrete. Let us follow a single piece of health data as it moves through a FHIR-enabled system, from the moment it is created to the moment it is consumed.
The Scenario
Maria Hernandez—remember her? 742 Evergreen Terrace, born March 12, 1985—visits her primary care physician for a routine checkup. The nurse takes her blood pressure. It is 142 over 88. Slightly elevated. The nurse enters the reading into the EHR.
Step One: Creation
The EHR system creates a FHIR Observation resource. It looks something like this:
{
"resourceType": "Observation",
"id": "bp-2026-06-23-001",
"status": "final",
"category": [
{
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/observation-category",
"code": "vital-signs",
"display": "Vital Signs"
}
]
}
],
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "85354-9",
"display": "Blood pressure panel with all children optional"
}
]
},
"subject": {
"reference": "Patient/example-patient-001"
},
"effectiveDateTime": "2026-06-23T09:30:00Z",
"component": [
{
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "8480-6",
"display": "Systolic blood pressure"
}
]
},
"valueQuantity": {
"value": 142,
"unit": "mmHg",
"system": "http://unitsofmeasure.org",
"code": "mm[Hg]"
}
},
{
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "8462-4",
"display": "Diastolic blood pressure"
}
]
},
"valueQuantity": {
"value": 88,
"unit": "mmHg",
"system": "http://unitsofmeasure.org",
"code": "mm[Hg]"
}
}
]
}Notice the layers of meaning embedded in this resource. The category tells us this is a vital sign. The code tells us, using the LOINC terminology, that this is a blood pressure measurement. The subject links to Maria’s Patient resource. The effectiveDateTime tells us when the measurement was taken. The component array breaks the blood pressure into its systolic and diastolic parts, each with its own LOINC code and quantitative value.
This is not merely a number. This is a semantically rich, computable assertion about a specific patient’s physiological state at a specific moment in time.
Step Two: Storage
The EHR system stores this resource in its database. If the EHR is built on a modern, FHIR-native architecture, the resource might be stored as-is, in JSON format, in a document database like MongoDB or a FHIR-specific server like HAPI FHIR or Smile CDR. If the EHR is a legacy system, the resource might be generated on-the-fly from the system’s internal data model, translated into FHIR format only when needed for exchange.
Step Three: Access
Maria opens her patient portal app on her phone. The app requests her recent vital signs from the EHR’s FHIR API. The EHR authenticates Maria using OAuth 2.0—she logs in with her username and password, and the app receives an access token. The app sends an HTTP GET request:
GET https://api.springfield-clinic.org/fhir/R4/Observation?patient=example-patient-001&category=vital-signs&_sort=-date&_count=5The EHR responds with a Bundle containing Maria’s five most recent vital sign observations, including the blood pressure reading from this morning. The app parses the JSON, extracts the systolic and diastolic values, and displays them in a friendly chart. Maria sees that her blood pressure is slightly elevated and makes a mental note to cut back on salt.
Step Four: Exchange
Maria’s doctor, concerned about the elevated reading, decides to refer her to a cardiologist. The referral system at Springfield Clinic generates a FHIR ReferralRequest resource and sends it to the cardiology practice’s system via a secure FHIR endpoint. The cardiology system receives the referral, creates an appointment, and pulls Maria’s relevant health history—including her blood pressure readings, her medication list, and her family history of hypertension—via FHIR queries.
None of this requires manual data entry. None of it requires faxing. None of it requires Maria to fill out another clipboard in another waiting room. The data flows, seamlessly and securely, from system to system, in a format that every system understands.
This is the promise of FHIR. This is the future that its architects envisioned. And in the best-case scenarios, this is the reality that patients and providers are beginning to experience.
The Friction: What FHIR Cannot Yet Do
It would be dishonest to present FHIR as a panacea. It is not. It is a standard, and like all standards, it is imperfect, incomplete, and contested.
The Implementation Gap
The gap between the FHIR specification and real-world implementations remains wide. A vendor can claim “FHIR compliance” while supporting only a subset of resources, a subset of operations, and a subset of search parameters. The ONC’s certification requirements have narrowed this gap, but they have not eliminated it. Two systems can both be “certified” and still fail to interoperate in meaningful ways.
This is the problem of conformance. The FHIR specification defines what is possible. Implementation guides define what is required for specific use cases. But actual implementations vary in their adherence to these guides. Testing and validation tools—like Inferno, the ONC’s testing framework—help, but they cannot catch every deviation.
The Identity Problem
Healthcare has no universal patient identifier in the United States. This is not a technical limitation; it is a political one. Concerns about privacy and government overreach have repeatedly blocked the creation of a national patient ID. The result is that every healthcare organization maintains its own set of patient identifiers, and matching patients across systems—known as patient matching or record linkage—remains an error-prone, probabilistic art.
FHIR does not solve this problem. It provides mechanisms for identifying patients within a system and linking to external identifiers, but it cannot create a universal identifier where none exists. Patient matching algorithms rely on demographic data—name, birth date, address, Social Security number—and these data are often incomplete, outdated, or inconsistent. The consequences of a mismatch are severe: the wrong patient’s records merged, the right patient’s records split, diagnoses attached to the wrong person, treatments delayed or denied.
The Semantic Gap
FHIR provides the syntax for health data exchange. It does not, by itself, ensure that the data means the same thing to the sender and the receiver. A blood pressure reading of 142/88 might be “elevated” in one clinical context and “normal” in another, depending on the patient’s age, comorbidities, and the measurement protocol. A diagnosis of “diabetes” might be Type 1, Type 2, gestational, or secondary, with profound implications for treatment.
FHIR’s terminology bindings help, but they are not exhaustive. Many clinical concepts resist easy coding. Narrative text—clinical notes, radiology reports, pathology reports—remains largely unstructured, and while FHIR can carry narrative data, it cannot, by itself, make that data computable. Natural language processing and machine learning are making progress on this front, but the problem of extracting meaning from clinical text remains unsolved.
The Business of Blocking
Information blocking—the practice of interfering with the access, exchange, or use of electronic health information—remains a significant barrier. The 21st Century Cures Act prohibits it, but prohibition and elimination are not the same thing. Vendors and healthcare organizations have found ways to technically comply with FHIR requirements while creating friction that discourages actual data exchange. Excessive fees. Burdensome registration processes. Opaque API documentation. Deliberately limited functionality.
The ONC has enforcement mechanisms, but enforcement is slow and resource-intensive. The economic incentives for data hoarding remain powerful. Healthcare is a competitive market, and data is a competitive advantage. Vendors that have invested billions of dollars in building proprietary ecosystems are not eager to see that data flow freely to competitors.
FHIR is a technical standard. It cannot, by itself, overcome economic and political resistance. It is a necessary condition for interoperability, but it is not sufficient.
The Global Challenge
FHIR was developed primarily in the United States, for the United States healthcare system. Its adoption has been driven by US regulatory requirements. While HL7 is an international organization and FHIR is explicitly designed to be globally applicable, the reality is that healthcare systems vary enormously across countries, and a standard that works for the US may need significant adaptation elsewhere.
European countries, with their national health services and strong privacy regulations (the General Data Protection Regulation, or GDPR, imposes requirements that go beyond anything in US law), have been cautious adopters. Some have embraced FHIR enthusiastically—the United Kingdom’s National Health Service has developed extensive FHIR profiles. Others have preferred to develop their own standards or to adapt FHIR in ways that diverge from the US model.
Low- and middle-income countries face a different set of challenges. They may lack the technical infrastructure, the trained workforce, and the regulatory frameworks needed to implement FHIR effectively. International development organizations have supported FHIR adoption in these contexts, but progress has been uneven.
The Deeper Layers: FHIR and the Future of Medicine
If we zoom out—way out—we can see FHIR not merely as a technical standard but as a manifestation of a larger shift in how we think about health, data, and the relationship between them.
From Documents to Data
For most of medical history, health information was narrative. Doctors wrote notes. Nurses wrote notes. These notes were stored in paper charts, read by human eyes, and interpreted by human minds. The electronic health record, in its early incarnations, largely replicated this model: it digitized the paper chart, but it did not fundamentally restructure it.
FHIR represents a move away from the document model and toward the data model. It treats health information as discrete, structured, computable elements that can be aggregated, queried, analyzed, and acted upon by algorithms as well as humans. This is not a neutral shift. It changes what kind of knowledge is valued, who can access it, and how it can be used.
A narrative note can capture nuance, ambiguity, and clinical judgment in ways that a structured data element cannot. A FHIR Observation resource cannot convey a doctor’s uncertainty, a patient’s fear, or the complex social context of a disease. The shift to structured data risks flattening the richness of clinical experience into checkboxes and drop-down menus.
But structured data also enables things that narrative notes cannot. It enables population health analytics that identify disease outbreaks before they become epidemics. It enables clinical decision support that prevents medication errors at the point of prescribing. It enables research that spans millions of patients and discovers treatments that no single clinician could have imagined.
The challenge is to preserve the strengths of both models. FHIR attempts this through its support for narrative text alongside structured data. But the tension between narrative and structure, between human judgment and algorithmic precision, is a defining feature of modern medicine, and it will not be resolved by any standard, however elegant.
The Patient as Data Steward
FHIR, particularly when combined with SMART on FHIR and patient access APIs, enables a shift in the locus of control over health data. Traditionally, health data has been controlled by healthcare organizations. The hospital owned the chart. The doctor wrote in it. The patient was a passive subject, granted access to their own information only as a courtesy or a legal requirement.
FHIR makes it technically feasible for patients to control their own health data—to aggregate it from multiple sources, to share it with whomever they choose, to analyze it with their own tools, to contribute it to research studies on their own terms. This is a profound shift in the power dynamics of healthcare.
Whether it becomes a reality depends on factors beyond technology. It depends on patient education, on the design of user-friendly tools, on regulatory frameworks that protect against exploitation, and on a cultural shift in how we think about the ownership of personal data. FHIR provides the plumbing. The architecture of patient empowerment is still being designed.
AI, Machine Learning, and the Computational Patient
The rise of artificial intelligence in healthcare is inseparable from the rise of structured, interoperable data. Machine learning algorithms are voracious consumers of data, and they require that data to be standardized, labeled, and accessible. FHIR is, in this sense, the substrate upon which the AI revolution in healthcare will be built.
Researchers are already using FHIR-based datasets to train models for disease prediction, drug discovery, and personalized treatment recommendation. The MIMIC-IV dataset, a widely used resource for critical care research, has been converted to FHIR format. The All of Us Research Program is using FHIR to structure its multimodal health data. Companies like Google Health, IBM Watson Health (rest in peace), and a host of startups are building AI pipelines that consume FHIR resources as their raw material.
This raises profound questions. Who owns the models trained on patient data? How do we ensure that AI systems are fair, transparent, and accountable? What happens to the doctor-patient relationship when algorithms can diagnose diseases more accurately than human physicians? FHIR does not answer these questions, but it creates the conditions under which they become urgent.
The Quantified Self and the Datafication of Health
Beyond the clinic, beyond the hospital, beyond the research laboratory, FHIR is converging with the consumer health revolution. Wearable devices—Fitbits, Apple Watches, continuous glucose monitors, sleep trackers—generate torrents of health data that were unimaginable a decade ago. This data is, for the most part, siloed in proprietary apps and clouds, disconnected from the clinical record.
FHIR provides a pathway for integrating consumer-generated health data with clinical data. The FHIR specification includes resources for device metrics, observations from home monitoring, and patient-reported outcomes. The Apple Health ecosystem uses FHIR to bridge the gap between consumer devices and clinical records. The goal is a continuous, comprehensive health record that spans the hospital, the home, and the spaces in between.
This vision is seductive. It promises a medicine that is proactive rather than reactive, personalized rather than one-size-fits-all, continuous rather than episodic. But it also raises concerns about surveillance, about the medicalization of everyday life, about the power of tech companies to monetize the most intimate data imaginable. The quantified self can become the commodified self with alarming speed.
Looking Beyond: The Standard That Became a World
We began with a waiting room. A clipboard. A patient named Maria Hernandez, writing her history for the hundredth time while computers hummed in the background, unable to speak.
We end somewhere else.
FHIR is not a magic wand. It will not, by itself, fix the fragmentation of American healthcare, or the inequities of global health, or the existential challenges of an aging population and a warming planet. It is a standard—a set of agreements, encoded in specifications and implementation guides, enforced by regulation and validated by testing. It is plumbing. It is infrastructure. It is the kind of thing that is invisible when it works and catastrophic when it fails.
But infrastructure matters. The Roman roads were not merely a way of moving legions; they were a way of moving ideas, of creating a shared world across distance and difference. The internet was not merely a way of sending emails; it was a way of reorganizing human knowledge, commerce, and sociality. FHIR is not merely a way of exchanging health records; it is a way of reorganizing the information architecture of medicine, of creating a shared substrate upon which new forms of care, research, and patient empowerment can be built.
The historians of the future—if we are lucky enough to have them, if we are wise enough to deserve them—may look back on the early twenty-first century as the moment when healthcare data began to flow. They may note the decades of fragmentation that preceded it, the fax machines and the paper charts and the proprietary silos. They may note the pandemic that exposed the fragility of the old order and the standard that offered a path to something better. They may note the patients who died because data did not flow, and the patients who lived because it finally did.
Or they may note something else entirely. FHIR may fail. It may be superseded by a better standard, or overwhelmed by proprietary alternatives, or rendered irrelevant by technologies we cannot yet imagine. The future is not determined. Standards are choices, and choices can be unmade.
What is certain is that the problem FHIR addresses—the problem of making health information accessible, understandable, and actionable across the boundaries of organizations, disciplines, and nations—is not going away. It will only become more urgent as medicine becomes more complex, as data becomes more abundant, and as the expectations of patients and societies evolve.
FHIR is one answer to this problem. It is, at its best, an elegant answer: pragmatic where it needs to be, rigorous where it can be, flexible where it must be. It is the product of a particular community, at a particular moment, with particular values—values of openness, of collaboration, of the belief that information wants to be free, or at least that it ought to be freer than it is.
Whether those values prevail is up to us. The standard has been written. The APIs have been defined. The regulations have been issued. What remains is the work of implementation, of advocacy, of holding vendors and institutions accountable, of building the applications and the ecosystems and the cultural shifts that will make FHIR not merely a specification but a lived reality for every patient who walks into a waiting room, picks up a clipboard, and wonders, with weary resignation, why they have to write their history down one more time.
The answer is: they shouldn’t have to. And someday, perhaps soon, they won’t.
The data will know them. The data will follow them. The data will speak for them, across systems and borders and the silos that have walled medicine off from itself for far too long.
This is the promise of FHIR. It is a promise still being kept, still being broken, still being fought for in conference rooms and code repositories and regulatory hearings and hospital basements where servers hum in the dark.
It is, in the end, a very human promise: that we can agree on something, that we can build something together, that the complexity of the body and the complexity of the world can be met with something other than fragmentation and despair.
The fire is lit. Whether it warms or consumes remains to be seen.
P.S. For those who wish to dig deeper, the canonical source is the FHIR specification itself, maintained by HL7 International at hl7.org/fhir. The SMART on FHIR specification lives at smarthealthit.org. The Argonaut Project’s implementation guides are archived at argonautwiki.hl7.org. And for the masochists among you, the author’s own blood pressure—captured, naturally, in a FHIR Observation resource—remains stubbornly, gloriously, humanly variable.