What Is FHIR?
FHIR (Fast Healthcare Interoperability Resources) is an HL7 standard for exchanging healthcare information using modern web technologies (RESTful APIs, JSON/XML, OAuth 2.0), used for clinical data exchange, patient access APIs, and increasingly for prior-authorization and quality reporting.
- Certification means the capability exists, not that it is available to you.
- A certified EHR's FHIR API still has to be enabled by the vendor, your application registered, credentials and scopes issued, and — where the data is reached through a patient-facing app — authorized by the patient.
- Payer APIs split along the same line.
- The Patient Access API is authorized by the patient for an app the patient chooses, so a billing team cannot treat it as a coverage lookup.
FHIR
Also known as: Fast Healthcare Interoperability Resources; HL7 FHIR
FHIR (Fast Healthcare Interoperability Resources) is an HL7 standard for exchanging healthcare information using modern web technologies (RESTful APIs, JSON/XML, OAuth 2.0), used for clinical data exchange, patient access APIs, and increasingly for prior-authorization and quality reporting.
Definition
FHIR is developed by HL7, and its version history matters more than the marketing name. HL7's own publication history, read on 17 September 2026, lists FHIR R4 — version 4.0.1, published 30 October 2019 — as the first release carrying normative content, FHIR R5 (5.0.0, published 26 March 2023) as the current release, and R6 as a work in progress. US regulation is deliberately behind that curve: 45 CFR 170.215 adopts FHIR Release 4.0.1 as the API base standard, alongside the US Core Implementation Guide STU 6.1.0, the SMART App Launch Implementation Guide 2.0.0, FHIR Bulk Data Access (Flat FHIR) v1.0.0, and the Da Vinci Coverage Requirements Discovery, Documentation Templates and Rules, and Prior Authorization Support guides at version 2.0.1. FHIR exchanges 'resources' (Patient, Encounter, Observation, MedicationRequest, Claim, Coverage and others) over REST APIs on HTTPS, secured with OAuth 2.0 / SMART on FHIR. On the payer side, the 2024 CMS Interoperability and Prior Authorization final rule (CMS-0057-F, published 17 January 2024) requires Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization FHIR APIs — but only of what the rule calls impacted payers: Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the Federally Facilitated Exchanges. Commercial and employer-sponsored plans are not on that list.
Example
A patient's phone health app uses SMART on FHIR with OAuth 2.0 to authenticate to their provider's FHIR API and pull Patient, Observation (vital signs, labs), MedicationStatement, and Condition resources. The flow starts with the patient authorizing that specific app: certification is why the endpoint exists, but nothing moves until the patient grants access, and the app then sees only the scopes granted. A payer Patient Access API works the same way — the patient authorizes an app, and that app reads the patient's own Coverage and ExplanationOfBenefit data.
Common Misconceptions
FHIR is not replacing X12 for claims billing. The 837 remains the claim transaction and the 835 the remittance, and no federal rule substitutes FHIR for either. What has changed is prior authorization specifically: CMS-0057-F requires impacted payers to implement a FHIR Prior Authorization API by 1 January 2027, and CMS's National Standards Group announced on 28 February 2024 that it will not take HIPAA Administrative Simplification enforcement action against covered entities that implement such an API without using the X12 278 standard. That is flexibility for one transaction, not a general replacement of X12 by FHIR.
Practical Application
Certification means the capability exists, not that it is available to you. A certified EHR's FHIR API still has to be enabled by the vendor, your application registered, credentials and scopes issued, and — where the data is reached through a patient-facing app — authorized by the patient. Payer APIs split along the same line. The Patient Access API is authorized by the patient for an app the patient chooses, so a billing team cannot treat it as a coverage lookup. The provider-facing route is the Provider Access API, which CMS-0057-F requires impacted payers to implement by 1 January 2027, limited to in-network providers who have a treatment relationship with that patient and subject to the patient's right to opt out. Plan against those dates, those payer categories, and that scope rather than against an assumption that an API is usable because a rule exists.
Related Terms
EHR (Electronic Health Record)
An Electronic Health Record is a digital, longitudinal record of a patient's health information maintained by a healthcare organization, designed to be shared across providers and care settings, and to support clinical decisions, billing, and quality reporting.
Read definition21st Century Cures Act
The 21st Century Cures Act is a 2016 federal law whose information blocking provisions, implemented at 45 CFR part 171, prohibit health care providers, health IT developers of certified health IT, and health information networks and exchanges from interfering with the access, exchange or use of electronic health information.
Read definitionInformation Blocking Rule
The Information Blocking Rule, codified at 45 CFR Part 171 under the 21st Century Cures Act, prohibits health care providers, health IT developers, and health information networks from engaging in practices likely to interfere with access, exchange, or use of electronic health information (EHI), subject to ten regulatory exceptions.
Read definitionWhere This Applies on MedPrecision
Need help with billing?
If this term is showing up in your denials, EOBs, or A/R aging, we can help. Get a free billing audit and we will trace the issue to its root cause.
- No contract
- No setup fees
- Reply within 1 business day