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

1.12.0 Resource Definitions

This specification defines a series of different types of resource that can be used to exchange and/or store data in order to solve a wide range of healthcare related problems, both clinical and administrative. In addition, this specification defines several different ways of exchanging the resources.

A resource is an entity that:

has a known identity (a url) by which it can be addressed
identifies itself as one of the types of resource defined in this specification
contains a set of structured data items as described by the definition of the resource type
contains a human-readable XHTML representation of the content of the resource
has an identified version that changes if the contents of the resource change

Resources have multiple representations. A resource is valid if it meets the above rules, and is represented in either XML or JSON according to the rules defined in this specification. Other representations are allowed, but are not described by this specification.

1.12.0.0.1 Definitions

Basic definitions for this page:

Resource

An instance of data that is stored or exchanged

Resource Definition

Defines the data elements that are part of the resource

Profile

Additional rules about the data elements for a particular context of use. There's a specific type of resource - the Profile Resource that is used to represent a profile

1.12.0.1 Contents of a Resource

All types of resources have the following optional or mandatory elements and properties:

A base set of defined data elements specific to the type
Extensions - additional data elements added by implementations
A human-readable narrative description of the contents of the resource
Contained resources - additional resources that are part of the identification and transaction space of this resource
Metadata - important information about the resource that is not part of the content model of the resource
Tags - labels affixed to the resources that may be used to define additional operational behavior such as security, workflow, etc.

Every resource starts with a common set of elements (for documentation of this format, see Resource Definition Format):

<[Name] xmlns="http://hl7.org/fhir">  
 <extension><!-- 0..*  Extension   See Extensions  --></extension>
 <modifierExtension><!-- 0..*  Extension   See Extensions  --></modifierExtension>
 <language value="[code]"/><!-- 0..1 Human language of the content (BCP-47) -->
 <text><!-- 0..1 Narrative Text summary of resource content, for human interpretation --></text>
 <contained><!-- 0..*  Resource   Contained Resources  --></contained>
 <!-- Defined Data Elements for Resource -->
</[Name]>

These elements SHALL always appear in this order. These basic elements shared by all resources come first in order to support consistent definitions for schema and UML derived code.

The optional language element specifies the base language of the resource using the codes defined in BCP 47. Note that not all the content of the resource has to be in the language. If a language is specified, it should also be specified on the Narrative Text. There is no default language, though one may be inferred from the context of use.

The language element is provided to support indexing and accessibility (e.g. text-to-speech use the language tag). The html language tag in the narrative is used when processing the narrative. The language tag on the resource is provided for use to specify the language of alternate presentations generated from the data in the resource

1.12.0.2 Resource Metadata

The metadata properties are key aspects of a resource and how it behaves. For implementation reasons, these are represented outside the resource:

Metadata Item	Type	Usage
Logical Id	id	A simple string that provides the logical identity of the resource. It is unique within the space of all resources of the same type on the same server. It is constant for the entire lifetime of the resource on the server.
Version Id	id	Changes each time the content of the resource changes. Can be referenced in a resource reference. Can be used to ensure that updates are based on the latest version of the resource. The version can be globally unique, or scoped by the Logical Id. Version identifiers are generally either a serially incrementing id scoped by the logical id, or a uuid, though neither of these approaches is required
Last Modified Date	instant	Changes each time the content of the resource changes. Can be used by a system or a human to judge the currency of the resource content.

Metadata Item

Type

Usage

Logical Id

A simple string that provides the logical identity of the resource. It is unique within the space of all resources of the same type on the same server. It is constant for the entire lifetime of the resource on the server.

Version Id

Changes each time the content of the resource changes. Can be referenced in a resource reference. Can be used to ensure that updates are based on the latest version of the resource.
The version can be globally unique, or scoped by the Logical Id. Version identifiers are generally either a serially incrementing id scoped by the logical id, or a uuid, though neither of these approaches is required

Last Modified Date

instant

Changes each time the content of the resource changes. Can be used by a system or a human to judge the currency of the resource content.

Logical and Version ids are case sensitive. Ids are always opaque, and systems need not and should not attempt to determine their internal structure. An id SHALL always be represented in the same way in resource references and URLs. Ids can be up to 36 characters long, and contain any combination of lowercase ASCII letters, numerals, "-" and ".".

Note: these data elements are represented outside the resource because:

They are almost always explicit in the envelope that carries the exchange content, and in particular they are in the http and atom headers
They will change as resources are managed, moved, or replicated, even when the content itself does not (though changing the logical id of a resource may require changing the content of other resources that reference it)

The full identity of a resource is an absolute URL constructed from the server address at which it is found, the resource type, and the Logical Id, such as http://test.fhir.org/rest/Patient/123 (where 123 is the Logical Id). Note that implementations SHOULD NOT assume that the identity of a resource is always resolvable to a literal server - it may be temporarily unavailable, or not available by policy (e.g. firewalls) or in some cases, it may not actually exist (e.g. use of resource outside a RESTful environment). Resources reference each other by their identity. These references are allowed to be absolute or relative (see Resource References for further discussion). Copying or moving resources from one server to another means that resources acquire a new identity. For further details, see Managing Resource Identity

Both the Version Id and the Last Modified Date change any time the resource changes. The Version Id is more useful for managing concurrency issues and version specific references because of the inherent uncertainties and precision limits associated with date/times. The Last Modified Date is useful for a human to ascertain the logical currency of the information in the resource.

In any environment where the resources are used, the technical details of how these metadata elements are represented during exchange will need to be resolved. For further details, see Using Resources with Services.

1.12.0.3 Inter-version Compatibility

The following rules will apply once the specification becomes a full normative specification. These rules ensure that implementations may process the content of the resources safely while exchanging data between applications using different versions of FHIR. However during the period of trial use of the specification, HL7 may make changes outside the limitations described here in response to discovered issues in the specification. Applications may wish to use resource tags to help manage this during the period of trial use.

There is no explicit version marker in the resource content. Once normative, subsequent versions of this specification may introduce new elements and/or content at any point in the resource contents, but the path and meaning of existing data elements will not be changed. Any value set or code list may be revised to include additional codes.

Each binding to a value set or code system indicates whether the value list automatically grows as new codes are defined, whether the list may be extended in future versions of the specification, or whether the list cannot be changed at all in future versions.

The conformance layer (Conformance and Profile) has mandatory properties declaring the FHIR specification version, and these may be used to determine which version of FHIR an implementation is using.

In a typical scenario, mixed versions may need to exist, so applications SHOULD ignore elements that they do not recognize unless they are modifierExtensions. However, in a healthcare context, many application vendors are unwilling to consider this approach because of concerns about clinical risk or technical limitations in their software (i.e. schema based processing). Applications are not required to ignore unknown elements, but SHALL declare whether they will do so in their conformance statements.

Additional discussion on inter-versioning issues can be found here: http://wiki.hl7.org/index.php?title=FHIR_interversion_compatibility.

1.12.0.3.1 Further Information

Additional documentation.