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: FHIR Resource
Source: HIMSS Dictionary of Health Information and Technology Terms, Acronyms, and Organizations, 6th Edition (2025)
🔍 Plain-Language Definition
A FHIR resource is the basic building block of the HL7 FHIR (Fast Healthcare Interoperability Resources) standard. In FHIR, all content that can be exchanged is defined as a resource. The HIMSS Dictionary notes what resources have in common: they are defined and represented in the same way, they are assembled from shared data types, they carry standard metadata, and they include a part people can read.
Each resource type describes one kind of thing in health care. A Patient resource carries demographics. An Observation carries a measurement such as a vital sign or lab result. A MedicationRequest carries an order for a drug. A Condition carries a problem or diagnosis. Resources point to each other through references; an Observation refers to the Patient it concerns and the Encounter during which it was made. The FHIR specification describes resources as usable to exchange or store data to solve a wide range of clinical and administrative problems, and defines several ways of exchanging them, including a RESTful application programming interface.
| Resource Element | What It Holds | Example |
|---|---|---|
| Type | Which kind of resource it is | Observation |
| Logical id | Identifier used in the resource’s address; never changes once assigned | “123” |
| Metadata | Information maintained by the infrastructure, such as version and last update | Version, profile claims |
| Content | Structured data items defined for that resource type | Value, unit, date |
| Narrative text | Human-readable summary of the content | “Blood pressure 120/80” |
| Extensions | Added data elements beyond the base definition | Local or specialty elements |
⚠️ Exam Alert: A resource is the unit of exchange in FHIR; a profile constrains a resource for a specific use; an implementation guide collects profiles and rules for a use case. FHIR is not the same as HL7 v2 messages or C-CDA documents, though it can carry similar content. Terminology such as LOINC and SNOMED CT fills coded fields in resources.
🌐 Why It Matters: Real-World Healthcare IT Context
Earlier health data standards were built around messages or documents. FHIR breaks content into smaller, addressable resources that applications can request individually, for example, a patient’s recent observations or active medications. This approach suits modern web and mobile applications and supports the application programming interfaces that patients and third-party apps use to access data. It also changes how organizations think about data: a record is a set of linked resources, each with its own identity and history.
The FHIR specification gives every resource a consistent frame. The logical id appears in the resource’s address and, once assigned, never changes. Metadata maintained by the infrastructure can change without changing the resource version. A resource may also declare the rules it followed, often by reference to an implementation guide that defines additional constraints. Because the base resources are intentionally general, real-world use depends on profiles that say which elements are required, which terminologies apply, and how extensions are used. A Patient in one country, or for one program, may be profiled differently from a Patient in another.
Mapping existing data into resources is a large piece of the work, and a 2026 scoping review in the Computational and Structural Biotechnology Journal examined how well this is assessed. Many existing health information systems predate FHIR and must translate their data models and elements into resources. The review screened 742 studies and included 39. It found fragmented practices and limited consensus on how to assess mapping quality, with most studies relying on manual evaluation of the transformed data and few considering source-to-target relationships before transformation. The authors, with input from four experts, formulated six requirements for future pre-mapping quality assessment frameworks. The takeaway for implementers is that a mapping project needs explicit quality checks, such as completeness, correctness, and consistency of transformed data, and cannot assume that valid FHIR output is accurate output.
FHIR also supports analytics and decision support. A 2023 scoping review in JMIR Medical Informatics identified 39 articles describing FHIR-based machine learning clinical information systems, divided into clinical decision support systems (18), data management and analytic platforms (10), and auxiliary modules and application programming interfaces (11). The review found strengths such as use of cloud systems and techniques to translate free text into FHIR, but also that many intelligent systems lacked EHR interoperability and externally validated evidence of clinical efficacy. Using FHIR does not by itself make a model safe or useful.
National systems show what FHIR can do at scale. A 2026 paper in JMIR Medical Informatics describes DEMIS, the German electronic reporting system for mandatory infectious disease notifications, which replaced paper-based reporting in 2020. DEMIS provides FHIR-based interfaces accessible by several authentication methods for laboratories, hospitals, and public health authorities, and uses standardized terminologies such as LOINC and SNOMED CT to submit information on notifiers, patients, diagnostics, clinical data, and epidemiological details. The paper reports on conceptualization from 2012, acceleration during the COVID-19 pandemic, and associated challenges. It illustrates that FHIR is a tool within a larger program that needs governance, security, and coordination.
For organizations, practical steps include learning which resources and profiles their EHR vendor supports, using validation tools, aligning with the U.S. Core Data for Interoperability where required, testing apps in a sandbox, and managing consent and security for patient-directed access. Teams should document mappings, keep terminology up to date, and monitor failures. Sensitive data need labels and policy so that sharing through APIs does not expose more than intended.
Common FHIR resource problems:
- Treating valid structure as proof of correct content
- Extensions used so freely that partners cannot interpret them
- Mappings that lose nuance from source data
- Different profiles in use by different partners
- Terminology bindings that are missing or out of date
- Security and consent handled as an afterthought
What supports effective FHIR use:
- Clear profiles and implementation guides for each use case
- Mapping quality checks before and after transformation
- Automated validation in development and monitoring in production
- Terminology management for coded elements
- Security, consent, and sensitivity labeling designed in
- Testing with real partners and applications
🏥 The Nurse’s Perspective: Clinical, Bedside, & Workflow
Nurses document the data that FHIR resources carry, and they use applications that read them.
At the Bedside
Vital signs, pain scores, intake and output, and assessments become Observation resources when they are recorded in structured fields with the right codes. Free text stays human-readable, but a program cannot easily analyze it. Careful use of structured documentation lets data move to other systems, patient apps, and public health reports.
In Clinical Workflow
Nurse managers rely on integrated data when patients transfer, when remote monitoring data feed the record, and when quality reports pull from the EHR. Case managers use outside records brought in through APIs and see gaps when a source system sends less than expected.
Nurse informaticists help define which nursing data should map to which resources, check that terminology fits nursing practice, and review how outside data display in the record. They take part in testing apps that use FHIR interfaces, from patient-facing tools to bedside devices.
In EHR Implementation (Go-Live Perspective)
An Epic Go-Live activates interfaces and APIs that use FHIR for patient access and data exchange. Analysts test that key resources, such as medications and allergies, show correct content to patients and outside apps. At-the-elbow support analysts hear from nurses about missing or confusing data from outside sources, and those reports help interface teams find mapping gaps.
🎓 CAHIMS / CPHIMS & HIMSS Perspective
CAHIMS Exam Domain Mapping
FHIR resources appear in standards, interoperability, and application questions:
| CAHIMS Domain | How FHIR Resources Appear |
|---|---|
| Healthcare & Technology Environments | Interoperability policy, standards development organizations |
| Clinical Informatics | Clinical data modeling, terminology, decision support |
| Healthcare Information & Systems Management | APIs, mapping, validation, security, integration |
| Management & Leadership | Interoperability strategy, vendor evaluation, governance |
Key Terms to Know Alongside FHIR Resource
- HL7 FHIR — standard for exchanging health data using resources and web technologies
- Profile — set of constraints applied to a resource for a specific use
- Implementation Guide — package of profiles and rules for a use case
- RESTful API — web interface that creates, reads, updates, and deletes resources
- Extension — added data element beyond a resource’s base definition
- Terminology Binding — link between a coded element and a defined value set
HIMSS Organizational Position
HIMSS supports interoperability and standards-based exchange through its public policy work, research, and education. Members can find related resources through the HIMSS Resource Center and Public Policy and Advocacy pages.
🔗 Explore Further: External References
- HL7 — FHIR R4 Resource Infrastructure https://hl7.org/fhir/R4/resource.html
- HL7 — FHIR Overview https://hl7.org/fhir/
- Seth et al. (2026), Computational and Structural Biotechnology Journal — FHIR Data Mapping Quality Assessment: A Scoping Review and Expert-Informed Requirements for Future Pre-Mapping Frameworks https://pubmed.ncbi.nlm.nih.gov/42923490/
- Balch et al. (2023), JMIR Medical Informatics — Machine Learning-Enabled Clinical Information Systems Using Fast Healthcare Interoperability Resources Data Standards: Scoping Review https://pubmed.ncbi.nlm.nih.gov/37646309/
- Suwono et al. (2026), JMIR Medical Informatics — Digitalization of the Mandatory Notifications System for Infectious Diseases in Germany: Implementation of DEMIS https://pubmed.ncbi.nlm.nih.gov/42753233/
- ONC — United States Core Data for Interoperability (USCDI) https://isp.healthit.gov/united-states-core-data-interoperability-uscdi
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