What Is the FHIR Standard?

A Practical Guide to HL7 FHIR for Healthcare Data Integration

Healthcare has never had a shortage of data. What it has lacked is a common language for moving that data between the systems that need it. A hospital's electronic health record data, a health plan's claims platform, a lab system, and a patient's smartphone health app all hold pieces of the same story, yet they rarely speak to each other cleanly.

The HL7 FHIR standard was built to fix that. Developed by HL7 International, it gives healthcare organizations a modern, web-friendly way to exchange clinical and administrative information through APIs, and it has quickly become the backbone of US healthcare interoperability policy.

That shift now carries a hard date. Under the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F), Medicare Advantage, Medicaid, CHIP, and federally facilitated Marketplace payers must have four standards-based APIs in production by January 1, 2027. For those payers, it is no longer a roadmap item. It is a compliance requirement with real financial consequences.

In this guide, we cover what FHIR is, the structure of FHIR and how it works, how it differs from earlier HL7 standards, who uses it, and why the hardest part of adopting it is usually the legacy data underneath the API rather than the API itself.

What Is FHIR?

FHIR is an interoperability standard for exchanging health care information electronically. It defines a common data model made of small building blocks, called resources, and a standard way to read, write, and search them through web APIs. In plain terms, it is how one healthcare system asks another for a patient record, a claim, or a prior authorization decision, and gets back something both sides understand.

It borrows heavily from how the rest of the internet already works: REST, JSON, XML, and OAuth, the same technologies behind most consumer and enterprise web APIs. That choice lowered the barrier to entry. A developer who has never worked in health informatics can usually read a resource and make basic FHIR API calls within an afternoon.

What FHIR Stands For and Who Maintains It

FHIR stands for Fast Healthcare Interoperability Resources® and is pronounced "fire." (You will sometimes see it misquoted as Fast Health Interoperability Resources.) It is published and maintained by Health Level Seven International, usually shortened to HL7 and sometimes written as Health Level 7. HL7 International is the nonprofit standards body behind the v2, v3, and CDA standards that hospitals and health plans have used for decades.

HL7 develops the standard in the open. The specification is free to read and use, changes go through a public balloting process, and the FHIR community tests new features at regular Connectathons. Alongside HL7, groups such as the Da Vinci Project, CARIN Alliance, and Argonaut Project publish implementation guides for specific use cases like payer data exchange and consumer access.

A Brief History: From HL7 v2 and v3 to FHIR

To understand why it exists, it helps to look at the previous standards that came before it.

• Version 2 (late 1980s onward). The HL7 v2 standard is a pipe-delimited messaging format that still carries most hospital system traffic today: admissions, discharges, transfers, lab orders, and results. It is flexible and widely adopted, but every implementation is a little different, so each interface needs custom work.
• HL7 v3 and CDA (2000s). Version 3 tried to fix v2's inconsistency with a rigorous, model-driven XML approach. It proved complex and saw limited adoption, though one piece, the Clinical Document Architecture (CDA and its C-CDA templates), became common for clinical summaries.
• FHIR (2011 onward). HL7 began the new standard as a fresh start that kept the clinical knowledge from v2 and v3 but delivered it through modern web APIs. The first draft appeared in 2014, and it has since become the default HL7 standard for new interfaces.

The result is that most organizations now live in a mixed world: v2 feeds and C-CDA documents on the inside, modern APIs on the outside, and a lot of transformation work in between. If you are still running point-to-point HL7 interfaces, our guide to clinical data integration covers how teams are consolidating them.

How FHIR Works

FHIR provides a consistent way to break health data into small, reusable resources, expose them through REST APIs, and tighten the rules for specific use cases through profiles and implementation guides. Four ideas cover most of what you need to know.

Resources: The Building Blocks of Healthcare Data

A FHIR resource is a defined unit of healthcare information with a known structure. Each one represents a single concept, such as a person, a clinical observation, a claim, or a coverage record. The base FHIR specification defines roughly 150 resources for healthcare, grouped into categories like clinical, administrative, financial, and workflow.

Some of the resources you will see most often:

• Patient and Practitioner for the people involved in care
• Encounter, Condition, and Observation for clinical events, diagnoses, and results
• MedicationRequest and Procedure for orders and treatments
• Coverage, Claim, and ExplanationOfBenefit for payer and financial data
• Questionnaire and QuestionnaireResponse for forms such as prior authorization documentation

Resources link to each other through references. An Observation points to the Patient it describes, and a Claim points to the Coverage it bills against. Linked together, these resources for health and financial records can represent anything from a single lab result to a member's full claims history. Because every base FHIR resource shares the same data structures (identifiers, metadata, narrative, and extensions), tools can process them consistently.

RESTful APIs, JSON, and XML

Resources are exchanged through a RESTful API. Each resource type has its own endpoint on a FHIR server, and clients use standard HTTP verbs to work with it: GET to read or search, POST to create, PUT to update, and DELETE to remove. A request like GET /Patient/123 returns that patient, and GET /Observation?patient=123&code=glucose returns matching lab results.

Resources can be represented in JSON, XML, or RDF. JSON is by far the most common choice for new APIs because it is lightweight and native to web and mobile development. Here is a trimmed Patient resource in JSON:

{
"resourceType": "Patient",
"id": "123",
"name": [{ "family": "Rivera", "given": ["Ana"] }],
"gender": "female",
"birthDate": "1984-06-02"
}

REST is not the only exchange pattern. The standard also supports messaging, documents, and Bulk FHIR, which exports large populations as NDJSON files. Bulk export matters for payers, because the CMS Provider Access API requires sharing data for whole patient panels rather than one record at a time. For analytics, the emerging SQL on FHIR specification defines standard views that flatten resources into tables. For a deeper look at the API layer itself, see our explainer on what a FHIR API is and how it works.

Profiles, Extensions, and Implementation Guides

The base specification is deliberately broad so it can work in any country and care setting. Real projects narrow it down using three tools:

• Profiles. A FHIR profile constrains a resource for a specific use, such as making certain fields required or binding a field to a specific code system. Shared code systems and value sets are what deliver semantic interoperability: both sides agree not just on the format but on what each code means.
• Extensions add data elements the base resource does not include, in a standard way that other systems can recognize.
• Implementation guides (IGs) package profiles, extensions, terminology, and API rules for a whole use case.

In the US, the most important IGs include US Core, which underpins ONC certification, the CARIN Blue Button IG for consumer claims access, and the HL7 Da Vinci guides that CMS points payers to: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), and Prior Authorization Support (PAS). In practice, to implement FHIR is to support the right implementation guides, not just generic resources.

FHIR Versions: DSTU2, STU3, R4, R5, and R6

The standard has gone through several major releases, and the HL7 version you use affects which resources and fields are available.

For most US organizations the practical answer is simple: build on FHIR Release 4 (R4). ONC certification and the CMS payer API rules are written around R4 and its IGs, and R4's normative core is designed to stay backward compatible. R5 and the upcoming R6 matter for planning, but R4 is what payers must serve by 2027.

FHIR vs. HL7: What's the Difference?

"FHIR vs. HL7" is a common search, but it is a slightly misleading comparison. HL7 is the organization, and this is one of its standards. When people say "HL7," they usually mean v2 messaging, so the real comparison is v2 (and CDA) versus HL7 FHIR.

The biggest practical difference is access. A v2 interface pushes a message when an event happens, and the receiver has to store and interpret it. The newer standard lets an authorized system ask for exactly the data it needs, when it needs it, through a documented API. The same push-versus-pull shift is happening in B2B exchange, as we cover in EDI vs. API integration.

Is FHIR Replacing HL7 v2?

Not anytime soon. Version 2 messaging is embedded in nearly every hospital, lab, and EHR interface in the country, and it works well for high-volume internal event feeds. Ripping it out would be expensive and offer little benefit.

What is happening instead is coexistence. FHIR has become the standard for new, outward-facing exchange: patient apps, payer APIs, provider-to-payer workflows, and regulatory reporting. v2 and C-CDA keep running underneath. Many "FHIR-enabled" systems are really an API layer in front of v2 feeds, EDI files, and relational databases.

That coexistence is why transformation matters so much. Every API that sits in front of a legacy system needs a reliable way to convert v2 messages, CDA documents, and X12 EDI into valid resources, and often to convert them back again.

Why FHIR Matters

It matters because it turns health interoperability from a series of custom projects into a shared, testable standard, and because US regulators now require it. For payers in particular, the question is no longer whether to adopt it but how quickly the data underneath it can be made ready.

Interoperability Between EHRs, Payers, and Partners

Before APIs, connecting two organizations usually meant a custom interface, a negotiated file layout, and months of testing. Every new partner started the process over.

A shared standard changes the economics. Once a payer exposes a conformant API, any EHR, app, or partner that supports the same IG can connect with far less custom work. Providers can check coverage and prior authorization requirements from inside the EHR. A new health plan can request a member's history from the prior plan. A patient can pull claims into an app of their choosing. Each of these is an exchange built on shared resources rather than a one-off integration.

Regulatory Drivers: ONC, CMS, and the 21st Century Cures Act

Three waves of federal policy have made it the default for US health data exchange:

• 21st Century Cures Act (2016). Congress called for standardized APIs that give patients access to their data "without special effort" and prohibited information blocking.
• ONC Cures Act Final Rule (2020). The Office of the National Coordinator for Health Information Technology (ONC) required certified EHR technology to support a standardized R4 API using US Core, SMART on FHIR, and bulk export, making the standard a baseline EHR capability.
• CMS interoperability rules (2020 and 2024). CMS first required impacted payers to offer FHIR APIs for patient access starting in 2021. The Interoperability and Prior Authorization Final Rule (CMS-0057-F), finalized in January 2024, goes much further.

Under CMS-0057-F, Medicare Advantage organizations, Medicaid and CHIP programs and managed care plans, and Qualified Health Plan issuers on the federally facilitated Exchanges must have four R4 APIs in production by January 1, 2027:

1. 1.Prior Authorization API, which lets a provider's EHR discover whether prior authorization is required, gather documentation, and submit the request electronically, using the Da Vinci CRD, DTR, and PAS guides.
2. 2.Provider Access API, which lets in-network providers pull a patient's claims, encounter, and clinical data, including in bulk.
3. 3.Payer-to-Payer API, which moves a member's history, including prior authorizations, to a new plan when they switch.
4. 4.Patient Access API (expanded), which now adds prior authorization status so members can track decisions in third-party apps.

The rule also sets prior authorization decision windows for most impacted payers, effective January 1, 2026: 72 hours for expedited requests and 7 calendar days for standard ones. CMS estimates the policies will save roughly $15 billion over 10 years.

For payers, the cost of missing the API deadline goes well beyond a compliance finding:

There is a market cost too. Providers will favor plans that offer fast, electronic prior authorization over plans still running on fax and phone. Members increasingly expect digital access to their data. Payers that lag will feel it in provider network satisfaction and member retention. For a payer-specific breakdown, read FHIR readiness for payers: why the data layer decides the deadline.

Security and HIPAA Compliance

The standard itself is a data format and API specification, so it does not make a system HIPAA compliant on its own. What it does provide is a well-defined security model that compliant implementations build on.

FHIR and SMART work together: the SMART framework layers OAuth 2.0 and OpenID Connect on top of the API to control who can access which patient data and under what scopes. Data travels over TLS, and the specification includes resources such as Consent, AuditEvent, and Provenance to record permissions, access, and data lineage. HIPAA compliance still depends on the organization: its access controls, encryption, audit logging, business associate agreements, and where protected health information is stored and processed. Our post on data integration control and compliance goes deeper on the governance side.

Who Uses FHIR? Common FHIR Use Cases

The use of FHIR now touches almost every part of the healthcare ecosystem, and the adoption of FHIR is accelerating. The use cases differ by organization, but they share one pattern: a system that needs data asks for it through a standard API instead of waiting for a custom file or fax.

Providers and EHR Systems

Every certified EHR in the US must support a standardized API, so providers are the most mature adopters. Hospitals and clinics plug SMART apps directly into the EHR, from clinical decision support to scheduling tools. They share data with health information exchanges and other providers, and give patients access to their health record through portals and consumer apps.

Inside the EHR, prior authorization is the use case providers care about most. With Da Vinci CRD and DTR, a clinician placing an order can see right away whether the payer requires prior authorization, and the EHR can pre-fill the required documentation from data it already holds.

Payers, Claims, and Prior Authorization

Payers are now the fastest-growing group behind FHIR adoption, largely because of CMS-0057-F. For a health plan, common uses include:

• Prior authorization. Receiving requests from provider EHRs through the Da Vinci PAS guide, then translating them to the X12 278 transaction that many utilization management systems still run on.
• Claims and encounter data. Exposing claims as ExplanationOfBenefit resources for the Patient Access and Provider Access APIs. See how AI is automating claims workflows upstream of these APIs.
• Member transitions. Matching members across plans using the $member-match operation and exchanging history through the Payer-to-Payer API.
• Quality and risk programs. Pulling clinical data from providers to support HEDIS reporting, risk adjustment, and care management.

Data Exchange with Partners and Third-Party Apps

The standard also opens the door to a wider ecosystem. Consumer apps give members a single view of claims, coverage, and clinical records. Labs, pharmacies, and care management vendors exchange data with plans and providers through standard APIs. Public health agencies use FHIR for electronic case reporting, and TEFCA, the national framework that connects health networks, is adding FHIR-based exchange so that any health system on the network can query another.

For every one of these partners, a standard API replaces a negotiated file format. That shortens onboarding and makes exchange easier to govern, as long as the data feeding the API is clean.

Challenges of Implementing FHIR

Standing up an endpoint is the easy part. Payers and providers are finding that the real difficulty sits in the data layer underneath the API: legacy formats, inconsistent source data, and keeping everything valid as standards evolve.

Mapping Legacy Formats (HL7 v2, CDA, EDI)

Most legacy data was never designed for this model. Core claims, eligibility, and utilization management systems still run on X12 EDI transactions, clinical systems emit v2 messages and C-CDA documents, and plenty of critical data lives in spreadsheets and PDFs. Before an API can serve that data, someone has to translate it.

The common mapping challenges include:

• X12 to FHIR. Translating the 278 for prior authorization, the 837 for claims, the 834 for enrollment, and the 270/271 for eligibility into resources, and in the case of Da Vinci PAS, mapping back to the X12 278 so existing UM systems can process it. CMS allows payers to meet the Prior Authorization API requirement with this kind of translation layer in front of existing systems. Our guide to EDI transactions explains each of these sets.
• v2 and CDA to FHIR. Converting ADT messages and C-CDA documents, with their nested segments and local variations, into well-formed resources.
• Unstructured policy content. Da Vinci DTR expects medical necessity criteria to be machine-readable, built on the FHIR Questionnaire resource and CQL logic, but most of that criteria lives in PDF medical policies or tools like InterQual and MCG. Intelligent document processing in healthcare is how teams are closing that gap.
• Identity. Without a universal patient identifier, matching members across plans for the Payer-to-Payer API requires deterministic and probabilistic matching logic.

This is where many projects stall. When every team maps data by hand, on its own timeline and without shared version control, work that should take days stretches into weeks. One large health plan Adeptia worked with faced exactly this problem across HL7 ADT, CCDA XML, and Excel-based chronic conditions data. Moving that mapping onto a single governed platform delivered three production FHIR maps and cut mapping generation for its HL7 and HEDIS specs from hours to minutes.

Version Management and Data Validation

The specification is a living standard. Organizations may need to support R4 for regulatory APIs, consume STU3 or DSTU2 from older partner systems, and plan for R5 and R6. IGs also release new versions, and CMS and ONC update which versions they recognize. Each change can ripple through mappings and profiles.

Validation is the other half of the problem. A resource can be syntactically valid JSON and still fail the profile a FHIR implementation guide requires: a missing required field, a code from the wrong value set, or a broken reference. Teams need to validate every resource against the right version, profile, and terminology before it reaches a partner, and route failures to someone who can fix them. Without that discipline, errors surface in production, in front of providers and regulators. Our AI data mapping best practices cover how to build validation into the mapping workflow.

How an Integration Platform Simplifies FHIR Data Exchange

Most payers do not need to replace their core systems to meet the CMS requirements. They need a dependable layer that connects to those systems, translates their data into valid resources, validates it, and delivers it to the APIs, on a deadline that does not move.

That is the role of an integration platform built for complex healthcare data. Adeptia Automate is an Intelligent ETL platform that connects to claims, enrollment, clinical, and legacy systems, translates X12 EDI, v2, C-CDA, spreadsheets, and documents into FHIR, validates the output against business rules, and orchestrates delivery to the Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs. Adeptia has processed insurance and healthcare EDI for more than 25 years, and a top-five US health services payer has already selected Adeptia for its FHIR transition.

AI-Powered Data Mapping to FHIR Resources

Mapping is where timelines are won or lost. Adeptia's AI data mapping proposes field-level mappings from source formats such as the X12 278, 837, and 834 or v2 ADT into the target resources and profiles. Analysts review and approve each suggestion instead of writing every map by hand. Existing Excel mapping specs can be ingested to generate a complete base mapping in minutes. (For the payer side of this, see health insurance data mapping.)

AI does the work at design time. At runtime, every integration executes as deterministic, auditable logic, which is what compliance teams and auditors expect from a regulated data flow. Around that core:

• AI Business Rules let compliance and operations teams define validation and routing rules in plain English, with versioning and approvals.
• Intelligent document processing turns PDF medical policies and other unstructured content into structured data teams can use to author Da Vinci DTR Questionnaires and rules.
• Bidirectional translation maps Da Vinci PAS resources to and from X12 278 and 275 transactions, so existing UM systems keep running.
• Data staging pipelines replicate legacy data into an indexed store to serve Bulk FHIR requests without loading production systems.
• Exception routing sends records that fail validation to the right reviewer with full context, while clean data keeps flowing.

On-Premises and Cloud Deployment for Regulated Industries

Where FHIR data is processed matters as much as how. PHI is subject to HIPAA, state privacy laws, customer contracts, and internal data residency policies. Some payers need processing to stay inside their own data centers. Others are moving to cloud stores such as AWS HealthLake, Google Cloud Healthcare API, or Azure Health Data Services.

Adeptia Automate deploys on-premises, in the cloud, as a hosted service, or in a hybrid model. That lets a payer process sensitive data close to its source while delivering resources wherever its APIs run, and change targets through configuration rather than re-engineering. Role-based access, approval workflows, and a complete audit trail for every run support the governance that HIPAA-regulated exchange demands.

Getting Started with FHIR

FHIR has become the common language of US healthcare data exchange. It gives EHRs, payers, partners, and patients a modern, API-first way to share data, and federal regulation now makes it mandatory for a large share of the market. For impacted payers, January 1, 2027 is a fixed date.

The practical path forward starts with the data, not the endpoint:

1. 1.Inventory your sources. Identify every X12, v2, C-CDA, database, and document source that feeds the four required APIs.
2. 2.Target R4 and the right IGs. Align on US Core, CARIN Blue Button, and the Da Vinci CRD, DTR, and PAS guides.
3. 3.Build a translation layer, not a rebuild. Map legacy formats to resources in front of existing systems, as CMS allows.
4. 4.Validate and govern every resource. Check output against profiles and business rules, and keep a complete audit trail.
5. 5.Plan for change. Choose tooling that can absorb new versions, IG updates, and partner formats without starting over.

The deadline doesn't move. Your data should. Adeptia helps payers turn the legacy EDI and clinical data underneath their APIs into clean, compliant resources without replacing core systems.

FHIR Standard FAQs

What is the difference between HL7 and FHIR?

What is the current version of FHIR?

Is HL7 FHIR an API?

Is FHIR free?

Is FHIR HIPAA compliant?