This page is part of the FHIR Specification (v0.0.82: DSTU 1). 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 identifying bundles, workflow management and claiming that resources conform to profiles. Tags are attached to resources and exchanged with the 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, and connecting resources to technical or clinical workflow.
Each tag has three properties:
| Scheme : uri | A uri that identifies the type of the tag |
| Term : uri | An absolute URI which 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 following tag schemes are defined:
| http://hl7.org/fhir/tag | A general tag |
| http://hl7.org/fhir/tag/profile | A profile tag - a claim that the Resource conforms to the profile identified in the term |
| http://hl7.org/fhir/tag/security | A security label |
In a general tag, the term may be a reference to a healthcare vocabulary, including ones defined in this specification, and vocabularies such as those defined by HL7 (v2 and v3/CDA), LOINC, or SNOMED CT. Alternatively, the term 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 term by appending the Url encoded Label to the base URL "http://hl7.org/fhir/tag/text/". When applications processing resources see this base URL, they can automatically know that this is a pure text label with no formal meaning.
Known General TagsThis table summarizes the tags that are defined as part of this specification:
| Term | Context | Description |
| http://hl7.org/fhir/tag/document | A bundle (feed.category) | Identifies that this bundle represents a document |
| http://hl7.org/fhir/tag/message | A bundle (feed.category) | Identifies that this bundle represents a message |
A profile tag is an assertion that the resource conforms to a particular Profile, which are sets of rules about what content is allowed to be in a resource. In a profile tag, the term is a URL that references a profile resource.
It's always possible to determine whether a resource conforms to a profile simply by testing it against the profile (the validation tools provide the functionality to perform this test in a variety of contexts). However there are several circumstances where simply examining whether a resource conforms to a particular profile as needed is impractical:
In addition, a validation application (see RESTful validation) needs a way for the client to inform it that it wants the resource tested against as a particular profile.
Profile Tags serve these use cases - a client/creator of a resource can tag the resource with an assertion that the resource conforms to a profile. The server/receiver of the resource can choose to take this assertion at face value, or to assist in locating the profile against which to validate the resource.
Note: resources can conform to multiple profiles at once. A resource can conform to a profile without ever being labelled that it does, or a resource may falsely claim to conform to a profile. For this reason, applications processing resources SHOULD always depend on the contents of the resource when processing them, and/or check resources against profiles directly rather than relying on profile tags. Profile Tags are provided as a method of finding resources that conform to a particular profile, not statements of meaning about the resource.
References to tags in other parts of the specification:
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:
Compartment definitions describe how particular compartment instances are named and identified, and how systems know which resources are in the compartment. The following compartments are 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. As a search related operation, the assignment of resources to compartments is only based on the current version of any of the resources involved. Note that contained patient resources cannot create a patient compartment of their own.
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 authorized 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. Irrespective of whether compartments are being used explicitly or implicitly, servers will need to make arrangements to make some resources with no direct link to a patient available to the client (medications, substances, etc.).
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 with containing context. In FHIR this is referred to as "bundling" the resources together. The resource bundle mostly includes the whole content of a resource, not just their metadata and their reference. These resource bundles are useful for a variety of different reasons, including:
The content of bundled resources SHALL always be present except in the special case of a transaction response.
Conceptually, a bundle has an identifier (url) and a date updated, and a list of resources, each of which has its metadata as listed above. Also, both the bundle and each resource have a set of named links, and may have additional Tags that indicate what use the bundle has.
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.
In XML, a bundle is represented as an Atom Feed, and in JSON, a custom format is defined.
There are situations where it is useful or required to handle pure binary content using the same framework as other resources. Typically, this is when the binary content is referred to from other FHIR Resources. Using the same framework means that the existing servers, security arrangements, code libraries etc. can handle additional related content. Typically, Binary resources are used for handling content such as:
A binary resource can contain any content, whether text, image, pdf, zip archive, etc. These resources are served in their native form on the rest interface, but can also be represented in XML or JSON, such as when including these resources in a bundle (used when it is convenient to include these in the feed directly rather than leaving them by reference).
References:
© HL7.org 2011+. FHIR DSTU (v0.0.82.2943) generated on Tue, Sep 30, 2014 18:10+1000.
Links:
What's a DSTU? |
Version History |
|
Propose a change