FHIR Resources Explained: Structure, Categories and Key Resources

In FHIR, everything exchanged is a resource: a patient, a blood pressure reading, a prescription, an insurance claim, even the description of what a server can do. Each resource type has a published definition listing its elements, their data types, cardinality and meaning. Resources can be serialized as JSON, XML or RDF, and on a RESTful server each instance has its own URL such as [base]/Patient/123.

The design goal is reuse. Rather than defining a new message for every workflow, FHIR provides a library of granular, composable resources that cover the common 80 percent of each concept and leave the remainder to extensions. If you are new to the standard, start with what FHIR is and then come back here for the details.

Every resource shares a common skeleton inherited from the base Resource and DomainResource definitions:

• resourceType names the type, e.g. Observation. In JSON it is always present.
• id is the logical id assigned by the server holding the resource. It is local to that server, not a business identifier.
• meta carries technical metadata: versionId, lastUpdated, the profiles the resource claims to conform to, security labels and tags.
• text is a human-readable XHTML narrative so that a person can read the resource even if their system does not understand every element.
• extension and modifierExtension hold data the base definition does not cover. Modifier extensions change the meaning of the resource and cannot be safely ignored.
• identifier (on most resources) holds business identifiers such as a medical record number, with a system URI that says who issued it.

Below the shared skeleton, each resource defines its own elements. Data types are reused everywhere: CodeableConcept for coded values, Quantity for measured amounts, Reference for links, Period for date ranges, and so on. Learning the dozen most common data types pays off more than memorising individual resources.

The Observation below records a body weight measurement. It uses a LOINC code, a UCUM unit, and a reference to the subject Patient. The status and code elements are required by the base specification.

{
  "resourceType": "Observation",
  "id": "weight-example",
  "meta": {
    "lastUpdated": "2026-11-01T09:30:00Z"
  },
  "status": "final",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/observation-category",
          "code": "vital-signs",
          "display": "Vital Signs"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "29463-7",
        "display": "Body weight"
      }
    ]
  },
  "subject": {
    "reference": "Patient/example"
  },
  "effectiveDateTime": "2026-11-01T09:15:00Z",
  "valueQuantity": {
    "value": 72.5,
    "unit": "kg",
    "system": "http://unitsofmeasure.org",
    "code": "kg"
  }
}

The FHIR resource list groups types into five levels, which roughly reflect how foundational they are:

• Patient: demographics and identifiers. Nearly every clinical resource points to one.
• Practitioner and PractitionerRole: the individual clinician, and the role they play at a specific organization or location.
• Encounter: an interaction between a patient and provider, such as an outpatient visit or inpatient stay. It gives clinical data its context.
• Observation: measurements and simple assertions, from vital signs and lab results to smoking status. It is the most heavily used clinical resource.
• Condition: problems, diagnoses and health concerns.
• AllergyIntolerance: allergies and intolerances, with criticality and reactions.
• MedicationRequest: an order or prescription for a medication, distinct from MedicationStatement (what the patient reports taking) and MedicationAdministration (what was actually given).
• DiagnosticReport: the report for a set of tests, such as a lab panel or imaging study, grouping result Observations and any conclusion.
• Bundle: a container for a collection of resources, used for search results, transactions, messages and documents.

When planning an API integration, list the resources each use case needs and check them against the target EHR's CapabilityStatement; support varies by vendor and by version.

Resources rarely stand alone. An Observation references its Patient and Encounter; a DiagnosticReport references its result Observations; a MedicationRequest references its requester. The Reference data type can hold a relative URL (Patient/123), an absolute URL to another server, a logical identifier, or an internal pointer to a contained resource.

• Relative references resolve against the server's base URL and are the most common form.
• Contained resources are embedded within a parent and have no independent identity; use them only when the referenced data cannot exist on its own.
• Search parameters such as _include and _revinclude let clients fetch referenced resources in one request instead of many round trips.
• When aggregating data from several systems, references often have to be rewritten. Plan for this in any interoperability design.

Each resource type gets the same set of RESTful interactions: read and vread by id and version, create, update, patch and delete, history, and search. That uniformity is one of FHIR's biggest practical advantages. Once a developer has retrieved Patients, retrieving Conditions or AllergyIntolerances is the same pattern with a different type name and a different set of search parameters.

GET /fhir/Observation?patient=example&category=laboratory&date=ge2026-01-01&_sort=-date&_count=50 HTTP/1.1
Host: fhir.example.org
Accept: application/fhir+json

Search parameters are defined per resource type, and servers declare which they support in their CapabilityStatement. Results come back in a Bundle with paging links, so clients should always follow the next link rather than assuming one page holds everything. Operations, invoked with a $ prefix such as Patient/$everything or ValueSet/$expand, cover behaviour that does not fit simple create, read, update and delete.

• Fetch the server's CapabilityStatement (GET [base]/metadata) before building against it; it is the authoritative list of supported resources, interactions and search parameters.
• Expect OperationOutcome resources on errors. They carry structured issue codes and are far more useful than HTTP status codes alone.
• Treat narrative text as display-only. Systems should compute on structured elements, not parse the XHTML.

Each resource carries a FHIR Maturity Model (FMM) level from 0 (draft) to 5 (widely implemented and stable), or the status Normative. In R4, a core set of content, including Patient, Observation, Bundle, StructureDefinition and the RESTful API, was the first to become normative, meaning future versions commit to backward compatibility for it. Lower-maturity resources can still change significantly between releases, which matters when you choose a FHIR version.

Base resources are intentionally broad. Profiles narrow them for a specific context: making elements required, binding codes to specific value sets, and defining extensions. Profiles are published in implementation guides, for example US Core for US clinical data and the International Patient Summary for cross-border summaries. A resource declares conformance in meta.profile, and validators can check it against the profile's StructureDefinition.