FHIR Resources are the core building blocks of the FHIR standard. Each resource represents a specific piece of healthcare information, such as a patient, a clinical observation, or an encounter. Together, resources define how healthcare data is structured, linked, and exchanged across systems.
Understanding FHIR Resources is essential because they form the foundation for every API call, profile, and data model built in FHIR. Whether data is being viewed through an app, exchanged between systems, or transformed inside an integration engine like Iguana, it all begins with resources.
A resource is a small, self-contained data structure that describes one concept in healthcare.
For example, the Patient resource describes an individual receiving care, while the Observation resource captures a lab result, and the Encounter resource records a visit or admission.
This modular design makes FHIR flexible, predictable, and reusable across many systems and use cases.
For a complete list of all FHIR resources, visit the:
Official HL7 resource index: HL7 FHIR Resource List (R4B)
Although there are more than 150 official FHIR resource types, each follows the same basic structure. This consistency allows developers and analysts to work with FHIR data without having to learn new formats for each type.
A typical FHIR resource contains:
| Element | Description |
|---|---|
| resourceType | Identifies the type of resource (for example, 'Patient' or 'Observation') |
| id | A unique identifier for the resource |
| meta | Metadata such as version and timestamps |
| text | A human-readable narrative summary |
| fields | The domain-specific data elements for that resource |
| extension | Optional fields that extend or customize the resource |
Example of a simple Patient resource in JSON:
{
"resourceType": "Patient",
"id": "12345",
"name": [
{
"family": "Doe",
"given": ["Jane"]
}
],
"gender": "female",
"birthDate": "1990-05-02"
}
FHIR is designed around the idea that healthcare data is interconnected. Instead of combining everything into one file, FHIR uses references between resources to represent relationships.
For example:
This creates a network of information that mirrors how care happens in the real world. It also allows applications to retrieve only the data they need, improving performance and clarity.
FHIR Resources are grouped into logical categories, each covering a different area of healthcare data.
| Category | Description | Example Resources |
|---|---|---|
| Clinical | Records of care, findings, and outcomes | Patient, Observation, Encounter, Condition |
| Administrative | Information about organizations, people, and workflow | Practitioner, Organization, Location, Schedule |
| Financial | Billing, insurance, and payment details | Claim, Invoice, Coverage |
| Infrastructure | Technical resources that support data exchange | Bundle, OperationOutcome, Parameters |
| Conformance | Definitions that govern how systems behave | StructureDefinition, CapabilityStatement |
These categories allow FHIR to cover both patient-level data and system-level configuration in one unified framework.
FHIR Resources are standardized, but healthcare data often varies by region, organization, or workflow. To handle this, FHIR provides two customization mechanisms:
Together, Profiles and Extensions ensure that FHIR remains both universal and adaptable.
Learn more: FHIR Profiles and Extensions →
Not all FHIR resources are at the same level of stability or adoption. Each one is assigned a FHIR Maturity Model (FMM) level, ranging from 0 (draft) to 5 (normative).
| Level | Meaning |
|---|---|
| 0 | Draft or experimental; subject to significant change |
| 1–2 | Under active development; used in limited implementations |
| 3–4 | Tested and implemented by multiple systems; relatively stable |
| 5 | Normative; part of the official FHIR standard and expected to remain compatible across versions |
High-maturity resources, such as Patient and Observation, are widely implemented and considered stable. Lower-maturity resources may still evolve as the standard grows.
Understanding maturity helps organizations decide which resources to adopt and how aggressively to implement new ones.
FHIR resources must follow specific structure definitions and constraints. Validation ensures that a resource instance conforms to the rules of the base FHIR standard or to a defined profile.
For developers and analysts, online tools such as the FHIR Validator can check whether a resource meets these requirements. Validation is useful during development to confirm that generated data is properly structured and ready for exchange.
Within Iguana, validation is supported as part of the FHIR Profiling Tool and FHIR Resource Creator workflows:
These features make it easier to maintain FHIR compliance during integration and transformation projects.
While there are many resource types, a few are used far more frequently in real-world integrations. These include:
These resources are the foundation of most clinical data exchanges and will be covered in more detail on the following pages.
In production environments, working with FHIR resources often involves mapping, validating, or generating data across multiple systems. Iguana simplifies this process by enabling teams to:
These capabilities help healthcare organizations manage hybrid workflows where HL7, FHIR, and API-based systems coexist.
Now that you understand what FHIR Resources are and how they work, you can explore some of the most common examples used in healthcare systems today.
