FHIR Explained: HL7 FHIR, the FHIR API, and SMART on FHIR

Here’s a request that sounds simple and used to be miserable: give me this patient’s last four hemoglobin A1c results.

With a traditional HL7 v2 interface, you don’t ask for that. You can’t. You subscribe to a feed, receive every lab result the sending system produces, store them all, and then query your own copy. Getting one patient’s last four A1c values means building a pipeline, negotiating an interface, and waiting six weeks for someone’s integration queue to clear.

With FHIR, it’s one line:

GET [base]/Observation?patient=449812734&code=http://loinc.org|4548-4&_sort=-date&_count=4

That difference is the entire story of why FHIR took over healthcare interoperability. Not because it’s more elegant, though it is. Because it turned health data from a stream you had to catch into a database you could query.

This guide covers what FHIR is, what HL7 is and how the two relate, how the FHIR API actually works, what SMART on FHIR does, which implementation guides matter, and where the FHIR standard still disappoints.

What is FHIR?

FHIR is a healthcare data standard that defines a set of modular data objects called resources and a REST API for reading and writing them over HTTPS using JSON or XML.

It’s published by HL7 International, and its full name is HL7 FHIR. In practice most people just say FHIR.

What Does FHIR Stand For?

FHIR stands for Fast Healthcare Interoperability Resources. It’s pronounced “fire,” and the fire imagery in FHIR community branding is entirely deliberate.

The name is also a little bit of marketing. “Fast” refers to fast to implement rather than fast at runtime. That claim mostly holds up: a developer who has built anything against a modern web API can read the FHIR spec and make a working call the same afternoon. Nobody has ever said that about HL7 v3.

FHIR was created by Graham Grieve, an Australian standards developer who had spent years inside HL7 and concluded the organization’s existing approach was failing implementers. He floated the concept around 2011, and HL7 published the first draft standard for trial use in 2014.

What is FHIR in Healthcare, Concretely?

Strip away the abstraction and FHIR does three things:

• It defines the shape of health data. A Patient has a name, birth date, and identifiers. An Observation has a code, a value, a subject, and a time. Every FHIR server agrees on these shapes.
• It defines how to move that data. A RESTful API with predictable URLs, standard HTTP verbs, and a search syntax.
• It defines how to secure it. Not in the core spec, but through the closely coupled SMART on FHIR authorization framework built on OAuth 2.0.

That third piece is underrated. Older HL7 standards said nothing about authentication, which is why every v2 interface is a private tunnel between two trusted machines rather than an API anyone can build against.

What is HL7?

You cannot understand FHIR without understanding the organization that made it and the standards that came before.

HL7 stands for Health Level Seven. Health Level Seven International is a nonprofit, ANSI-accredited standards development organization founded in 1987. It publishes most of the messaging and document standards that hold American healthcare IT together.

The “Level Seven” is a reference to the seventh layer of the OSI networking model, the application layer. The founders were signaling that they were standardizing the content of clinical messages, not how those messages travel across a wire.

So when someone asks what HL7 is in healthcare, there are two valid answers, and conflating them causes endless confusion:

• HL7 the organization, which publishes standards including FHIR
• HL7 the standard, which in casual usage almost always means HL7 version 2

If a hospital integration analyst says “we’ll send you an HL7 feed,” they mean v2. If a vendor says “we’re HL7 compliant,” ask which standard, because the word alone tells you nothing.

What Are HL7 Standards? The Family Explained

Four HL7 standards matter in practice:

• HL7 v2 (first released 1989, still at v2.x today) is the pipe-delimited messaging standard that carries the overwhelming majority of real-world clinical traffic. Admissions, lab results, orders, scheduling, charges.
• HL7 v3 (early 2000s) was an ambitious XML rewrite built on an abstract Reference Information Model. It was rigorous, comprehensive, and nearly impossible to implement. Adoption outside a few national programs was minimal. HL7 v3’s failure is the direct cause of FHIR’s design philosophy.
• CDA (Clinical Document Architecture), built on the v3 model, defines clinical documents rather than messages. Its US constraint, C-CDA, is what your Continuity of Care Document and hospital discharge summary exchanges actually use. It remains heavily deployed.
• FHIR, the current standard, which learned from all three.

What is an HL7 Interface?

An HL7 interface is a point-to-point connection that carries HL7 v2 messages between two systems, typically over TCP using a wrapper protocol called MLLP.

Here’s what an actual v2 lab result message looks like:

MSH|^~\&|LABSYS|MERCY|EPICADT|MERCY|202603151432||ORU^R01|MSG00042|P|2.5.1
PID|1||449812734^^^MERCY^MR||CHEN^MEILING^A||19780412|F
OBR|1|ORD9931^LABSYS|LAB77213^LABSYS|4548-4^Hemoglobin A1c^LN|||202603151215
OBX|1|NM|4548-4^Hemoglobin A1c^LN||7.8|%|4.0-5.6|H|||F

Each line is a segment. MSH is the message header, PID is patient identification, OBR is the order, OBX is the observation and result. The pipes separate fields, carets separate components.

This is not as bad as it looks. It’s terse, fast to parse, and it has moved trillions of clinical messages without drama. Interface engines like Mirth Connect, Rhapsody, Cloverleaf, Iguana, and Corepoint exist to route, transform, and monitor these feeds, and skilled integration analysts can stand up a new v2 interface quickly.

The problems with v2 are structural, not cosmetic:

• It’s a push model. The sender decides what you get and when. You cannot query.
• Optionality is rampant. So many fields are optional that two “compliant” v2 implementations often can’t talk without custom mapping.
• Z-segments are everywhere. Anything the standard didn’t anticipate goes into a custom Z segment, which is by definition non-interoperable.
• Every interface is bespoke. Connecting n systems trends toward n² interfaces, which is how health systems end up maintaining hundreds of them.
• No security model. Authentication and authorization are somebody else’s problem.

So how is HL7 used in healthcare today? Mostly this: v2 runs the internal plumbing of hospitals, C-CDA carries documents between organizations, and FHIR handles APIs, apps, and anything regulatory.

HL7 vs FHIR: What’s the Difference?

This is the most-asked question about both standards, so here it is directly.

HL7 is the organization; FHIR is one of its standards. When people ask about “the difference between HL7 and FHIR,” they almost always mean the difference between HL7 v2 and FHIR:

	HL7 v2	FHIR
Model	Messages pushed on events	Resources queried on demand
Transport	TCP/MLLP	HTTPS
Format	Pipe-delimited text	JSON, XML, or RDF
Access	Subscribe to a feed	REST API with search
Customization	Z-segments (non-standard)	Extensions and profiles (standardized)
Security	Not addressed	OAuth 2.0 via SMART
Docs	PDF specification	Browsable spec with examples
Learning curve	Steep and healthcare-specific	Familiar to any web developer
Best at	High-volume internal event flows	Apps, patient access, analytics, APIs

Does FHIR Replace HL7 v2?

Not yet, and not entirely. Anyone telling you v2 is dead has not worked inside a hospital.

Realistically:

• New external-facing work is FHIR. Patient apps, payer APIs, regulatory reporting, third-party integrations.
• Internal event plumbing is still v2. ADT feeds, lab result routing, and charge capture work fine and carry enormous volume. Nobody rips out working infrastructure for architectural purity.
• The two coexist through interface engines, which increasingly translate v2 to FHIR and back. That translation layer is where a lot of practical integration work now lives.

Expect a long overlap. Plan for both.

How the FHIR API Works?

This is where the FHIR standard earns its reputation. If you’ve used any REST API, most of this will feel obvious, which is exactly the point.

FHIR Resources

A resource is the atomic unit of FHIR. It’s a self-contained object with a type, an id, and a defined set of fields. FHIR R4 defines roughly 145 resource types; R5 added more.

The ones you’ll meet constantly:

• Patient, Practitioner, Organization, Location for the who and where
• Encounter for a visit
• Observation for labs, vitals, and most measured values
• Condition for problems and diagnoses
• MedicationRequest, MedicationStatement, AllergyIntolerance, Immunization
• DiagnosticReport for structured reports, DocumentReference for pointers to documents
• Coverage, Claim, ExplanationOfBenefit for the payer side

Here’s the A1c result from the v2 example above, as a FHIR Observation:

{
  "resourceType": "Observation",
  "id": "a1c-77213",
  "status": "final",
  "code": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "4548-4",
      "display": "Hemoglobin A1c/Hemoglobin.total in Blood"
    }]
  },
  "subject": { "reference": "Patient/449812734" },
  "effectiveDateTime": "2026-03-15T12:15:00-05:00",
  "valueQuantity": {
    "value": 7.8,
    "unit": "%",
    "system": "http://unitsofmeasure.org",
    "code": "%"
  },
  "interpretation": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation",
      "code": "H"
    }]
  }]
}

Longer than the v2 line, and far more explicit. The coding systems are named by URL, the units are bound to UCUM, and the patient reference is resolvable. Nothing depends on a shared implementation note buried in a spec document.

How FHIR REST APIs Simplify Integration Across EHR Systems

The FHIR API uses ordinary HTTP against predictable URLs:

GET    [base]/Patient/449812734          # read one patient
GET    [base]/Patient?family=chen&birthdate=1978-04-12
POST   [base]/Observation                # create
PUT    [base]/Patient/449812734          # update
GET    [base]/Patient/449812734/$everything

Search is where it gets useful:

GET [base]/Observation?patient=449812734
    &code=http://loinc.org|4548-4
    &date=ge2025-01-01
    &_sort=-date
    &_count=4

That single request returns the last four A1c results since January 2025, sorted newest first. The same request works against Epic, Oracle Health, MEDITECH, athenahealth, or any conformant FHIR server.

That portability is the actual value proposition. With v2, integrating with a second EHR meant a second project. With FHIR, it means a different base URL, a different OAuth registration, and a tolerance for vendor quirks. The quirks are real, but the shape of the work no longer changes per vendor.

Bundles, Compartments, and Operations

Three concepts that come up fast:

• Bundle is a container. Search results come back as a Bundle. You can also POST a Bundle as a transaction to write several resources atomically.
• Compartments group resources by subject, which is what makes Patient/123/$everything possible.
• Operations, prefixed with $, handle things REST doesn’t express well: $everything, $validate, $match for patient matching, $export for bulk extraction.

The Four FHIR Paradigms

FHIR isn’t only REST. The spec defines four exchange paradigms, and knowing they exist prevents a lot of confusion:

1. REST for request and response. The dominant pattern.
2. Messaging for event-driven exchange, conceptually similar to v2.
3. Documents for signed, immutable clinical documents, conceptually similar to CDA.
4. Services for arbitrary operations that don’t fit the other three.

There’s also Subscriptions, which let a server notify a client when matching data changes. This is FHIR’s answer to the push use case v2 handles today, and it’s how the standard closes its last real gap against v2.

FHIR Versions: R4, R5, and What to Build On

FHIR version history in short:

• DSTU1 (2014) and DSTU2 (2015): early trial use
• STU3 (2017): wider adoption, still not stable
• R4 (published late 2018): the first release with normative content, meaning backward compatibility guarantees
• R4B (2022): a small maintenance release
• R5 (2023): substantial improvements, modest adoption
• R6: in development and balloting; confirm current status before planning around it

Build on R4. That advice sounds dated and remains correct, because R4 is the version written into US regulation. ONC certification criteria and the US Core Implementation Guide are anchored to R4, so R4 is what certified EHRs expose. R5 is technically better and commercially less useful.

This is the single most common mistake new FHIR developers make: reading the current spec on the HL7 website, building against R5, and discovering that every EHR they need to reach speaks R4.

Profiles, Extensions, and Implementation Guides

Base FHIR is deliberately incomplete. The spec follows an 80/20 rule: include what roughly 80 percent of implementers need everywhere, and push the rest into extensions.

That means base FHIR alone is not enough to achieve interoperability. Two systems can both be valid FHIR and still fail to exchange usefully. The layer that fixes this:

• Extensions add fields the base resource lacks, in a standardized, machine-readable way. This is the disciplined replacement for v2’s Z-segments.
• Profiles constrain a resource: which fields are required, which codes are allowed, which extensions apply.
• Implementation Guides (IGs) bundle profiles, terminology, and rules for a specific use case.

When someone says “we support FHIR,” the useful follow-up is “which implementation guides?”

US Core

US Core is the baseline profile set for the United States. It defines the minimum each resource must contain to satisfy US requirements, and it’s bound to the United States Core Data for Interoperability (USCDI), the government’s list of required data classes.

USCDI advances by version. Certified health IT was required to support USCDI v3 as of January 1, 2026, with later versions in the pipeline. If you’re building for the US market, US Core is not optional reading.

Da Vinci

The Da Vinci Project produces IGs for payer and provider workflows. The prior authorization set is the most consequential:

• CRD (Coverage Requirements Discovery): does this order need authorization?
• DTR (Documentation Templates and Rules): what documentation is required, pulled from the chart automatically?
• PAS (Prior Authorization Support): submit the request and get a decision

These are the guides underlying CMS’s Prior Authorization API requirement, which impacted payers must implement by January 1, 2027. If you work anywhere near prior authorization, Da Vinci is the technical spine of the reform.

Other Da Vinci guides cover payer data exchange (PDex), gaps in care, and member attribution.

CARIN Blue Button

CARIN Blue Button standardizes claims and encounter data for patient-facing apps, and it’s the basis for the Patient Access API that Medicare Advantage, Medicaid, CHIP, and marketplace plans have been required to expose since 2021.

Bulk FHIR

Regular FHIR is built for one patient at a time. Bulk Data Access, sometimes called Flat FHIR, adds an $export operation that returns whole populations as newline-delimited JSON files.

If your use case is analytics, quality measurement, risk adjustment, or research, Bulk FHIR is the part you care about, and it’s a different implementation effort from patient-level APIs. Plan for it separately.

Worth noting for anyone tracking national exchange: TEFCA has committed to FHIR-based exchange through its Facilitated FHIR approach, which makes FHIR fluency a prerequisite for participating in nationwide data sharing rather than a nice-to-have.

What is SMART on FHIR?

SMART on FHIR is the authorization and app-launch framework that lets a third-party application securely connect to an EHR’s FHIR API, with the user’s permission and the right patient in context.

SMART stands for Substitutable Medical Applications, Reusable Technologies. It came out of the Computational Health Informatics Program at Boston Children’s Hospital, with Ken Mandl and Josh Mandel among its principal architects. The founding vision was an app store for healthcare: write an app once, run it inside any EHR.

FHIR answers “what does the data look like and how do I request it.” SMART answers “who are you, what are you allowed to see, and which patient are we talking about.” You need both. FHIR without SMART is an API with no front door.

How SMART App Launch Works

SMART is built on OAuth 2.0 for authorization and OpenID Connect for identity, with healthcare-specific additions.

There are two launch patterns:

• EHR launch: a clinician clicks your app from inside the EHR. The EHR passes launch context, so your app already knows the current patient and user.
• Standalone launch: a patient opens your app directly, picks their provider, and logs in with their patient portal credentials.

The flow, simplified:

1. Your app fetches the server’s SMART configuration to find its authorization endpoints
2. It redirects the user to the authorization server with the scopes it needs
3. The user authenticates and consents
4. Your app exchanges the resulting code for an access token
5. It calls the FHIR API with that token, plus the patient id from the launch context

Scopes are where SMART gets healthcare-specific:

• patient/Observation.read reads observations for the one patient in context
• user/Patient.read reads patients the logged-in user can access
• launch/patient requests patient context
• offline_access requests a refresh token

SMART v2 and Granular Scopes

SMART App Launch 2.0 improved the framework in ways that matter for anyone building today:

• Granular scopes replace blunt all-or-nothing access. Instead of patient/*.read, you can request patient/Observation.rs?category=laboratory and ask only for lab results.
• Finer-grained permissions split read into separate read and search capabilities.
• Asymmetric client authentication improves security for backend services.

Note the version reality: SMART App Launch 1.0 is what US certification requires, so 1.0 is what you’ll reliably find deployed, with 2.0 support growing. Check per vendor.

There’s also SMART Backend Services, which uses signed JWT client authentication instead of a user login. That’s how automated systems perform Bulk FHIR exports, since there’s no human present to click “allow.”

What Is FHIR Used For?

Concrete deployments, not theory:

• Patient access apps. Any app pulling your records from a health system through your portal login is almost certainly using SMART on FHIR.
• Clinician-facing apps inside the EHR. Risk calculators, specialty scoring tools, and clinical decision support that launch in context and write back.
• Payer APIs. Patient Access, Provider Directory, and the coming Prior Authorization, Provider Access, and Payer-to-Payer APIs.
• Prior authorization automation through Da Vinci CRD, DTR, and PAS.
• Quality measurement and risk adjustment. Bulk FHIR export replacing manual chart abstraction, which is one of the largest cost centers in payer operations.
• Public health reporting. Electronic case reporting and registry submission.
• Research. Cohort identification and data extraction, including large multi-site networks.
• Nationwide exchange. TEFCA’s Facilitated FHIR work.
• Clinical decision support via CDS Hooks, a companion specification that lets an EHR call out to external services at defined workflow moments.

Where FHIR Falls Short

An honest guide has to say this part out loud.

• Conformance varies widely. Two certified FHIR servers can behave differently on search parameters, pagination, and optional fields. “It works against Epic” is not the same as “it works.”
• Data quality is untouched. FHIR standardizes structure, not accuracy. A cleanly formatted Condition resource can still carry a stale problem list.
• Write access is scarce. Most production FHIR APIs are read-heavy. Writing back to the chart is limited, gated, and vendor-specific.
• Terminology is still hard. FHIR points at LOINC, SNOMED CT, RxNorm, and ICD-10. It does not make anyone use them consistently, and local codes persist everywhere.
• Performance at scale bites. Retrieving a large population one resource at a time is slow, which is precisely why Bulk FHIR exists.
• Version fragmentation is real. R4 in production, R5 published, R6 coming, and IGs pinned to different releases.
• Documents did not go away. Plenty of exchange still moves C-CDA inside a DocumentReference, which means you have a FHIR wrapper around a document you still have to parse.

None of this argues against FHIR. It argues against treating FHIR support as a finished integration.

Frequently Asked Questions

What does FHIR stand for?

Fast Healthcare Interoperability Resources. It’s pronounced “fire” and published by HL7 International, which is why it’s often written HL7 FHIR.

What is FHIR in healthcare?

A standard that defines health data as modular resources such as Patient, Observation, and Condition, and defines a REST API for exchanging them over HTTPS in JSON or XML. It’s the basis for patient-facing health apps, payer APIs, and current US interoperability regulation.

What does HL7 stand for?

Health Level Seven, a reference to the application layer of the OSI networking model. HL7 International is the standards organization; HL7 v2 is the messaging standard most people mean by “HL7.”

What is HL7 in healthcare?

It refers to two things. HL7 International is the standards organization behind most US healthcare data standards. “HL7” on its own usually means HL7 v2, the messaging standard that carries admissions, lab results, orders, and charges between hospital systems. Ask which one someone means.

What is the difference between HL7 and FHIR?

HL7 is the organization that publishes FHIR, so they aren’t alternatives. Comparing HL7 v2 to FHIR: v2 pushes pipe-delimited messages over TCP when events occur, while FHIR exposes queryable resources over a REST API in JSON with OAuth security. FHIR is easier to adopt; v2 still carries more internal hospital traffic.

Does FHIR replace HL7 v2?

Eventually in some areas, not soon overall. New external and regulatory work uses FHIR. Internal hospital feeds still run largely on v2, and most organizations will operate both for years.

What is an HL7 interface?

A point-to-point connection carrying HL7 v2 messages between two systems, usually over TCP with MLLP framing, often managed through an interface engine such as Mirth Connect or Rhapsody.

What is HL7 integration?

Connecting two systems so they can exchange HL7 messages, historically v2 feeds routed through an interface engine. Modern HL7 integration work increasingly means translating between v2 and FHIR rather than building new v2 interfaces from scratch.

What is a FHIR API?

A web API that follows the FHIR standard: predictable URLs like GET [base]/Patient/123, standard HTTP verbs, a defined search syntax, and JSON or XML payloads.

What is SMART on FHIR?

An authorization and app-launch framework built on OAuth 2.0 and OpenID Connect that lets third-party apps connect securely to an EHR’s FHIR API with the correct user and patient context. SMART stands for Substitutable Medical Applications, Reusable Technologies.

Which FHIR version should I use?

R4, in almost all US cases, because R4 is what certification requires and what certified EHRs expose. Read the R4 specification rather than the newest published version.

Is FHIR free to use?

Yes. The FHIR specification is published openly and can be implemented without license fees. Some terminologies it references, notably SNOMED CT, carry their own licensing terms depending on your country and use.

What to Do Next

If you’re evaluating FHIR for a project, three steps beat another week of reading.

Make a real call against a public sandbox. Every major EHR vendor runs one. Register a test app, complete a SMART launch, pull an Observation. An afternoon of that teaches more than any overview, including this one.

Identify your implementation guide before you design anything. US Core if you’re doing general clinical data, CARIN Blue Button for claims, Da Vinci if you’re between payer and provider, Bulk Data if you’re doing population analytics. The IG determines your data model, so choosing it late means rework.

Decide early whether you need one patient or a population. Patient-level FHIR and Bulk FHIR are different engineering problems with different authorization models. Teams that discover this at month four lose the most time.