HL7 FHIR Resources: The 5 Resource Categories, JSON Data Model, Reference Graphs, and Bundles

FHIR resources are the modular, addressable building blocks of the Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR) standard used to represent and exchange clinical, administrative, financial, and research healthcare data. Whereas legacy health data standards such as HL7 v2 transmitted pipe-delimited event messages and HL7 v3 Clinical Document Architecture (C-CDA) exchanged monolithic XML clinical summaries, the HL7 FHIR data model decomposes the electronic health record into discrete, web-addressable units—such as Patient, Observation, Condition, MedicationRequest, and Encounter—that can be created, read, searched, and updated individually via standard HTTP RESTful APIs in JSON, XML, or RDF Turtle formats.

What Is a FHIR Resource?

In the HL7 FHIR specification (spanning FHIR R4 and FHIR R5), a Resource is the smallest unit of transaction that has an independent, meaningful clinical or administrative existence and a persistent URL identity on a FHIR server (for example, https://fhir.example.org/r4/Patient/pat-10482). Every FHIR resource—regardless of whether it describes a vital sign measurement, an insurance claim, or a clinical trial protocol—inherits from the base Resource and DomainResource definitions and shares five structural components:

1. Resource Type and Logical ID (resourceType & id): Declares the canonical FHIR resource class (e.g., "Observation") and the server-assigned logical identifier that uniquely addresses that instance on the host server.
2. Resource Metadata (meta): Carries operational provenance and governance tags, including the version identifier (versionId), last-updated timestamp (lastUpdated), security classification labels (such as confidentiality codes), and conformance profile URLs (profile, such as an ONC US Core profile).
3. Human-Readable Narrative (text): An XHTML block containing a human-readable summary of the resource’s clinical content, ensuring that a receiving clinician can safely display the record even if their system does not parse every specialized coded element.
4. Structured Core Elements (80/20 Rule): HL7 designs core resource schemas according to the 80/20 rule: core fields inside a resource cover only the data elements required by roughly 80% of mainstream healthcare implementations worldwide, keeping the base specification lean and implementable.
5. Extensibility Framework (extension): For the remaining 20% of jurisdiction-specific, specialty-specific, or clinical-trial-specific attributes (such as OMB race/ethnicity categories in the United States or oncology staging extensions in mCODE), FHIR uses strongly typed extension arrays pointed to a canonical StructureDefinition URL rather than untyped custom fields.

What Are the Main Categories of FHIR Resources?

In HL7 FHIR Release 4 (R4, v4.0.1)—which comprises approximately 145 resource types and serves as the federally mandated baseline for ONC 21st Century Cures Act certification—HL7 organizes all resources into five foundational categories based on their architectural layer:

FHIR Resource Category	Architectural Purpose	Core Representative Resource Types	Typical Clinical & Research Role
1. Foundation Resources	Infrastructure, packaging, terminology, conformance profiling, and security auditing	Bundle, CapabilityStatement, StructureDefinition, ValueSet, CodeSystem, ConceptMap, AuditEvent, Provenance, OperationOutcome	Wraps REST search results and batches; defines US Core profiles; tracks 21 CFR Part 11/HIPAA audit trails
2. Base Resources	Administrative entities, identities, encounters, locations, and scheduling workflows	Patient, Practitioner, PractitionerRole, Organization, Location, Encounter, EpisodeOfCare, Appointment, Schedule, Device	Establishes who received care, who delivered it, where it occurred, and during which clinical visit
3. Clinical Resources	Observations, diagnoses, medications, care plans, diagnostic reports, and procedures	Observation, Condition, Procedure, MedicationRequest, MedicationAdministration, AllergyIntolerance, DiagnosticReport, Immunization, CarePlan, ServiceRequest	Captures vital signs, LOINC lab results, SNOMED CT/ICD-10 diagnoses, RxNorm orders, and imaging reports
4. Financial Resources	Coverage verification, claims submission, prior authorization, and payment reconciliation	Coverage, Claim, ClaimResponse, ExplanationOfBenefit, CoverageEligibilityRequest, Account, ChargeItem	Powers CMS Patient Access APIs, Da Vinci prior authorization, and revenue cycle eligibility checks
5. Specialized Resources	Public health reporting, clinical research trials, quality measurement, and evidence-based medicine	ResearchStudy, ResearchSubject, Measure, MeasureReport, MolecularSequence, Questionnaire, QuestionnaireResponse	Supports EHR-to-EDC trial enrollment, ePRO survey capture, eCQM quality reporting, and clinical genomics

How Do FHIR Resources Link Together to Represent a Patient Record?

Unlike a relational SQL database that links tables via integer foreign keys or an HL7 v2 message that nests segments inside a fixed positional hierarchy, FHIR represents a longitudinal patient record as a directed graph of typed Resource References. A Patient resource contains only administrative demographics (name, birthDate, gender, medical record number identifiers, and contact details); it does not embed arrays of the patient’s diagnoses, lab results, or prescriptions inside the Patient JSON object itself.

Instead, clinical and financial resources point inward toward the Patient and Encounter via explicit Reference elements:

• Subject and Context Pointers: An Observation resource (such as a serum creatinine result coded with LOINC) contains a "subject": {"reference": "Patient/pat-10482"} element linking it to the patient, an "encounter": {"reference": "Encounter/enc-9901"} element linking it to the specific inpatient admission, and a "performer": [{"reference": "Practitioner/prac-441"}] element linking it to the ordering clinician.
• Clinical Reasoning Chains: A DiagnosticReport references multiple child Observation resources in its result array; a MedicationRequest references a Condition resource in its reasonReference element to justify why a drug was prescribed; and a Provenance resource points to any target resource to record the digital signature, author, and timestamp of an update.
• Packaging Multi-Resource Graphs with Bundle: When a client application queries an EHR endpoint (such as Epic on FHIR) or a cloud repository (such as AWS HealthLake, Smile Digital Health, or Firely Server) using a search query with _include or _revinclude parameters—for example, GET /Patient?_id=pat-10482&_revinclude=Condition:patient&_revinclude=Observation:patient—the server packages the matching Patient, Condition, and Observation instances into a single container resource of type Bundle ("type": "searchset"). Similarly, Bundle resources of type transaction or batch allow clients to submit an atomic graph of interlinked resources in a single HTTP POST request.

Frequently Asked Questions

What is a FHIR resource?

A FHIR resource is a modular, individually addressable data packet in the HL7 FHIR standard—such as a Patient, Observation, Condition, or MedicationRequest—that combines a logical URL identifier, metadata, a human-readable XHTML narrative, structured data elements, and typed extensions in JSON or XML format.

What are the main categories of FHIR resources?

HL7 organizes FHIR resources into five main categories: Foundation resources (infrastructure, terminology, and Bundles), Base resources (Patients, Practitioners, Organizations, and Encounters), Clinical resources (Observations, Conditions, Procedures, and Medications), Financial resources (Coverage, Claims, and ExplanationOfBenefit), and Specialized resources (ResearchStudy, Questionnaire, and MeasureReport).

How do FHIR resources link together to represent a patient record?

FHIR resources form a directed graph using typed Reference fields: clinical resources such as Observation, Condition, and MedicationRequest include a subject reference pointing to the target Patient resource and an encounter reference pointing to the visit, and can be retrieved together inside a single FHIR Bundle container.