Technical specialist lab · Module 1 · 50 min
Reading FHIR: Resources, JSON & References
Read a FHIR resource as a modelled clinical object rather than arbitrary JSON: ids versus business identifiers, references between resources, searchset Bundles, and the version question you ask before any integration.
After this module you can
Open a FHIR payload from an unfamiliar system and read it structurally: what each resource is, how it identifies itself, what it points at, and what is still missing before it can become model input.
- Read a FHIR JSON resource as a modelled object, not arbitrary JSON
- Distinguish a resource id, a business identifier and a Reference
- Recognise common Patient, Observation, Condition and Encounter fields
- Follow references between resources to assemble patient context
- Explain what a searchset Bundle represents
- Ask which FHIR version, profiles and implementation guide a system supports
Querying for these resources over a FHIR API is planned for Module 2, which is not yet released. Here you learn to read what comes back.
Step 1
“We have FHIR”
An AI team is told the hospital's platform is FHIR-enabled, so integration is solved. Six weeks later the model still cannot be given a usable input: the endpoint returns hundreds of Observations with no clinical grouping, the HbA1c results carry two different codings, half the Conditions have no onset date, and nobody can say which encounter a value belongs to.
What FHIR gives you
A shared resource model, defined data types, stable field semantics, references between resources, and an interoperable exchange format. Two systems can talk about a blood pressure the same way.
What it does not give you
Task relevance, a curated cohort, guaranteed completeness, consistent local coding, or an AI-ready feature table. A conformant server can still return data that is unusable for your specific question.
Version reality check
- FHIR R5 (5.0.0) is the current published core release of the specification.
- Many production deployments still run R4 or R4B. SMART App Launch 2.2 is published against R4.
- R6 is a ballot/development sequence, not the production baseline you should assume.
- Examples in this module use stable, R4-compatible shapes that are familiar in production systems.
- Before integrating, inspect the target server's CapabilityStatement and the implementation guide it claims to conform to. Never assume a version, a profile or an extension is supported.
REST is the most common way to interact with a FHIR server, but it is not the only one. FHIR also defines messaging, documents and operations, and resources are routinely exchanged as files or bulk exports. Treat FHIR as a resource model plus exchange framework, not as “an API style”.
Imaging mostly lives outside these resources: pixel data is DICOM, exchanged over DICOMweb, with FHIR ImagingStudy acting as the pointer. Treated here as an adjacent standard only.
0 of 6 steps complete
Sources & evidence · 6 sources
This module cites standards and specifications.
Content reviewed: September 2026. Publication dates of the individual sources are shown in each citation.
HL7 FHIR R5 (v5.0.0, STU) — current published specification
The core specification. R5 (v5.0.0, STU) is the current published release; R4 and R4B remain in production use — verify the release implemented by the local system. Release-pinned; checked 10 September 2026.
Open sourceHL7 FHIR — directory of published versions
Which sequences exist, what is published, and what is still in ballot.
Open sourceHL7 FHIR — Resource: Patient
Field definitions, cardinality and the identifier element.
Open sourceHL7 FHIR — Resource: Observation
code, status, effective[x] and the polymorphic value[x].
Open sourceHL7 FHIR — Resource: Bundle
Bundle types, entries and search mode.
Open sourceHL7 FHIR — References between resources
Relative, absolute, contained and logical references.
Open source