Written and maintained by CASRAI Editorial Board
Last updated
Quick answer: FHIR (Fast Healthcare Interoperability Resources, pronounced “fire”) is a modern data standard, published by HL7 International, for exchanging health information electronically. It defines a common set of “Resources” — small, well-defined data objects like Patient, Observation, Condition, and MedicationRequest — and a way to move them between systems over standard web technology: REST APIs and JSON (or XML), the same technical pattern most modern web and mobile software already uses. FHIR exists to replace slower, harder-to-integrate older health-data formats with something a typical software developer can pick up and build against without specialized health-IT training. For a research organization, FHIR is most often encountered as the mechanism by which data moves out of a hospital’s electronic health record (EHR) and into a research database, a real-world-evidence study, or a clinical data warehouse.
nn
What Does FHIR Stand For, and Who Maintains It?
n
FHIR stands for Fast Healthcare Interoperability Resources. It is developed and maintained by HL7 International (Health Level Seven International), the same standards development organization behind the older HL7 Version 2 (HL7 v2) messaging standard and HL7 Clinical Document Architecture (CDA) — see What Is HL7? for the parent organization and its earlier standards. FHIR is not a competitor to HL7; it is HL7’s own next-generation standard, built specifically to fix adoption and integration problems that HL7 v2 and CDA left unsolved. FHIR has gone through several released versions (DSTU2, STU3, and the current widely-deployed R4, with R5 available), and most production EHR interoperability today runs on R4 or a close variant of it.
nn
What Problem Does FHIR Actually Solve?
n
Before FHIR, moving clinical data between two systems — two hospitals, an EHR and a research database, an EHR and a patient-facing app — typically meant custom, one-off integration work. Older standards like HL7 v2 and CDA are genuinely capable of representing clinical data, but they use formats (pipe-delimited segments for v2, large structured XML documents for CDA) that most general-purpose software developers have never worked with and that don’t map cleanly onto the tools used to build ordinary web and mobile applications. Every new connection tended to require health-IT-specialist effort, which made data exchange slow and expensive to build and kept a lot of clinical data effectively locked inside whichever system first captured it.
n
FHIR’s design choice was to stop inventing health-IT-specific plumbing and instead build on the same REST/JSON patterns used across the rest of the software industry. A developer who has built against any modern web API already understands most of how a FHIR API works; the health-specific part is the resource model (what a “Patient” or “Observation” resource contains), not the transport mechanism. That lowers the cost of building a new integration and is the main reason FHIR adoption accelerated sharply once EHR vendors began exposing FHIR APIs as a standard feature rather than a custom project.
nn
How FHIR Works: Resources, APIs, and Profiles
n
FHIR organizes clinical and administrative information into Resources — discrete, purpose-built data objects, each representing one kind of real-world thing: Patient (demographics), Observation (a vital sign, lab result, or other measurement), Condition (a diagnosis or problem), MedicationRequest (a prescription order), DocumentReference, Encounter, and well over a hundred others covering most of what a health record contains. Each resource type has a defined structure, and systems exchange them either by calling a FHIR REST API (e.g., requesting a specific patient’s Observations) or by bundling resources into a message or document.
n
Because real-world use cases need more precision than a generic resource definition alone provides, FHIR also supports Implementation Guides and profiles — constraints on top of the base resources that specify exactly which fields are required and what value sets apply for a particular country, program, or use case. In the U.S., the US Core profile and the underlying United States Core Data for Interoperability (USCDI) data set are what most EHR-to-EHR and EHR-to-app data exchange is actually built against; U.S. federal interoperability policy built on the 21st Century Cures Act has pushed EHR vendors toward exposing standardized, FHIR-based APIs for patient and provider access. Other countries and programs maintain their own FHIR implementation guides for the same reason: FHIR itself is a flexible base standard, and the profile is what makes two independently built systems actually interoperable with each other.
nn
FHIR vs. HL7 v2 and CDA: What’s the Difference?
n
FHIR, HL7 v2, and CDA are all HL7 standards, and in practice a large health system runs all three at once for different purposes — this is one of the most common points of confusion for anyone new to the space. See What Is HL7? for a fuller comparison of the family; briefly:
n
- n
- HL7 v2 is a messaging standard, still the dominant way hospital systems exchange real-time event notifications internally — a new admission, a lab result becoming available, an order being placed. It moves fast and is deeply embedded in existing hospital interface engines, which is why it hasn’t disappeared even as FHIR has grown.
- CDA (Clinical Document Architecture), and its U.S. constraint C-CDA, represents a complete clinical document — a discharge summary or continuity-of-care document meant to be read as a whole, human-readable record, not queried piece by piece.
- FHIR represents discrete, individually addressable data elements accessed via a web API, which is what makes it suited to modern app-style integrations, dashboards, and pulling just the specific data elements a research query needs, rather than an entire document or message stream.
n
n
n
n
None of the three is simply “the new version” of the others; they solve different integration problems, and current U.S. and international interoperability guidance generally treats FHIR as the standard to build new integrations on, while v2 and CDA remain in place for the workflows they already handle.
nn
Why FHIR Matters for Research Data Access
n
For research administration specifically, FHIR is usually the layer that determines how hard (or easy) it is to get clinical data out of a source EHR and into a research-usable form. A few concrete places this shows up:
n
- n
- EHR-to-research-database pipelines. Tools like REDCap and other electronic data capture (EDC) systems increasingly offer FHIR-based import connectors, letting study teams pull structured EHR data (labs, medications, encounters) directly into a study database instead of manual chart abstraction.
- Real-world data and real-world evidence studies. Real-world evidence (RWE) research depends on assembling clinical data from EHRs across multiple sites; FHIR is one of the standard interfaces used to extract that data before it’s harmonized into a common analytical format, such as the OMOP common data model.
- Multi-site and federated studies. Because FHIR gives every participating EHR a consistent API shape, it reduces (though doesn’t eliminate) the custom integration work needed when a study spans institutions running different EHR platforms — see Epic vs. Oracle Health (Cerner) for how differently two major EHR vendors otherwise diverge.
- Health-system interoperability compliance work. Hospital IT and compliance teams tracking federal interoperability requirements — see Promoting Interoperability Program — are frequently the same teams a research office has to coordinate with to get a FHIR-based data-access agreement or API connection approved.
n
n
n
n
n
Getting data out via a FHIR API doesn’t remove the usual research-compliance steps — IRB review, a data use agreement, and HIPAA-compliant handling of the underlying protected health information still apply regardless of which technical standard moved the data (see HIPAA and Retrospective Research). FHIR determines how the data gets extracted; it doesn’t change who is allowed to see it or under what authorization.
nn
Who in a Research Organization Actually Deals With FHIR
n
FHIR rarely shows up as something a principal investigator configures directly. In practice it’s most relevant to:
n
- n
- Research informatics and clinical data warehouse staff, who build or maintain the pipelines that pull FHIR data from the EHR into research-usable storage.
- Clinical research coordinators and data managers on studies that use an EHR-integrated EDC, where FHIR is what makes “auto-populate this field from the chart” possible instead of manual re-entry.
- Research IT and health-system informatics teams negotiating what data a given FHIR API endpoint will expose to a research use case, and under what data-governance terms.
- Research compliance and privacy staff, who need to understand that a FHIR connection is a data flow requiring the same HIPAA/IRB scrutiny as any other extraction from the EHR, not a technical detail that sits outside their review.
n
n
n
n
n
Understanding FHIR at the level covered here — what it is, what problem it solves, and how it differs from the older HL7 standards it sits alongside — is usually enough for anyone in these roles to have an informed conversation with the technical staff who build and maintain the actual integration.
nn
Frequently Asked Questions
n
Is FHIR a database?
n
No. FHIR is a data standard and API specification — a way of structuring and exchanging health data — not a database product or storage system. A FHIR server sits in front of some underlying data store and exposes it through the FHIR API.
n
Does FHIR replace HL7 v2 or CDA?
n
Not outright. FHIR is the standard most new integrations are built on, but HL7 v2 remains heavily used for real-time internal hospital messaging, and CDA/C-CDA documents are still exchanged for complete clinical-document use cases. Most health systems run all three simultaneously.
n
Is FHIR only used in the United States?
n
No. FHIR is an international HL7 standard, and multiple countries and health systems maintain their own national or program-specific FHIR implementation guides. The U.S. Core / USCDI profile is simply one prominent example, driven by U.S. federal interoperability policy.
n
Do researchers need to learn FHIR themselves?
n
Usually not in technical depth. Most research staff need to know what FHIR is and what kind of data flow it represents so they can work effectively with informatics, IT, and compliance colleagues who do build and govern the actual connections — the technical implementation is typically handled by research informatics or health-system IT staff.
n
What is a “FHIR Resource”?
n
A Resource is FHIR’s basic building block — a defined data object representing one kind of clinical or administrative concept, such as Patient, Observation, Condition, or MedicationRequest. Systems exchange information by requesting, sending, or bundling these resources rather than free-form documents.
n
