- FHIR (Fast Healthcare Interoperability Resources) is the HL7 standard for exchanging health records using modern web technology.
- It breaks health information into standard building blocks such as patients, encounters, observations and coverage, so different systems understand each other.
- Federal rules for certified EHRs and for payers now depend on FHIR, including the 2027 prior authorization APIs.
- For a practice, the value is practical: patient access, easier exchange, approved apps, and no data lock-in.
FHIR (pronounced "fire") is one of those terms every EHR vendor uses and few explain. You do not need to understand it technically to benefit from it, but you should know what it makes possible and what to ask your vendor.
FHIR in one paragraph
FHIR is a standard published by HL7, the organization behind most healthcare data standards. It describes health information as a set of standard building blocks, called resources, such as a patient, an encounter, a lab observation, a medication or an insurance coverage, and it defines how systems request and send those resources over the same kind of web interfaces (APIs) that power everyday apps.
Why it replaced older approaches
Before FHIR, exchange mostly relied on HL7 version 2 messages and C-CDA documents. Both still matter: lab results commonly travel as HL7 v2 messages, and C-CDA documents carry care summaries between providers. But each connection often needed custom interface work, and getting a single piece of information meant exchanging whole documents.
FHIR makes it possible to ask for exactly the information needed, in a format any compliant system understands, using widely known web technology. That is why regulators chose it as the foundation for patient access and payer APIs.
The building blocks a practice touches every day
You will rarely see these names in a practice, but every visit creates them. Knowing them makes vendor conversations much easier:
| FHIR resource | What it holds in plain words |
|---|---|
| Patient | Name, date of birth, contact details and identifiers |
| Encounter | A visit: when, where, with whom and why |
| Condition | A diagnosis or problem on the problem list |
| Observation | A lab result, vital sign or screening score |
| MedicationRequest | A prescription |
| AllergyIntolerance | An allergy and the reaction |
| Coverage | The patient's insurance plan and member details |
| DocumentReference | A document such as a scanned record or a care summary |
USCDI: the agreed minimum
FHIR describes how data is exchanged; the United States Core Data for Interoperability (USCDI) describes which data must be exchangeable at a minimum. It lists data classes such as allergies, medications, problems, lab results, vital signs, immunizations, procedures and clinical notes. Certified EHRs must be able to share USCDI data through their APIs, and new versions add data classes over time. When a vendor says it supports exchange, ask which USCDI version it supports.
SMART on FHIR in plain words
SMART on FHIR is the standard way for an approved app to connect to an EHR safely. The pattern is familiar from consumer apps that ask to “sign in with” another service:
- A user opens the app and is sent to the EHR to sign in.
- The EHR shows what the app is asking to see, such as medications or lab results.
- The user approves, and the app receives access to only that information, for a limited time.
- Every access is recorded, and access can be withdrawn.
For a practice, this means a new tool, such as a remote monitoring service or a specialty calculator, can connect without a custom interface project, and without handing the vendor a shared password.
Patient access in practice
When a patient asks to connect a health app to their records, the request usually goes through the patient portal: the patient signs in, approves the app and chooses what it may see. Practices should make sure the portal sign-up works smoothly, because patient access is only as good as the patient’s ability to get into the portal in the first place.
Where FHIR shows up in federal rules
- Certified EHRs must provide standardized FHIR APIs so patients can access their own records through an app of their choice.
- The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) requires impacted payers (Medicare Advantage, Medicaid and CHIP programs and plans, and QHP issuers on the federal exchanges) to implement FHIR APIs, with API requirements generally starting January 1, 2027, including a Prior Authorization API.
- Information-blocking rules discourage withholding electronic health information from patients and other providers when exchange is permitted.
What FHIR changes for your practice
For patients
- Records available in apps they choose
- Less paperwork when they change providers
For your practice
- Easier exchange with hospitals and labs
- Approved apps connect without custom projects
- Prior authorization moving to electronic payer APIs
- Your data leaves with you in a standard format
What to ask any EHR vendor about FHIR
Almost every EHR now says it “supports FHIR”. These questions show whether that support will help your practice:
- Can patients reach their records through an app of their choice, at no extra charge?
- Can we exchange records with our hospitals and HIE without a custom interface project?
- How will you use payer Prior Authorization APIs when they go live in 2027?
- Can approved third-party apps connect using SMART on FHIR, with access limited and recorded?
- If we leave, can we export every patient’s full record in a standard format, and is there an exit fee?
- Is interoperability included in the price, or sold as an add-on?
Where XEHR stands
XEHR exchanges records using FHIR and C-CDA, lets approved apps connect through SMART on FHIR with every access recorded, and exports your data in standard formats with no exit fee. Interoperability is included, not sold separately.
