Overview
FHIR — Fast Healthcare Interoperability Resources, pronounced 'fire' — is the modern healthcare data exchange standard published by HL7. Unlike HL7 v2 (message-based, pipe-delimited, positional) or HL7 v3 (document-based, XML-heavy, slow-adopted), FHIR is a resource-based RESTful API standard using JSON (with XML also supported), patterned on modern web API conventions. FHIR's design goal was to make healthcare integration feel like any other modern API — predictable, documented, and tool-friendly.
FHIR is structured around Resources — discrete, composable data objects representing clinical and administrative concepts. Core clinical Resources include Patient, Encounter, Observation, Condition, Medication, DiagnosticReport, Procedure, Immunization. Core administrative Resources include Coverage, Claim, ClaimResponse, ExplanationOfBenefit, Organization, Practitioner, Location. Each Resource has a defined schema with required, optional, and extensible fields. Profiles (US Core, Da Vinci Payer-Provider implementation guides) constrain and extend the base Resources for specific use cases.
Current dominant version is FHIR R4 (Release 4), published in 2019. FHIR R5 is the latest release but adoption is still early. The 21st Century Cures Act and CMS Interoperability and Patient Access rules mandate FHIR-based APIs for specific data flows: patient access to their own data, payer-provider data exchange via Da Vinci CRD/DTR/PAS, and prior authorization automation. These regulatory drivers have accelerated FHIR adoption substantially.
Revenue cycle use cases for FHIR include: real-time eligibility and benefit inquiry (FHIR 270/271 equivalents); electronic prior authorization via Da Vinci PAS using FHIR PriorAuthorization and Claim resources; Coverage discovery; ExplanationOfBenefit-based member data access; and CRD/DTR for coverage requirements documentation at the point of care. Each of these replaces or complements an X12 EDI transaction with a RESTful FHIR equivalent.
SMART on FHIR is the OAuth-based app authorization framework layered over FHIR. It lets EHR-embedded apps launch with user and patient context, request specific data scopes, and exchange access tokens securely. SMART is the dominant model for third-party app integration with modern EHRs and is what most CMS-mandated patient-access APIs use.
Mature RCM teams treat FHIR API as a lever rather than a report line. The practical move is to set a weekly delta target against the 90-day baseline and make FHIR API the headline metric a biller owner is accountable for, with ehr integration and hl7 interface as the second-tier drivers they report on beneath it. The trap worth naming is denominator drift — a change in payer mix, service line, or even calendar workdays can move FHIR API without any operational issue, so the monthly review should always include a volume-normalized cut alongside the raw number. Reviewers also recommend stratifying by top five payers, because a single payer's policy change will frequently distort an all-payer FHIR API reading.
Industry benchmark
HL7 FHIR R4 is the most widely adopted version. CMS Interoperability rules and ONC USCDI drive FHIR-based API adoption. Da Vinci, CARIN Alliance, and Gravity Project publish implementation guides for specific use cases.
Worked example
A RCM platform integrates with a hospital EHR using FHIR R4. It queries Patient, Coverage, and Encounter resources at registration to populate the billing record; receives Claim and ClaimResponse resources for state-of-claim tracking; and submits PriorAuthorization resources via Da Vinci PAS to automate PA workflow. Compared to legacy HL7 v2 integration, the FHIR-based flow is real-time, bidirectional, and extensible without per-field mapping work.
Frequently asked questions — FHIR API
Is FHIR replacing HL7 v2?
Slowly in specific use cases, not wholesale. FHIR is dominant for modern API integration and regulatory-mandated use cases. HL7 v2 remains the majority of legacy transactional messaging in most health systems. Both will coexist for years.
What is SMART on FHIR?
An OAuth 2.0-based framework for authorizing third-party apps to access FHIR data. It enables EHR-launched apps with user and patient context, scope-based data access, and token-based authentication. The dominant model for modern EHR app integration.
What are the main FHIR Resources used in RCM?
Coverage, Claim, ClaimResponse, ExplanationOfBenefit, PriorAuthorization, Patient, Encounter, Organization, Practitioner. Da Vinci implementation guides (CRD, DTR, PAS) specify how these resources are used in specific payer-provider workflows.
Is FHIR free to use?
Yes. FHIR is published by HL7 under a non-restrictive license. Implementations are royalty-free. Toolkits (HAPI FHIR, FHIR reference implementations) are open source. Some profile guides and registry services have optional fees but the standard itself is free.
Disclaimer
This glossary entry is operational reference for revenue-cycle and medical-billing professionals. It is not legal, clinical, or contractual advice. Industry benchmarks cite named public sources where available; always verify against the current guidance from the authority body before relying on a number in a contract, policy, or compliance filing.