. Page versions: R5 R4B R4 R3 R2This page is part of the FHIR Specification (v0.11: DSTU 1 Ballot 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2
There are 4 cases where elements inside a resource reference each other:
These references are done using an id/idref based approach, where a source element indicates that it has the same content as the target element. The target element has an attribute "id" which must have a unique value within the resource with regard to any other id attributes. The "id" attribute is not in any namespace. The source element reference must refer to an attribute in the same resource (or, for a CodeableConcept, inside the same datatype).
<example>
<target id="a1">
<child>...</child>
</target>
<-- other stuff -->
<source idref="a1">
</example>
In a single resource, this works like xml:id/idref, but there is an important difference: the uniqueness and resolution scope of these id references is within the resource that contains them. If multiple resources are combined into a single piece of XML, such as an atom feed, duplicate values may occur between resources. This must be managed by applications reading the resources.
Note that all references between the xhtml elements and the data elements must be understood to establish a "derived from" relationship, where the derived content (whether text or data) refers to the source content. Note that this means some references may be forward references (references to elements defined later in the instance).
The defined elements in a resource includes many references to other resources. The resources combine to build a web of information about healthcare.
References are always defined in one particular direction - from one resource (source) to another (target). The corresponding reverse relationship from the target to the source exists in a logical sense, but is not represented explicitly in the resource. Navigating these reverse relationships requires some external infrastructure to track the relationship between resources.
Because resources are processed independently, relationships are not considered to be transitive. For example, if a Condition resource references a particular Patient as its subject, and it links to a Procedure resource as its cause, there is no automatic rule or implication that the procedure has the same patient as its subject. Instead, the subject of the procedure must be established directly in the procedure itself. Another way to state this is that the context of the subject is not "inherited" and it does not "conduct" along the relationship to procedure. The only exception to this in the case of contained resources (see below). Note that in practice, the relationships do need to describe a logical and coherent record.
In a resource, references are represented with a type, a reference, and a text description. The key property of the reference is the reference - resources are identified and addressed by their URL. The actual reference looks like this (see "XML Format" for details of the way resource contents are described):
<[name] xmlns="http://hl7.org/fhir"> <!-- from Element: extension --> <type value="[code]"/><!-- 0..1 Resource Type --> <reference value="[string]"/><!-- 0..1 Relative, internal or absolute URL reference --> <display value="[string]"/><!-- 0..1 Text alternative for the resource --> </[name]>
| Path | Definition | Type | Reference |
|---|---|---|---|
| ResourceReference.type | One of the resource types defined as part of FHIR | Incomplete | http://hl7.org/fhir/resource-types |
Notes:
Constraints
A relative reference to the patient "034AB16" in an element named "context" on a FHIR RESTful server:
<context>
<type value="Patient" />
<reference value="patient/@034AB16" />
</context>
An absolute reference to a resource profile in an element named "profile":
<profile>
<type value="Profile" />
<reference value="http://fhir.hl7.org/svc/profile/@c8973a22-2b5b-4e76-9c66-00639c99e61b" />
</profile>
Note that HL7 has not yet actually created a profile registry, nor decided on a URL for it.
A short display text that provides a human readable identification of the resource may be provided:
<custodian>
<type value="Organization" />
<reference value="organization/@123" />
<display value="HL7, Inc" />
</custodian>
This text can be used by a system that is unable to resolve the reference to an actual resource.
In some circumstances, the content referred to in the resource reference does not have an independent existence apart from the resource that contains it - it cannot be identified independently, and nor can it have its own independent transaction scope. Typically, such circumstances arise where the resource is being assembled by a secondary user of the source data, such as a middleware engine. If the data available when the resource is constructed does not include record keys or absolute identification information, then a properly identified resource cannot be assembled, and even if an arbitrary identification was associated with it, the resource could never be the subject of a transaction outside the context of the resource that refers to it.
In these circumstances, the resource is placed directly in line in the reference. This should never be done when the content can be identified properly, as once identification is lost, it is extremely difficult (and context dependent) to restore it again.
An example of a contained resource:
<Document xmlns="http://hl7.org/fhir">
<extension>...</extension>
<text>...</text>
<contained>
<Organization id="org1">
<!-- whatever information is available -->
</Organization>
</contained>
<information>
<!-- other attributes -->
<custodian>
<type value="Organization" />
<reference value="#org1" />
</custodian>
<!-- other attributes -->
<information>
</Document>
The same example in JSON:
{ "Document" : {
"extension" : { ... },
"text" : { .. },
"contained: [
{"Organization" : {
"_id" : "org1",
.. whatever information is available ...
}}
]
"information: {
... other attributes ...
"custodian" : {
"type" : { "value" : "Organization" },
"url" : { "value" : "#org1" }
}
... other attributes ...
}
}}
The type and url are always required, even though somewhat redundant in this case, to ensure that a single approach to resolving resource references can be used - simply by resolving the URL, and accessing accordingly.
Some notes about use and interpretation of contained resources:
Readers of the resources bundles should always look through the resources in the atom feed when a resource reference is encountered. The resource reference may have the resource type and a relative url, which is the id of the target, like this:
<institution>
<type value="Organization" />
<reference value="organization/@23" />
</institution>
A reader trying to find the resource this institution element identifies should always look through the entries in the atom feed prior to looking anywhere else for the institution. If the feed.id for the resource that contains the link above is http://example.org/, then the absolute URL is http://example.org/organization/@23. If that organization is in the feed, it would look like this:
.. feed ..
<entry>
..
<id>http://example.org/organization/@23<id>
..
<content type="text/xml">
<Organization xmlns="http://hl7.org/fhir">
<!-- Content for the resource -->
</Organization>
</content>
... feed ...
It would also be possible to locate the resource by an absolute url. In this case, the id element contains a direct reference to the location of the resource:
<institution>
<type value="Organization" />
<reference value="http://example.org/organization/@23" />
</institution>
If there is no resource in the atom feed with an appropriate URL, then the application may try accessing the provided URL directly or use some other implementation-specific method for resolving how to find the resource.