FHIR (pronounced “fire”) stands for Fast Healthcare Interoperability Resources.
It is a healthcare data exchange standard created by HL7 International that gives different systems — EHRs, lab systems, payer platforms, patient apps, and clinical tools — a common way to represent and share health information using modular building blocks called resources and modern API patterns.
Unlike older HL7 standards that rely on event-driven messaging or document-based exchange, FHIR uses RESTful APIs, JSON, and XML formats familiar to web developers.
The result is a standard that can support hospital integrations, patient-facing apps, payer data exchange, quality measurement, clinical decision support, and population health workflows through a single architectural model.
A 2025 ONC data brief found that 70% of U.S. hospitals enabled patient access using standards-based APIs such as FHIR in 2024.
A 2025 global survey of 82 FHIR experts across 52 countries found that 71% reported active FHIR use, with R4 as the dominant production version in 31 countries.
Here is what this guide covers:
- How SMART on FHIR handles security
- How FHIR differs from HL7 v2 and CDA
- Where FHIR fits in U.S. interoperability policy
- Benefits, limitations, and implementation steps
- Why profiles and implementation guides are needed
- How FHIR works (resources, APIs, and data formats)
How does FHIR work?
FHIR breaks healthcare information into standardized building blocks called resources.
Each resource represents a healthcare concept — a patient, a lab result, a medication order, an encounter, an allergy — and can be independently created, read, updated, searched, or deleted through API calls.
FHIR ARCHITECTURE
How FHIR data moves from definition to exchange
Resource
Standard data building block
Profile
Constraints for a use case
Impl Guide
Rulebook for a workflow
FHIR API
Real-world data exchange
FHIR APIs use standard HTTP methods
- Read — retrieve a specific resource (GET)
- Search — query resources by parameters (GET with search params)
- Create — add a new resource (POST)
- Update — modify an existing resource (PUT)
- Delete — remove a resource (DELETE)
Data is typically transmitted in JSON (most common for APIs and apps) or XML (used in some document and validation contexts).
What are FHIR resources?
Resources are the core data objects in FHIR. Each represents a distinct healthcare concept and can be independently addressed, exchanged, and linked to other resources.
| FHIR resource | Represents | Example use |
| Patient | Demographics and identifiers | Find or verify a patient record |
| Observation | Measurements and findings | Blood pressure, lab value, vital sign |
| Encounter | A healthcare visit or interaction | Office visit, hospital admission |
| MedicationRequest | Medication order or prescription | Active prescription for a patient |
| AllergyIntolerance | Allergy or sensitivity | Penicillin allergy |
| DiagnosticReport | Diagnostic findings | Lab panel, imaging report |
| Condition | Problem, diagnosis, or concern | Diabetes, hypertension |
| Procedure | Clinical action performed | Surgery, vaccination |
| Coverage | Insurance or payer information | Health plan details |
| Claim | Billing or payment request | Submitted healthcare claim |
How does FHIR differ from HL7 v2 and CDA?
FHIR is part of the HL7 standards family — not a replacement for everything that came before it. HL7 International is the organization; FHIR is one of several standards it maintains.
| Standard | Model | Common format | Best for |
| HL7 v2 | Event-driven messages (segments and fields) | Pipe-delimited text | Hospital interfaces — ADT, orders, results, billing |
| CDA | Document-based clinical exchange | XML | Clinical documents — discharge summaries, care records |
| FHIR | Resource-based API exchange | JSON or XML | Apps, APIs, patient access, modern data exchange |
HL7 v2 remains one of HL7’s most widely adopted standards, prominent in inpatient settings worldwide.
FHIR and v2 often coexist — organizations may keep v2 interfaces for legacy hospital workflows while building FHIR APIs for app access, payer exchange, and new integrations.
The practical mistake is assuming FHIR automatically replaces v2. Migration is a project, not a toggle.
Why do FHIR implementations need profiles and implementation guides?
Base FHIR resources are intentionally flexible.
A Patient resource can represent patient data in many different ways. That flexibility is a strength for the standard, but a problem for interoperability — because two systems using the same resource can still structure the data differently.
Profiles constrain base resources for specific use cases. A profile might require specific fields, restrict code systems, or add extensions for data that the base resource doesn’t cover.
Implementation guides (IGs) package profiles, terminology rules, examples, and interaction patterns into a complete specification for a use case or jurisdiction.
US Core is the U.S. Realm FHIR implementation guide that defines baseline profiles and interactions for patient data exchange. It maps to USCDI (the federal baseline dataset) and is central to U.S. certification and patient-access API requirements.
A 2024 scoping review of FHIR in chronic disease management found that only about 20% of reviewed applications referenced implementation guides — a sign that profile and IG discipline remains a weak point in real-world FHIR adoption.
How does SMART on FHIR handle security?
FHIR defines data structures and API patterns. Security is handled through complementary frameworks — primarily SMART on FHIR and OAuth 2.0.
SMART on FHIR provides a standard way for apps to
- Launch securely within an EHR workflow
- Authenticate users through OpenID Connect
- Operate within patient or practitioner context
- Request specific data access through OAuth scopes
The principle is minimum necessary access — apps should request only the FHIR scopes they need for their function.
A 2024 VA study of telesupervision found that supervisors were more confident than trainees that essential security elements were maintained during remote work — a reminder that security architecture and user experience of security are not always aligned.
FHIR enables secure exchange, but it does not automatically guarantee compliance.
HIPAA, state privacy rules, consent management, and organizational policy still govern how data is accessed, shared, and protected.
Where does FHIR fit in U.S. interoperability policy?
FHIR has moved from a voluntary standard to a regulatory building block.
ONC’s Cures Act Final Rule requires standardized APIs so patients can securely access structured health information through apps.
CMS’s 2024 Interoperability and Prior Authorization Final Rule requires impacted payers to implement and maintain certain HL7 FHIR APIs, with most API requirements taking effect by January 1, 2027.
| Policy area | FHIR role |
| Patient access | API access to health information under ONC/CMS rules |
| Provider access | Payer-to-provider data sharing |
| Payer-to-payer exchange | Data continuity when coverage changes |
| Prior authorization | API-supported request and response workflows |
| USCDI / US Core | Defines data classes and FHIR profiles for U.S. implementation |
HHS announced in June 2026 that TEFCA exchange grew to more than 1 billion health records in less than one year. While TEFCA is not FHIR, it is part of the national exchange infrastructure that FHIR-based APIs increasingly support.
What are the benefits and limitations of FHIR?
Here are the benefits and limitations of FHIR, weighed in:
FHIR ADOPTION
Where FHIR stands in production healthcare
70%
Of U.S. hospitals using FHIR-based APIs for patient access (2024)
71%
Of 52 surveyed countries reporting active FHIR use (2025)
73%
Of digital health companies using standards-based APIs with EHRs
57%
Of digital health companies also using proprietary APIs alongside FHIR
Sources — ONC Data Briefs (2025–2026), HL7/Firely Survey (2025), Barker et al. JAMIA (2024)
FHIR creates real value when it is implemented consistently. Benefits include
- A common model for representing health data across systems
- Reduced custom integration work when profiles and IGs are followed
- Alignment with U.S. regulatory requirements for data access and exchange
- API patterns that support patient access, app development, and payer exchange
But FHIR does not solve everything by itself
- Security and consent governance require separate design
- R4 and R5 version differences create compatibility decisions
- Data quality varies — APIs expose what the source system contains
- Profile and IG conformance is uneven across vendors and organizations
- Semantic interoperability still depends on consistent terminology and coding
A 2024 JAMIA survey found that even among FHIR-adopting digital health companies, 47% cited high API fees, 41% cited lack of realistic test data, and 40% cited insufficient data elements as substantial barriers.
How should organizations start implementing FHIR?
A practical implementation checklist:
9 Steps for a Successful FHIR Implementation
Work through each checkpoint before moving to production.
When interoperability meets revenue
FHIR-based APIs increasingly drive how patient data, payer authorization, and claims information move between systems.
When those connections break down, practices face delayed authorizations, incomplete data, and avoidable denials.
MedHeave helps healthcare providers build the operational bridge between clinical data exchange and revenue cycle performance.
- Claims and authorization workflows connected to payer data exchange
- EHR integration support for billing and documentation systems
- Denial management tied to data completeness and interoperability gaps
- Compliance documentation for payer and certification requirements
Contact MedHeave to connect your interoperability investments to your revenue cycle.
Frequently asked questions
Here are some commonly asked questions about FHIR:
FHIR is a healthcare data exchange standard that lets different systems share health information using a common structure. It breaks medical data into modular building blocks called resources — such as Patient, Observation, MedicationRequest, and Encounter — and makes them accessible through modern web APIs. FHIR is created by HL7 International, is pronounced “fire,” and is now used by the majority of U.S. hospitals for patient-access APIs. It supports app development, payer data exchange, quality reporting, and clinical decision support.
HL7 International is the standards organization that publishes FHIR and other healthcare interoperability standards. FHIR is one specific HL7 standard — the modern, API-focused one using resources and JSON/XML. HL7 v2 is an older, widely used messaging standard that remains common for hospital interfaces like ADT, lab orders, and results. CDA is another HL7 standard designed for clinical document exchange. FHIR, v2, and CDA often coexist in the same organization because they serve different workflows and integration patterns.
Yes. FHIR is actively used and growing. HL7 lists FHIR R5 as the current published version, while R4 remains the dominant production version because major U.S. implementation guides (including US Core) and regulatory requirements still reference R4. ONC found that 70% of U.S. hospitals used FHIR-based APIs for patient access in 2024. CMS requires impacted payers to implement FHIR APIs by January 2027. FHIR is not declining — but version choice depends on the implementation guide and use case.
A FHIR profile constrains a base resource for a specific use case. Base FHIR resources are intentionally flexible, so profiles narrow them by requiring certain fields, restricting code systems, or adding extensions. For example, a US Core Blood Pressure profile constrains the Observation resource to require specific LOINC codes, systolic and diastolic components, and UCUM units. Profiles are packaged inside implementation guides, which define the complete rules for exchanging data in a particular context or jurisdiction.
In certain U.S. programs, specific FHIR-based APIs are required. ONC’s Cures Act Final Rule requires standardized APIs for patient access to structured health information. CMS’s 2024 interoperability rule requires impacted payers to implement FHIR-based Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs. Requirements vary by actor type, program, and compliance deadline. Outside the U.S., FHIR adoption is growing but regulatory mandates vary by country. Organizations should verify which FHIR version and implementation guide their specific requirements reference.
