The Missing Layer in Healthcare Data Exchange
All articles
FHIR

FHIR R4 in plain terms: resources, references, and why bundles matter

FHIR made healthcare data addressable. Resources, references, and bundles are most of what you need to work with it.

Curiflow·June 22, 2026·5 min read

FHIR, pronounced "fire," stands for Fast Healthcare Interoperability Resources. Where C-CDA is a whole document, FHIR breaks a record into small, addressable pieces you can request one at a time. That single idea is most of what makes it useful.

Resources

Each piece is a resource: a Patient, a Condition, an Observation, a MedicationStatement, an Encounter. Every resource has a defined shape, so a Condition from one system has the same fields as a Condition from another. Coded fields carry a system, a code, and a human display, so the value is unambiguous.

Example: a Condition resource

The same type 2 diabetes diagnosis from the C-CDA piece, as a FHIR R4 Condition, coded and linked to its patient and encounter.

{
  "resourceType": "Condition",
  "id": "cond-8842",
  "clinicalStatus": { "coding": [{ "code": "active" }] },
  "code": {
    "coding": [{
      "system": "http://hl7.org/fhir/sid/icd-10-cm",
      "code": "E11.22",
      "display": "Type 2 diabetes with chronic kidney disease"
    }]
  },
  "subject":   { "reference": "Patient/8842" },
  "encounter": { "reference": "Encounter/enc-9817" }
}

Notice the diagnosis is already coded to E11.22, the value a C-CDA would have made you derive.

References

Look at subject and encounter above. Resources link to each other with references like Patient/8842. A Condition points to the Patient it belongs to; an Observation points to the Encounter it was taken in. Follow the references and you can reconstruct the whole picture without cramming everything into one file, and you never repeat the patient's details on every record.

R4, and why the version matters

FHIR has gone through several versions; R4 is the first "normative" release and the one payers, vendors, and regulators standardized on, usually with the US Core profiles layered on top to say which fields are required. When someone says "FHIR" in production today, they almost always mean R4.

Bundles

A Bundle packages related resources together so they can travel as a unit, for example every resource that makes up a single encounter.

{
  "resourceType": "Bundle",
  "type": "collection",
  "entry": [
    { "resource": { "resourceType": "Patient",     "id": "8842" } },
    { "resource": { "resourceType": "Encounter",   "id": "enc-9817" } },
    { "resource": { "resourceType": "Condition",   "id": "cond-8842" } },
    { "resource": { "resourceType": "Observation", "id": "obs-egfr" } }
  ]
}

That is how you hand an agent a complete, self-consistent slice of a record in one call, the patient, the encounter, and every finding, already linked by reference.

FHIR gives you the shape. It does not give you the content, you still have to get the codes right.

That last point is the one teams underestimate. FHIR standardizes how data is structured, not whether the values in it are correct. Curiflow serves FHIR R4 bundles where every Condition, Observation, and Medication is coded, MEAT-validated, and cited to its exact source span, so the resources your agents call are not just well-shaped, they are defensible.

Convert anything to FHIR.

NHance turns eFaxes, PDFs, CCDA, and CSVs into clean, structured, FHIR-ready data in under 3 minutes, not 3 months. HIPAA and SOC 2 compliant.