This 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
In addition to the basic contents of Resources, and their metadata, each resource can be labelled with one or more "Tags". These tags can be used to associate additional operational information with the Resources, including defining security labels used in access control policies, workflow management, and other uses. Tags are attached to resources, and exchanged with their resource. Tags are never used to keep information that needs to be understood when interpreting the content of a resource; their function is limited to finding and controlling access to the resource.
Each tag has two properties:
| URI : uri | A term that defines the meaning of the tag |
| Label : string | (Optional) A human-readable label for the tag for use when displaying in end-user applications |
The URI may be a reference to a healthcare vocabulary, including ones defined in this specification, such as the basic security label set, or vocabularies such as those defined by HL7 (v2 and v3/CDA), LOINC, or SNOMED-CT. Alternatively, the URI may be one defined by the implementation in the local context. Literal references that refer directly to a description of the tag (typically just an HTML page) are preferred over symbolic references but this is not required.
If the end user application provides functionality to the user that allows the user to affix arbitrary text tags to the resource for their own purpose, the application can automatically construct a URI by appending the mime encoding of the Label to the base URL "http://hl7.org/fhir/tags/text/". When applications processing resources see this base URL, they can automatically know that this is a pure text label with no formal meaning.
Each resource may belong to one or more logical compartments. A compartment is a logical grouping of resources which share a common property. Compartments have two principal roles:
Compartments define how particular instances of the compartment are defined and identified, and how systems know whether resources are in the compartment or not. Here is a list of the compartments defined by this specification:
| Name | Title | Description | Identity | Membership |
| patient | Patient | The set of resources associated with a particular patient | There is an instance of the patient compartment for each patient resource, and the identity of the compartment is the same as the patient. When a patient is linked to another patient, all the records associated with the linked patient are in the compartment associated with the target of the link. | The patient compartment includes any resources where the subject of the resource is the patient, and some other resources that are directly linked to resources in the patient compartment |
As an example of compartment usage, to retrieve a list of a patient's conditions, use the URL:
GET [baseurl]/patient/@[id]/condition
The details of this usage are described under the search operation.
Compartments may be used explicitly, like this, but can also be used implicitly. For instance, if a FHIR server is providing a patient view of a record, the authorised user associated with use of the FHIR RESTful api may be limited to accessing records from the compartment instance(s) logically associated with their identity.
Note that resources may cross between compartments, or interlink them. Examples of this would be where a Diagnostic Report identifies a subject, but an Observation it references identifies a different subject, or where a List resource references items that identify different subjects. Such cross-linking may arise for many valid reasons, including:
Given the wide variety of use cases and contexts in which FHIR is used, compartments do not define how cross-linking is handled. Systems may reject resources, remove them from both compartments, or place them in both, or act in some other fashion.
One common operation performed with resources is to gather a collection of resources into a single instance. In FHIR this is referred to as "bundling" the resources together. The resource bundle is not just a list of references to resources, but includes their whole content. These resource bundles are useful for a variety of different reasons, including:
Conceptually, a bundle has an identifier (url) and a date updated, and a list of resources. For each resource in the list, the bundle has the resource and also its metadata as listed above. Each entry in the bundle retains its original identifier. This means that applications reading the bundle should always look for a resource by its identity (after converting relative URLs absolute URL) in the bundle first before trying to access it by its URL.