What is FHIR (Fast Healthcare Interoperability Resources)
FHIR (Fast Healthcare Interoperability Resources) is a healthcare data exchange standard developed by HL7 (Health Level Seven International). It provides a modern, web-based framework for sharing electronic health information across systems, using familiar technologies like RESTful APIs and JSON.
FHIR is designed to improve interoperability between electronic health records (EHRs), payers, providers, and patients. It breaks health information into modular building blocks called “resources,” which cover areas such as patients, medications, laboratory results, and claims.
FHIR integrates with other standards, using SNOMED CT for clinical terminology, LOINC for lab and observation data, and UCUM for units of measure. It also complements document-based standards like C-CDA, which was widely used before FHIR.
By making health data easier to exchange and integrate, FHIR supports patient access, care coordination, analytics, and regulatory requirements, and it underpins the technology infrastructure needed for Value-Based Care (VBC).
Key Components of FHIR (Fast Healthcare Interoperability Resources)
FHIR was created by HL7 International to modernize healthcare data exchange. Unlike older standards that relied heavily on large, rigid documents, FHIR is designed around flexible, modular “resources” that can be easily shared using modern web technologies. This approach makes it easier for health IT vendors, providers, and payers to connect systems, improve interoperability, and meet regulatory requirements for patient access and data exchange.
FHIR Resources
The building blocks of FHIR are called resources. Each resource is a small, structured unit of health data that can stand alone or be combined with others. Examples include:
- Patient → demographic and identifier information
- Observation → lab results, vital signs, or measurements
- Medication → details about a drug or therapy
- Claim → billing and reimbursement information
Resources are designed to be extensible, meaning they can be adapted for different use cases while keeping a consistent core structure.
FHIR APIs
FHIR uses RESTful APIs to make health data available and exchangeable across systems. This means developers can use standard web technologies like HTTP, JSON, and XML to query and share patient data securely. For example:
- A provider EHR can query another system for recent lab results
- A payer system can request claims information from a hospital
- A patient portal can pull medication lists directly from an EHR
Terminology Integration
FHIR doesn’t replace medical code systems — it relies on them. For accuracy and consistency:
- SNOMED CT provides clinical terminology for conditions, procedures, and findings
- LOINC supplies standardized codes for lab results and observations
- UCUM ensures consistency in units of measure
This integration allows FHIR to transmit not just raw data, but semantically meaningful information.
Interoperability Across Systems
FHIR was designed to make healthcare data exchange more scalable and user-friendly:
- Cross-vendor compatibility → ensures that EHRs and health apps can “talk” to each other
- International adoption → supports multiple countries’ healthcare systems, not just U.S. regulations
- Patient empowerment → APIs give patients direct access to their health information through apps and portals
Regulatory and Industry Role
- FHIR plays a central role in U.S. and global health IT regulations:
- CMS and ONC have mandated FHIR-based APIs for patient access and payer data exchange
- FHIR underpins interoperability rules such as the 21st Century Cures Act
- Commercial health plans, research networks, and population health platforms increasingly require FHIR integration
How FHIR Is Used in Practice
Step 1 — Health Data Is Created
A patient visit, lab test, medication order, or claim generates data inside an EHR, lab system, or payer platform.
Step 2 — Data Is Encoded as FHIR Resources
The system breaks the information into standardized FHIR resources (e.g., a blood test result becomes an Observation resource; patient demographics become a Patient resource). These resources use consistent structures and link to standard terminologies like SNOMED CT, LOINC, and UCUM.
Step 3 — Data Becomes Accessible via API
The healthcare system makes this information available through a FHIR API. This API allows secure, structured access using modern web formats like JSON or XML.
Step 4 — Data Exchange Across Systems
Other entities (EHR vendors, payers, health apps, researchers) can request or send FHIR resources:
- A payer pulls Claim data for reimbursement tracking
- A patient app retrieves Medication and AllergyIntolerance resources from the EHR
- A specialist’s system queries Observation resources for lab results
Step 5 — Data Integration for Use
The resources are combined into a coherent patient record, enabling:
- Clinicians to make better decisions with complete, real-time data
- Patients to access and share their health records easily
- Payers to evaluate claims, quality measures, and value-based care metrics
Step 6 — Outcomes & Analytics
Because the data is standardized, health systems can use it for:
- Population health monitoring
- Quality reporting to CMS and other payers
- Research and innovation in care delivery and health equity
Billing and Reimbursement for FHIR
How FHIR Supports Billing Data
FHIR itself is not a billing code set like ICD-10 or CPT.
Instead, it provides the data exchange framework for transmitting claims, encounters, and payment information.
Resources such as Claim, ClaimResponse, and ExplanationOfBenefit (EOB) allow payers and providers to exchange reimbursement data consistently.
Do FHIR Standards Affect Reimbursement?
- Indirect impact: FHIR ensures billing-related data is interoperable, accurate, and accessible, which reduces denials and administrative errors.
- CMS role: FHIR is required in federal rules like the CMS Interoperability and Patient Access Final Rule, which mandates payer-to-payer data exchange.
- Value-based care (VBC): FHIR enables payers to collect the quality and cost data needed to calculate shared savings, risk adjustment, and performance bonuses.
Limitations of FHIR in Billing
- Not a billing code system: FHIR transmits billing information but still relies on ICD-10, CPT, and HCPCS codes for actual reimbursement.
- Implementation burden: Smaller providers may struggle to adopt FHIR-compliant systems due to cost and IT complexity.
- Variable adoption: Some payers and vendors still use legacy standards (like X12 transactions), which slows FHIR integration.
Future Outlook
- FHIR is expected to become the default data standard for claims, prior authorization, and payment reconciliation.
- Integration with AI-driven analytics could streamline billing workflows and reduce administrative burden over time.
Quality & Equity Implications of FHIR
Improving Data Quality
FHIR creates a common structure for health data, reducing variation across EHRs, labs, and payer systems. By standardizing how patient records, labs, medications, and claims are exchanged, FHIR improves accuracy in reporting and reduces administrative errors.
Enhancing Patient Access
- FHIR APIs allow patients to retrieve their health data through apps and portals.
- Under the 21st Century Cures Act, patients have the right to access their records in real time.
- This supports transparency and empowers patients to make informed decisions about their care.
Supporting Value-Based Care (VBC)
- FHIR enables timely exchange of quality and cost data across providers and payers.
- It makes it easier to track outcomes, measure performance, and manage populations in accountable care models.
- Standardized data exchange reduces gaps that can lead to missed quality benchmarks.
Advancing Health Equity
- FHIR allows integration of social determinants of health (SDOH) data, often captured with Z codes, into patient records.
- It supports cross-system reporting to identify disparities in care delivery.
- Public health agencies can use FHIR-enabled data to monitor inequities and target interventions.
Challenges to Equity
- Uneven adoption: Large systems adopt FHIR faster than smaller practices, potentially widening digital divides.
- Technical barriers: Not all patient-facing apps present data in accessible or usable ways.
- Global variation: While FHIR is international, implementation standards differ, which can slow equity-focused outcomes.
Frequently Asked Questions about FHIR
1. What is FHIR in healthcare?
FHIR (Fast Healthcare Interoperability Resources) is a standard developed by HL7 to improve the exchange of electronic health data using modern web technologies like RESTful APIs and JSON.
2. How does FHIR work?
FHIR organizes health information into modular “resources” such as Patient, Observation, Medication, or Claim. These resources can be shared securely across systems using APIs, enabling interoperability between EHRs, payers, and health apps.
3. Is FHIR the same as HL7?
Not exactly. HL7 is the standards organization that created FHIR. Earlier HL7 standards (like v2, v3, and C-CDA) focused on document or message-based exchange, while FHIR provides a more flexible, web-based approach.
4. Can FHIR be used for billing?
Indirectly. FHIR is not a billing code system like ICD-10 or CPT. Instead, it transmits billing and claims data through resources such as Claim and ExplanationOfBenefit, helping ensure payment information is accurate and interoperable.
5. What is an example of a FHIR resource?
A common example is the Observation resource, which might represent a lab result such as “blood glucose level.” Another is the Medication resource, which lists a patient’s prescribed drugs.
6. Is FHIR required by CMS or federal rules?
Yes. CMS and ONC require FHIR-based APIs under rules like the 21st Century Cures Act and the CMS Interoperability and Patient Access Final Rule, making FHIR adoption mandatory for payers and providers participating in federal programs.
