2016年1月21日 (四) 12:08的最新版本

1.12.0 Resource Definitions [resources.html#root ]

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.html XML] or [json.html 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:

1.12.0.1 Contents of a Resource [resources.html#content ]

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

• A base set of defined data elements specific to the type
• [extensibility.html Extensions] - additional data elements added by implementations
• A [narrative.html#Narrative human-readable narrative] description of the contents of the resource
• [references.html#contained Contained resources] - additional resources that are part of the identification and transaction space of this resource
• [#metadata Metadata] - important information about the resource that is not part of the content model of the resource
• [extras.html#tags 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 [formats.html Resource Definition Format]):

<[#content [Name]] xmlns="http://hl7.org/fhir">  [formats.html ]
 <[extensibility.html extension]><!-- 0..*  [extensibility.html Extension]   [extensibility.html See Extensions]  --></extension>
 <[extensibility.html modifierExtension]><!-- 0..*  [extensibility.html Extension]   [extensibility.html See Extensions]  --></modifierExtension>
 <[base-definitions.html#Resource.language language] value="[[datatypes.html#code code]]"/><!-- 0..1 Human language of the content (BCP-47) -->
 <[narrative.html#Narrative text]><!-- 0..1 [narrative.html#Narrative Narrative] Text summary of resource content, for human interpretation --></text>
 <[references.html#contained contained]><!-- 0..*  [references.html#contained Resource]   [references.html#contained 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.html#Narrative 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 [resources.html#metadata ]

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

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 [references.html 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.html 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 [services.html Using Resources with Services].

1.12.0.3 Inter-version Compatibility [resources.html#version ]

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 [extras.html#tags 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.html Conformance] and [profile.html 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.html 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.

• [conformance-rules.html Conformance Rules]
• [resources.html Resource Definitions]
• [extras.html Tags, Bundles, Compartments]
• [references.html References between Resources]
• [narrative.html Narratives]
• [formats.html Formats:] [xml.html XML], [json.html JSON]
• [extensibility.html Extensibility] ([extensibility-examples.html Examples])
• [base-definitions.html Formal Definitions]