What Is HL7 FHIR? A Practical Overview of the Standard

What You Need to Know

• Definition. HL7 FHIR is the modern healthcare data-sharing standard that uses web APIs and modular resources to move clinical data between systems.
• Key finding. Only 43% of U.S. hospitals routinely meet the four-part interoperability definition, despite widespread FHIR API certification.¹⁰
• Practical takeaway. FHIR depth determines whether an AI scribe writes structured data into the chart or just dumps text.

What HL7 FHIR Is and Why It Was Created

You have probably heard FHIR mentioned in vendor demos and ONC posts more in the past two years than in the previous ten. Here is the short version of what it is and why it matters now.

HL7, short for Health Level Seven International, is the nonprofit that writes the rules for how healthcare software shares data. It has been at this work since well before modern web APIs existed. The older HL7 standards (v2, v3, and CDA) still move messages and documents inside most U.S. health systems. None of them were built to push data into a phone, a payer's portal, or a third-party app in real time. FHIR is HL7's answer to that gap.

NLM puts it plainly. FHIR is the way to use common web tools to share healthcare data.¹ ONC says it is the standard behind a more connected health ecosystem.²

The shift was not optional for vendors. By December 2022, more than 95% of certified health IT developers had wired up the patient access APIs ONC required.³ A new CMS rule called CMS-0057-F now extends FHIR API requirements to most payers on a fixed timeline.⁴

The federal government keeps pushing. ASTP/ONC (the federal office that now houses ONC under the Assistant Secretary for Technology Policy) released a 2024 Federal FHIR Action Plan to coordinate FHIR work across agencies, payers, and providers.²²

The standard your vendor is certified against is one piece of the puzzle. How that standard is wired into your chart is where most of the practical questions live for an outpatient practice.

How FHIR Works: Resources, APIs, and the Modern Web Stack

FHIR works the way modern apps work. Your chart data gets broken into small modular pieces called "resources." Apps move those resources around using the same plumbing that powers consumer web and mobile software.

Think of resources as Lego blocks. A Patient resource holds demographics. An Observation resource holds a single lab result or a vital sign. A MedicationRequest holds an order. The eCQI Resource Center describes resources as a way for clinicians to share data no matter how each EHR stores it underneath.⁵

Each resource has its own ID and its own predictable structure. That is what makes them addressable from outside the EHR.

The API layer is what makes FHIR feel familiar to anyone who has built modern software. A FHIR-aware tool reads, writes, updates, or deletes resources using the same HTTP verbs every web app uses. It does this over secure connections.

Most production deployments use JSON for the data. A security layer called SMART on FHIR handles authentication and patient consent.

A standard built on REST and JSON taps into the same developer pool that builds banking apps, ride-share apps, and consumer health apps. Healthcare gets to ride that tooling and talent pool.

Profiles and extensions let countries and specialties tweak the base resources for local rules without breaking interoperability. The same Patient resource can carry different required fields in a U.S. ambulatory practice and a German hospital. Both still talk to any FHIR client.

Where FHIR Shows Up in Your EHR Today

For most outpatient practices, FHIR is invisible day to day. The chart still looks the same. Orders still look the same.

What changes is how data moves between the EHR and any tool that connects to it.

Each FHIR-enabled action in a typical visit corresponds to one or more resources:

Pulling up a patient's record uses Patient and Encounter.

• Updating the problem list writes to Condition.
• Putting in a medication order writes to MedicationRequest.
• Lab results come back as Observation entries.
• The visit note itself is captured as a DocumentReference linked to that day's Encounter.

These resources are not abstract. They map to the same fields a clinician edits during a visit. FHIR just restructures them so any FHIR-aware app can read or write them through a standard call.

By 2024, 81% of U.S. hospitals enabled patient access via apps configured to API specs. 70% met FHIR specs specifically.⁶ Outpatient FHIR-based API use grew from 62% in 2021 to 74% in 2022, then held steady through 2024.⁶

Lower-resourced and independent hospitals have lagged on these patient-facing capabilities. The same pattern shows up in outpatient practices.

Knowing which resources sit behind which chart actions is what makes vendor demos useful and is the foundation of any EHR integrations conversation. An AI scribe that only writes to DocumentReference is doing far less than one that also writes Condition, MedicationRequest, and Observation.

FHIR and AI Documentation: Why Integration Depth Matters

Here is the question that matters. When an AI scribe finishes a visit, does it just hand you a written note, or does it also fill in the structured chart fields you would otherwise type yourself?

That is the difference between a scribe that cuts your typing and a scribe that cuts your post-visit work. Updating the problem list, entering medication orders, and recording observations by hand still costs minutes per visit. Across a full day, that adds up.

FHIR is what makes the second kind of scribe possible. A scribe with deep FHIR integration can write directly into Condition, MedicationRequest, and Observation: the structured fields shown in the last section. A scribe without that depth gives you a paragraph of text and leaves the chart updates to you.

Research backs this up. A randomized trial found FHIR-connected apps get used much more often when the EHR shows them to the clinician at the right moment in the workflow.⁷ Other studies have shown FHIR apps can pull chart data together automatically, like calculating a stroke risk score without making the clinician hunt through tabs.⁸ Medication reconciliation is next on the list, though vendors are still building those workflows out.⁹ FHIR apps have also worked at scale across multiple sites and EHRs.²³

If you are evaluating an AI scribe, the one question that matters is whether it writes back to the structured chart fields or just gives you the note. FHIR depth is what tells you which one you are getting.

What FHIR Has Delivered, and Where It Still Falls Short

FHIR has shipped a lot of infrastructure without yet shifting day-to-day practice as much as the headlines suggest. ONC measures hospital interoperability as four things: sending, receiving, finding, and integrating outside data. ONC's 2023 hospital data showed 70% of U.S. hospitals reported meeting all four. Only 43% were actually using all four routinely.¹⁰

That gap is the data point to remember when a vendor pitches you on FHIR.

The same data showed no real change between 2022 and 2023.¹⁰ Information blocking rules and continued certification did not move the daily picture year over year.

Certified does not mean used. ONC has said as much in its own materials.³

Hospitals are further along than the regional data-sharing networks that move clinical data between them. Only about 1 in 5 of those networks routinely send or receive data via FHIR.¹³

The financial backdrop makes this matter. A Health Affairs brief estimated wasteful administrative spending at $285 to $570 billion as of 2019, or 7.5 to 15% of national health spending.¹⁴ The figure is a pre-pandemic baseline and likely understates today's level. Even small chunks of that pile are worth automating.

For patients, FHIR-built tools have a clear engagement payoff. A 2024 systematic review found a positive relationship between patient EHR access and engagement across treatment adherence, self-management, communication, and satisfaction.¹⁵

Three things to take away from the gap:

• FHIR availability is not the same as FHIR use. Confirm a vendor's certification claim at the workflow level, not the marketing level.
• The patient-facing side of FHIR has moved faster than the provider-facing side.
• The FHIR value for your practice depends less on the standard than on which tools you actually deploy.

The standard is published and the certified infrastructure is in place. What is still uneven is the part that turns FHIR APIs into chart workflows real clinicians and patients use every day.

What Adoption Looks Like for Independent and Group Practices

How FHIR shows up depends on practice size. The standard is the same, but the questions look different at each end.

If you are an independent or small practice, you probably do not have an in-house IT person who can dig into a vendor's technical specs or audit how a third-party app behaves. Tool selection comes down to clinician word of mouth, EHR-recommended apps, and how easy the pricing page is to read.

If you are a group practice, you have a different problem. Multi-site rollouts mean change management, consistent setup across locations, and a clear answer on which chart fields the vendor will write into at each site.

The patient-side payoff also reaches practices unevenly. Independent and lower-resourced hospitals trail on FHIR-enabled patient apps, even as overall outpatient access has climbed.⁶

Two patterns follow:

• For independent and small practices: pick the tool that fits your EHR cleanly. Workflow simplicity and EHR fit usually beat feature breadth.
• For group practices: this is a procurement decision. Include data flow review, vendor agreements, audit logs, and what the vendor writes back to the chart.

Neither is better. The right approach matches the practice's IT capacity and the workflows already in place.

The cost a FHIR-aware tool can chip away at is real. A 2016 Health Affairs analysis found U.S. physician practices spent more than $15.4 billion a year on quality measure reporting alone, averaging 785 hours per physician.¹⁶ That figure is a conservative pre-pandemic baseline and the burden has not shrunk since.

The Commonwealth Fund's 2025 brief on primary care admin burden lists prior auth, EHR work, inbox management, and forms as the biggest sources of practice load. The brief points at interoperability and FHIR as part of the way out.¹⁷

MGMA's 2025 prior auth report found that 92% of group practices have hired or reassigned staff just to handle PA volume.¹⁸ That is a lot of staff time tied up in a workflow FHIR is finally starting to touch.

The Regulatory Backbone: Information Blocking, CMS-0057-F, and Patient Access APIs

The rules around FHIR are clear enough now that practices can plan around them. Two pieces matter most. The first is information blocking enforcement. The second is a CMS deadline for payers called CMS-0057-F.

Information blocking enforcement got teeth in 2025 and 2026. Under the Cures Act, the HHS Office of Inspector General can assess civil monetary penalties of up to $1 million per violation against four categories of covered actors: developers of certified health IT, entities offering certified health IT, health information exchanges, and health information networks.¹¹ ONC can also ban a developer from the Health IT Certification Program and terminate the certification of any product involved in information blocking.¹¹ Provider organizations face a separate track called "disincentives," which can mean reduced Medicare payments through programs like the Promoting Interoperability Program, MIPS, and the Medicare Shared Savings Program.¹¹⁻¹²

CMS-0057-F is the near-term driver for FHIR adoption among payers. The rule applies to Medicare Advantage, Medicaid, CHIP, and the major qualified health plans on the federal exchanges. Operational provisions started January 1, 2026, and the bigger API work is due January 1, 2027.⁴

CMS has also proposed a follow-on rule (CMS-0062-P) to extend electronic prior auth to drug transactions, using a mix of NCPDP pharmacy standards and additional FHIR specifications. The target compliance date is October 1, 2027.¹⁹

The prior auth load FHIR is meant to cut is huge. AMA's 2024 prior auth survey of 1,000 physicians found practices complete 39 prior auth requests per physician per week, eating up 13 hours of physician and staff time.²⁰ Only 28% of prior auth transactions were fully electronic in 2022.²¹

Three things this means for an outpatient practice:

• Your EHR vendor's FHIR API is an audit item now, not a nice-to-have. A vendor that limits access could be on the hook.
• Prior auth workflows will shift unevenly as payers come online. Practices working with multiple payers will see the change one payer at a time.
• The list of third-party apps you let into your chart now belongs in the same governance binder as your HIPAA business associate agreements. For a deeper take on the security side, see our guide to HIPAA-compliant AI note taking.

FHIR by itself does not enforce anything. The rules around it do.

Questions to Ask Your EHR and AI Vendors About FHIR

The questions you ask about FHIR matter more than the marketing language a vendor uses. Most vendors say they "support FHIR" or "integrate with Epic." Both can mean a lot of different things.

Use these in vendor evaluations. They line up with the resources and rules already covered.

Which version of FHIR they support

• Which version of FHIR does your product support? DSTU2, STU3, R4, or R5?
• If R4 is the production target, do you also handle R5 features our EHR may turn on next?

What they actually do with chart data

• Which FHIR resources does your tool read from our EHR?
• Which ones does it write back to the chart? Specifically, do you write Condition, MedicationRequest, and Observation in addition to DocumentReference?
• What triggers a write? Clinician approval, automated post, or another step?

How they get in and what gets logged

• Which SMART on FHIR scopes does your tool ask for?
• How are those scopes logged inside our EHR?
• What does the audit trail show for write actions performed on the chart?

How they line up with the rules

• Are your FHIR APIs lined up with ONC certification requirements for our EHR vendor?
• For payer-facing functions, does your roadmap include the CMS-0057-F prior authorization API work?

What it's like in production

• What is the typical latency on a write back to our EHR?
• What happens when a write fails or our EHR rejects one?

A vendor that answers these concretely has thought through integration depth. A vendor that drops back into marketing language usually has not. For a side-by-side starting point, see our list of the best AI medical scribes in 2026.

Commure Scribe and FHIR-Aware EHR Integration

Commure Scribe is an AI medical scribe built around EHR integration. For independent and small practices, the integration is copy/paste; for medium and large group practices, it is one-click sync with the EHR. The clinician reviews, edits, and finalizes before anything posts to the chart.

The structured fields a FHIR-aware tool needs to write (Condition, MedicationRequest, and Observation) are the same fields Commure Scribe surfaces for clinician review. Suggested ICD-10 and CPT codes appear in a separate tab, which keeps the coding workflow distinct from the note.

This article is for informational and educational purposes only, does not constitute legal, medical, or professional advice, and does not guarantee compliance with any specific regulation.

‍