Resource (FHIR Resource)

fhir technical technical fhirinteroperabilityhealthcare
Source: HL7 System: http://hl7.org/fhir Code: Resource Reviewed: 16/01/2026 License: CC-BY-4.0

Resource (FHIR Resource)

One-sentence definition: A FHIR Resource is a discrete, self-describing unit of healthcare data — such as a Patient, Observation, or MedicationRequest — that has a defined structure, a unique identity, and is exchanged via RESTful HTTP operations.

Full Definition

FHIR defines approximately 160 resource types in R4, each representing a single healthcare concept. Resources are the atomic unit of FHIR data exchange: every API call creates, reads, updates, or deletes a resource; every Bundle contains resources; every profile constrains a resource type.

Each resource has a set of common elements present across all types — resourceType, id, meta, text, and extension — plus the type-specific data elements defined for that resource in the FHIR specification. Resources are serialized as JSON (most common in modern implementations), XML, or Turtle (RDF).

A resource instance is identified by a logical ID within a server: [base]/Patient/123. That same resource may also be identified by a persistent canonical URL or by a business identifier (such as an MRN), depending on the reference context.

Implementation details: This entry covers the definition and purpose of FHIR resources. For resource structure (id, meta, text, extension), reference types, the resource lifecycle, and practical JSON examples, see the canonical reference → What Is FHIR.

Context and Usage

Where This Term Appears

Resources appear throughout the FHIR ecosystem:

  • API request and response URLs (GET /Patient/123, POST /Observation)
  • FHIR server logs and audit trails
  • Implementation Guide (IG) documentation and conformance requirements
  • Application code — serialization, validation, transformation logic
  • Bundles — collections of resources sent together in a transaction or message
  • Validation error messages (“resource does not conform to profile http://…”)

Common Usage Examples

In conversation: “The EHR exposes Observation resources for lab results — we pull them every 15 minutes and push to our analytics pipeline.”

In documentation: “All Patient resources returned by this server conform to the US Core Patient profile.”

In technical contexts:

GET /Patient/123
GET /Observation?patient=123&category=laboratory
POST /MedicationRequest

Why FHIR Resources Exist

Earlier HL7 standards encoded healthcare data in ways that were difficult to work with at scale. HL7 v2 used flat, positional pipe-delimited segments — fast for transactions but version-fragile and hard to parse cleanly. HL7 v3 introduced complex XML schemas with a formal Reference Information Model (RIM) that proved too difficult for most development teams to implement correctly.

FHIR resources solved this by applying familiar REST API patterns to health data. Each resource type is a modular, consistently structured data object that can be independently versioned, profiled, validated, and composed into Bundles. This made health data as accessible as any REST API — any developer who has worked with JSON APIs can understand a FHIR resource with minimal ramp-up time.

Resource Categories

FHIR R4 resources are organized into five broad functional categories: Clinical (the core clinical record — Patient, Observation, Condition, Procedure, MedicationRequest, DiagnosticReport, and others), Administrative (who delivered care and where — Organization, Practitioner, Location, Appointment), Financial (payer and billing workflows — Claim, ExplanationOfBenefit, Coverage), Infrastructure (the FHIR machinery itself — Bundle, CapabilityStatement, StructureDefinition, ValueSet, OperationOutcome), and Definitional (templates and protocols — PlanDefinition, Questionnaire, Measure). Most integration work involves clinical and administrative resources; infrastructure resources appear when configuring or querying a FHIR server.

Relationship to Other Terms

  • FHIR — The standard that defines resources; resources are the central concept in FHIR
  • HL7 — The organization that publishes the FHIR specification
  • Profile — A StructureDefinition that constrains a resource type for a specific context
  • Extension — Mechanism for adding data to a resource beyond its base definition
  • LOINC — The coding system used in Observation.code to identify what was measured

Common Misconceptions

Misconception 1: Each Resource Type Needs Its Own Database Table

  • Incorrect belief: A FHIR server must have a patients table, an observations table, a conditions table, and so on — one table per resource type.
  • Reality: This is an implementation detail. FHIR servers commonly use a single resources table with type as a column, a document store (MongoDB, DynamoDB) with resource type as a field, or any other storage approach. The resource model is a logical interface contract, not a database schema prescription.
  • Why it matters: Choosing a storage architecture based on the mistaken assumption of required per-type tables leads to unnecessary complexity and missed optimization opportunities. Let the access patterns — search, versioning, bulk export — drive the schema, not the resource taxonomy.

Misconception 2: Resources Map 1:1 to Clinical Concepts

  • Incorrect belief: One clinical event or concept = one FHIR resource.
  • Reality: A single clinical event typically maps to multiple resources linked by references. A blood panel is one DiagnosticReport referencing many Observation resources (one per analyte). An encounter produces an Encounter resource, Condition resources for problems identified, MedicationRequest resources for prescriptions, and Procedure resources for interventions — all linked together.
  • Why it matters: Queries that retrieve “all data for this encounter” must follow references across multiple resource types. Data pipelines that count “clinical events” must understand the resource decomposition pattern to avoid double-counting or missing related data.

Why Resources Matter

Resources are the vocabulary of FHIR. Every API call, every integration, every validation rule, and every Implementation Guide is built on the resource model. Understanding which resource type carries which data — and how resources reference each other — is the foundation for building or consuming any FHIR-based system.

The modular design means teams can focus on the resource types relevant to their use case without understanding all 160. A lab results integration needs Observation, DiagnosticReport, Patient, and Practitioner. A medication management workflow needs MedicationRequest, MedicationDispense, Patient, and Practitioner. The model is intentionally decomposed so that complexity scales with scope.

Cross-References

  • FHIR — The standard that defines resources and the REST interaction model
  • HL7 — The organization that publishes FHIR
  • Profile — How resource types are constrained for specific contexts
  • Extension — How additional data is attached to resources
  • LOINC — Coding system used in Observation resources for clinical measurements

Last reviewed: February 15, 2026 Definition authority: HL7 International Content status: Canonical reference