By Eric Andrew Kristof, RN, CAHIMS | Healthcare IT Professional | HIMSS Arkansas Chapter Member
About This Series: The HIMSS Word of the Day is a running blog series drawing from the HIMSS Dictionary of Health Information and Technology Terms, Acronyms, and Organizations, 6th Edition (2025) — the authoritative reference for healthcare IT professionals and the primary study resource for CAHIMS and CPHIMS certification. Each post paraphrases the term in plain language, grounds it in real-world healthcare IT context, and adds a bedside nursing perspective you won’t find in a textbook.
📖 The Term: Fast Healthcare Interoperability Resources (FHIR)
Source: HIMSS Dictionary of Health Information and Technology Terms, Acronyms, and Organizations, 6th Edition (2025)
🔍 Plain-Language Definition
FHIR (pronounced “fire”) is HL7’s modern standard for exchanging healthcare data. It breaks health information into small, well-defined building blocks called resources, such as a patient, an encounter, a lab observation, a medication order, or a problem-list entry, and moves them using the same web technologies that power everyday apps.
The HIMSS Dictionary describes FHIR as HL7’s next-generation framework, one that keeps the strengths of its older standards (HL7 Version 2, Version 3, and the Clinical Document Architecture) while adopting current web standards and putting ease of implementation first. Simple resources cover the everyday basics of care, and they can be combined to represent more complex clinical models. Their definitions rest on careful requirements work and cross-mapping to other standards.
The practical difference from older standards is granularity. Instead of sending a whole document or a long pipe-delimited message, a FHIR client can ask for exactly one thing, such as a patient’s active medications, and get back exactly that.
| FHIR Building Block | What It Does |
|---|---|
| Resources | Standard data structures (Patient, Observation, Condition, MedicationRequest, Encounter, and roughly 150 more) that represent discrete clinical and administrative concepts |
| RESTful API | Uses ordinary web requests to read, search, create, and update resources, typically exchanged as JSON |
| Profiles and Implementation Guides | Constrain base resources for a specific use. In the U.S., the US Core guide defines how to represent USCDI data in FHIR |
| Terminology Bindings | Tie resource fields to code systems such as SNOMED CT, LOINC, and RxNorm so the meaning travels with the data |
| SMART on FHIR | Adds standardized app launch and OAuth 2.0 authorization so third-party apps can run inside or alongside the EHR |
| Bulk Data (Flat FHIR) | Exports data for whole populations at once for analytics, quality reporting, and payer use cases |
⚠️ Exam Alert: Keep the layers straight. FHIR is the exchange standard and API. HL7 v2 is the older message standard still running most hospital interfaces (ADT, orders, results). C-CDA is a document standard for summaries such as discharge summaries. USCDI defines what data must be exchangeable, US Core defines how that data looks in FHIR, and TEFCA defines the network rules for who exchanges it nationally. FHIR complements HL7 v2 rather than replacing it overnight.
🌐 Why It Matters: Real-World Healthcare IT Context
FHIR moved from promising draft to federal requirement in about a decade.
HL7 published the first draft standard in 2014. Release 4, in 2019, was the first to include normative content, meaning core parts of the standard were stable enough to build long-term products on. That stability is why U.S. regulation names FHIR R4.
The regulatory turning point was the ONC Cures Act Final Rule (2020). Certified EHRs must now offer a standardized API for patient and population services, built on FHIR R4, the US Core implementation guide, SMART App Launch, and Bulk Data. On the payer side, the CMS Interoperability and Patient Access Final Rule required many CMS-regulated health plans to offer a FHIR-based Patient Access API. The later CMS Interoperability and Prior Authorization Final Rule extends FHIR APIs to prior authorization and payer-to-provider exchange, with requirements phasing in through 2027.
What FHIR makes possible:
- Patients downloading their own records into apps of their choice
- Third-party clinical apps (risk calculators, growth charts, and specialty tools) launching inside the EHR through SMART on FHIR
- Decision support delivered from outside the EHR through CDS Hooks
- Population-level data export for quality measurement and research
- Faster, more automated prior authorization between providers and payers
Where FHIR programs struggle:
- Inconsistent implementation, where two “FHIR-compliant” systems still disagree on details
- Data quality problems that FHIR transports faithfully but cannot fix
- Security and privacy review of third-party apps that receive patient data
- Hospitals still running hundreds of HL7 v2 interfaces alongside new FHIR APIs
- Workforce gaps in the developers and analysts who understand both clinical data and APIs
FHIR does not create interoperability by itself. It removes much of the technical friction so policy, governance, and data quality become the remaining work.
🏥 The Nurse’s Perspective: Clinical, Bedside, & Workflow
Nurses rarely hear the word FHIR on a shift, but they increasingly work with the data it moves.
At the Bedside
When a patient opens a phone at admission and shows a medication list pulled from another health system’s portal, that list very likely traveled over a FHIR API. When a home blood pressure cuff’s readings appear in the chart, a FHIR Observation is often behind them. FHIR is turning the patient’s own devices into legitimate sources of clinical information, and nurses are often the first clinicians to decide whether that information can be trusted.
That judgment matters. FHIR moves data faithfully, including data that is incomplete or out of date. The nurse’s reconciliation conversation with the patient remains the safety check.
In Clinical Workflow
Inside the EHR, SMART on FHIR apps show up as tools embedded in the workflow: a pediatric growth chart, a fall-risk calculator, a specialty documentation aid. For nurses, the benefit is fewer separate logins and less copying between systems. The risk is a new tool appearing in the workflow without training or clear ownership of its output.
Nursing data is also part of what FHIR exchanges. Vital signs, assessments, care plan goals, and screening results are all representable as FHIR resources, which means well-structured nursing documentation can follow the patient to the next care setting rather than staying trapped in one facility’s flowsheets.
In EHR Implementation (Go-Live Perspective)
During an Epic Go-Live, most of the interface traffic is still HL7 v2: ADT messages, lab results, pharmacy orders, and charges. FHIR work tends to appear in the integration of third-party apps, patient-facing features, and payer connections, often in later phases after the core cutover is stable.
End-user support analysts encounter FHIR indirectly through questions like why an outside app’s data is not showing, or why a patient’s app cannot connect. Knowing that FHIR APIs, app registration, and patient authorization are separate layers from the classic interfaces helps route those tickets to the right integration team instead of the general help desk queue.
🎓 CAHIMS / CPHIMS & HIMSS Perspective
CAHIMS Exam Domain Mapping
FHIR is one of the most heavily tested standards on the CAHIMS exam:
| CAHIMS Domain | How FHIR Appears |
|---|---|
| Healthcare & Technology Environments | Cures Act Final Rule API requirements; CMS patient access and prior authorization rules; HL7 as a standards development organization; information blocking |
| Clinical Informatics | SMART on FHIR apps in clinical workflow; CDS Hooks; patient-generated health data; terminology bindings |
| Healthcare Information & Systems Management | FHIR versus HL7 v2 versus C-CDA; API security and OAuth; integration architecture; Bulk Data for analytics |
| Management & Leadership | Third-party app governance; vendor management; regulatory compliance planning; interoperability strategy |
Key Terms to Know Alongside FHIR
- HL7 (Health Level Seven International) — the standards development organization that publishes FHIR, HL7 v2, and C-CDA
- HL7 Version 2 — the older, widely deployed message standard that still runs most hospital interfaces
- US Core Implementation Guide — the U.S. profiles that define how USCDI data is represented in FHIR
- USCDI (U.S. Core Data for Interoperability) — the federal list of data classes and elements that certified systems must be able to exchange
- SMART on FHIR — the app launch and authorization framework that lets apps securely connect to EHR data
- API (Application Programming Interface) — the defined interface software uses to request and exchange data, which FHIR standardizes for healthcare
HIMSS Organizational Position
HIMSS treats interoperability as central to its mission and advocates for standards-based exchange, including FHIR, through its public policy work with federal agencies. Interoperability and FHIR implementation are recurring themes in HIMSS Global Health Conference programming, and members can find related research and guidance through the HIMSS Resource Center.
🔗 Explore Further: External References
- HL7 International — FHIR Specification https://www.hl7.org/fhir/
- HL7 — US Core Implementation Guide https://hl7.org/fhir/us/core/
- HL7 — SMART App Launch Implementation Guide https://hl7.org/fhir/smart-app-launch/
- ONC — Cures Act Final Rule https://healthit.gov/regulations/cures-act-final-rule/
- CMS — Interoperability and Patient Access Final Rule (CMS-9115-F) https://www.cms.gov/initiatives/burden-reduction/overview/interoperability/policies-regulations/cms-interoperability-patient-access-final-rule-cms-9115-f
- CMS — Interoperability and Prior Authorization Final Rule (CMS-0057-F) https://www.cms.gov/initiatives/burden-reduction/overview/interoperability/policies-regulations/cms-interoperability-prior-authorization-final-rule-cms-0057-f
Term source: HIMSS Dictionary of Health Information and Technology Terms, Acronyms, and Organizations, 6th Edition (2025). All definitions in this series are paraphrased for editorial purposes. Readers are encouraged to consult the primary source for exact language.
Eric Andrew Kristof, RN, CAHIMS is a Healthcare IT professional and HIMSS Arkansas Chapter member based in Hot Springs Village, AR, with hands-on Epic Go-Live experience and a diverse healthcare and IT background. He writes at kristof.org at the intersection of clinical care and healthcare technology.
Leave a Reply