FHIR Resources Explained: The Building Blocks of Modern Healthcare Data

FHIR resources are the individual, structured data units that make up the entire FHIR standard, each representing a specific real-world healthcare concept like a patient, an observation, or an encounter, in a consistent JSON or XML format that any FHIR-compliant system can read and understand. Rather than one massive document containing everything about a patient, FHIR breaks clinical data into these discrete, purpose-built resources that reference each other, similar in spirit to how HL7 v2 uses distinct message types for different clinical events.

Below is what a FHIR resource actually contains structurally, the most commonly used resource types in practice, and how resources work together through a RESTful API. If you're planning a FHIR-based integration, our free Mirth Health Check can help scope which specific resources your project actually needs — part of the Mirth Connect support work we do for US healthcare teams.

Every FHIR resource follows a consistent structural pattern regardless of what clinical concept it represents, which is exactly what makes FHIR predictable to work with once you understand that shared underlying structure.

A Unique Identifier and Resource Type

Every resource includes an id uniquely identifying that specific instance, along with a resourceType field declaring what kind of resource it is, whether Patient, Observation, or any of the dozens of other defined types in the specification.

Metadata Tracking Version and Change History

The meta element carries versioning information, including a versionId and lastUpdated timestamp, letting systems track exactly when a resource last changed and supporting conflict detection during concurrent updates.

Core Data Fields Specific to That Resource Type

Beyond the shared structural elements, each resource type defines its own specific fields relevant to what it represents, such as a Patient resource's name and birthDate, or an Observation resource's value and code.

Extensions for Data Outside the Base Specification

FHIR's extension mechanism lets implementers add data elements not covered by the base resource definition, which is common for use cases like US Core profiles adding fields required for specific national implementation guides.

While the FHIR specification defines well over a hundred resource types, most real-world integrations concentrate heavily on a much smaller set that covers the majority of common healthcare data exchange needs.

Patient as the Foundation for Most Clinical Data

The Patient resource anchors most other clinical resources through references, since observations, encounters, and conditions all typically link back to a specific patient, making it usually the first resource any integration needs to handle correctly. See our FHIR Patient resource guide for the details.

Observation for Labs, Vitals, and Assessments

Observation covers an enormously wide range of measured or assessed data, from lab results to vital signs to clinical assessments, using a coded value system like LOINC to identify precisely what was measured. See our FHIR Observation resource guide for more.

Encounter for Visits and Care Episodes

Encounter represents a specific interaction between a patient and the healthcare system, whether an inpatient stay, an outpatient visit, or an emergency department encounter, providing context for other resources tied to that visit.

Condition, MedicationRequest, and AllergyIntolerance

These three resources cover diagnoses, prescribed medications, and documented allergies respectively, forming the core of what most clinical summary or decision support use cases actually need to function correctly.

FHIR resources aren't isolated data blobs — they're designed to be created, read, updated, and searched through a standard RESTful API pattern that any FHIR-compliant server implements consistently.

Standard CRUD Operations Across Every Resource Type

FHIR defines consistent create, read, update, and delete operations that work the same way across every resource type, meaning learning the pattern once for Patient largely transfers directly to working with Observation or Encounter.

References Linking Resources Together

Resources reference each other by id rather than duplicating data, so an Observation references its subject Patient rather than embedding that patient's full demographic record inside every single observation resource created.

Bundles for Grouping Multiple Resources Together

A Bundle resource groups multiple individual resources together for transactions, search results, or batch operations, letting a single API call return or submit several related resources in one coordinated request.

Search Parameters for Finding Specific Resources

Each resource type defines its own set of search parameters, letting API consumers query for exactly the resources they need, such as finding all Observations for a specific patient within a defined date range.

Scoping which resources a project actually needs, versus what a vendor's full FHIR surface theoretically offers, is where most projects waste early time. Our free Mirth Connect health check can help scope that as part of the standard diagnostic.

Book a Free Health Check →

Troubleshooting something specific? Send us the log, or check pricing for our support plans.