Resource References — One of the core building blocks of FHIR

Resources don’t exist in isolation. The true power of FHIR lies in the links between resources that combined paint a complex picture of a patient’s journey over time.

A Patient enters a hospital, is diagnosed with an illness by a doctor, leading to a scan followed by a procedure. A simple chain of events that most people encounter at some point in their lives.

In FHIR this will typically be represented by a host of inter-connected resources: Patient, Encounter, Organization, Observation, ServiceRequest, ImagingStudy, DiagnosticReport, Procedure, etc.

Each of these resources will be linked to each other via a spider web of connections — all with the patient at the centre.

These connections are made via Resource References, which typically look like this.

~ Relative URL: Patient/7480947
~ Absolute URL:
~ Logical URI: urn:uuid:a9ba7c98-9ab3-4a25-b894-73dda76eed3d

Here’s what an initial Encounter looks like for the above Patient, filled with Resource References that link to the doctor, to her own patient record and to the hospital she visited.

Every developer working with FHIR needs to understand Resource References, the different forms they can take, and how they can be resolved.

More about Resource References here:

But as with so much of FHIR, it’s not always that simple.

While most references to resources follow one of the structures shown above, there are also logical references inside contained resources, Identifiers as resource references that cannot always be resolved, and canonical references — all of which work and behave a little differently.

[Sample data generated by Syntea and hosted by Mitre:]



Sign up to “The Tuesday FHIR Sessions” and receive an email every Tuesday where I go deep on a single FHIR topic.