. Page versions: R5 R4B R4 R3 R2This page is part of the FHIR Specification (v0.06: DSTU 1 Ballot 2). 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
A resource is an entity that:
Resources have multiple representations. A resource is valid if it meets that 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.
This page documents how the content of the resources are described and controlled.
To provide a visual sense of what the end resource instances will look like, all resources are described using a pseudo-XML syntax. The syntax uses the following notation:
<name xmlns="http://hl7.org/fhir" [xml:lang]>
<nameA><!-- 1..1 type description of content --><nameA>
<nameB><!-- 0..1 type description --></nameB>
<nameC> <!-- 1..* -->
<nameD ><!-- 1..1 type>Relevant records --></nameD>
</nameC>
<name>
Notes:
When represented as XML, resources may be validated by schema and schemas are provided, but operational systems are not required to do so (though the XML must always be valid against this specification and the schema and Schematron). In addition to the simple XML description, W3C Schema, UML models, and other definitional models are provided that may be a useful aid for system implementation. Resources may also be represented using JSON.
All resources contain extensions and then a narrative section at the end:
<[Name] xmlns="http://hl7.org/fhir"> <!-- Defined Content for Resource --> <extension><!-- 0..* Extension See Extensions --></extension> <text><!-- 1..1 Narrative Text summary of [x], for human interpretation --></text> </[Name]>
The use of the extensions element is discussed under "Extensibility". The text ("Narrative") is discussed below.
In addition to these data elements, there are several pieces of metadata about a resource that are not part of the resource content, but are delegated to the infrastructure:
| Metadata Item | Type | Usage |
|---|---|---|
| Logical Id | id | The identity of the resource. Resources always have a known identity except in the case where a new resource is being submitted to a server to assign a resource to it. Resource identification is discussed further below |
| Version Id | id | Changed each time the content of the resource changes. Can be referenced in a resource reference (see below). 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. Since version ids must be unique, they 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 | dateTime | Changed 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. |
In any environment where the resources are used, the technical details of how these metadata elements are represented will need to be resolved. For further details, see Implementation Details, which also contains a discussion of how resource identity is maintained.
The logical id and version id of a Resource are of type id which is up to 36 characters long and contains:
| A whole number in the range 0 to 2^64-1. May be represented in hexadecimal | |
| A uuid (guid) (in lowercase, without wrapping with the characters "{}[]" which sometimes occur) | |
| An ISO OID | |
| Any other combination of letters, numerals, "-" and "." | |
Resource ids are case sensitive. Ids are always opaque, and systems need not and should not attempt to determine their internal structure. However the id is represented, it must always be represented in the same way in resource references and URLs.
Every resource SHALL include a human readable narrative that contains a summary of the resource, and may be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative. Resources may define what content should be represented in the narrative to ensure clinical safety.
The narrative for a resource is allowed to contain additional information that is not in the structured data, including human-edited content. Such additional information must be in the scope of the definition of the resource. In small, closed trading partner environments, there may be no need for a narrative text. In such cases, implementations are allowed to populate the narrative with text equivalent to "No human readable text provided for this resource" (other languages are allowed). Implementers should note that small, closed trading partner environments are very likely to open up during the lifetime of the resources they define.
The narrative is an xhtml fragment that also includes images if appropriate:
<[name] xmlns="http://hl7.org/fhir"> <status><!-- 1..1 code generated | extensions | additional --></status> <div xmlns="http://www.w3.org/1999/xhtml"> <!-- Limited xhtml content< --> </div> <image> <!-- 0..* Images referenced in xhtml --> <mimeType><!-- 1..1 code Mime type of image --></mimeType> <content><!-- 1..1 base64Binary base64 image data --></content> </image> </[name]>
Terminology Bindings
| Path | Details | Strength |
|---|---|---|
| Narrative.status | The status of a resource narrative (see http://hl7.org/fhir/narrative-status for values) | complete/required |
| Narrative.image.mimeType | see BCP 13 (RFCs 2045, 2046, 2047, 4288, 4289 and 2049) | complete/required |
The contents of the div element are an XHTML fragment containing only the basic html formatting elements described in chapters 7-11 (except section 4 of chapter 9) and 15 of the HTML 4.0 standard, <a> elements (either name or href), images and internally contained style attributes. The XHTML content must not contain a head, a body element, external stylesheet references, scripts, forms, base/link/xlink, frames, iframes, and objects. The div element must have some non-whitespace content.
<narrative>
<div xmlns="http://www.w3.org/1999/xhtml">This is a simple
example with only plain text</div>
</narrative>
<narrative>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>
This is an <i>example</i> with some <b>xhtml</b> formatting.
</p>
</div>
<narrative>
The image source may be a local reference within the resource:
<img src="#a5"/>
This is an internal reference to an id attribute on an element in the same resource, either in the image attachments on the text element directly, or an element of type "Attachment".
<narrative>
<html xmlns="http://www.w3.org/1999/xhtml">
<p>
<img src="#a1/>.
</p>
</html>
<image id="a1">
<mimeType>image/png</mimeType>
<data>MEKH....SD/Z</data>
</image>
<narrative>
Since the presence of images that are not part of the resource is not guaranteed, images that are an essential part of the narrative should always be embedded.
Note: the XHTML is contained in general XML, and there is no support for HTML entities like or © etc. Unicode characters should be used instead. Note that   substitutes for .
The XHTML fragment in the narrative may be styled using CSS in the normal fashion, using a mix of classes, ids and in-line style elements. Specific CSS stylesheets will be applied to the XHTML when it is extracted from the resource to be displayed to a human to create the presentation desired in the context of use. Authors may fix the following styling aspects of the content:
These style properties are specified in-line using the style attribute. If an equivalent html element exists, such as "i", or "pre", it may be used instead, but note that some of these elements are deprecated in HTML 4 and must not be used in Narrative XHTML (including "u", and "font").
Rendering systems are required to respect any of these rendering styles when they are specified in the XHTML, though appropriate interpretation is allowed (e.g. a low-contrast display for dark room contexts may adjust colors accordingly).
Authors are allowed to specify additional styles and style properties as specified in the CSS specification, but these are extensions to this specification and renderers are not required to honor them. Note, however, the additional rules around styling that apply in the context of documents.
Note: styles in resources can make use of the styles defined in the standard FHIR stylesheet, which lives here: http://hl7.org/implement/standards/fhir/fhir.css. Since this stylesheet is not referred to directly, rendering systems may take their own copy if they wish. Authoring systems should not depend on these styles being defined for clinical content.
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 has no content (text or children elements) and just a single attribute named "idref". The value of the idref attribute must match the value of an id attribute in the same resource (or, for a CodeableConcept, inside the same datatype).
<example>
<target id="a1">
<child>content</child>
</target>
<-- other stuff -->
<source idref="a1">
</example>
In a single resource, this works exactly 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.
The "Resource" type indicates a reference from one resource to another.
<[name] xmlns="http://hl7.org/fhir"> <type><!-- 0..1 code Resource Type --></type> <id><!-- 0..1 uri URL/Id of the reference --></id> <version><!-- 0..1 uri Specific version URL/Id of resource referenced --></version> <display><!-- 0..1 string Text alternative for the resource --></display> </[name]>
Terminology Bindings
| Path | Details | Strength |
|---|---|---|
| ResourceReference.type | Any defined Resource Type name | complete/required |
The reference must specify the resource type, whether or not the type of the resource reference is fixed for the element in the resource definition. A resource reference may contain either a version independent reference ("id") or a version dependent reference ("version") or both. If both are provided, it is at the discretion of the processor of the data whether to access the version specific or version independent reference.
Both the id and the version are URL references - they must be literal URLs that resolve to the location of the resource. Both URLs may either be absolute URLs, or relative URLS. If they are relative URLs, they are interpreted to contain the logical id and versionId respectively of the resource in question, and the resolution of the local references is a matter of implementation logic. If relative references are used, a version cannot be provided without an id, since the version may be scoped by the id. Using absolute URLs provides a stable scalable approach suitable for a cloud/web context, while using relative/logical references provides a flexible approach suitable for use when trading between separated eco-systems (see implementation issues for further discussion). Absolute URLs do not need to point to a FHIR RESTful server, though this is the preferred approach. Irrespective of whether the URL points to a FHIR RESTful server or includes the logical id in the URL, URLs are always considered to be case-sensitive and lowercase is preferred.
A relative reference to the patient "034AB16" in an element named "context":
<context>
<type>Patient</type>
<id>034AB16</id>
<context>
This is a relative reference in the sense that the patient resource "034AB16" is available from the same location as the resource that contains the reference. So, for instance, if the resource that contains this reference is at http://www.acme.com/fhir/labreport/@1234567, then this patient resource will be at http://www.acme.com/fhir/patient/@034AB16
An absolute reference to a resource profile in an element named "profile":
<profile>
<type>Profile</type>
<id>http://fhir.hl7.org/svc/profile/@c8973a22-2b5b-4e76-9c66-00639c99e61b</id>
<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:
<id>
<type>Organization</type>
<id>1234</id>
<display>HL7, Inc</display>
<id>
This text can be used by a system that is unable to resolve the reference to an actual resource.
Use
There is no explicit version marker in the XML. Subsequent versions of this specification may introduce new elements at any point in the content models, but the path and meaning of existing data elements will not be changed. Given that, in a typical scenario, mixed versions may need to exist, applications SHOULD ignore elements that they do not recognize unless those elements are marked with a "must understand" attribute. 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 must declare whether they will do so in their conformance statements using the acceptUnknown element.
Note that the version of FHIR supported is a mandatory element in the applications conformance profile.
This specification provides schema definitions for all of the content models described here. The base schema is called "fhir-base.xsd" and defines all of the datatypes and also the base infrastructure types described on this page. In addition, there is a schema for each resource and a common schema fhir-all.xsd that includes all the resource schemas. A customized atom schema fhir-atom.xsd is provided for validating bundles.
In addition to the w3c schema files, this specification also provides Schematron files that enforce the various constraints defined for the datatypes and resources. These are packaged as files for each resource as well as a combined fhir-atom.sch file that incorporates the rules for all resources.
XML that is exchanged must be valid against the w3c schema and Schematron, though there is no requirement to validate instances against either, nor is being valid against the schema and Schematron sufficient to be a conformant instance. (This specification makes several rules that cannot be checked by either mechanism.) Exchanged content must not specify the schema or even the schema instance namespace in the resource itself.
In addition to the schema, this specification also provides object models defined in UML that may be of assistance in defining systems that work with the resources defined here.
Although the UML models provided express the same contents as the resource formats, because of the wide variation in how different architectures and tools map from UML to XML, there should be no expectation that any particular tool will produce compatible XML from these UML diagrams. Systems are welcome to use these object models as a basis for serialization internally or even between trading partner systems, with any form of exchange technology (including JSON). Systems that use this form of exchange cannot claim to be conformant with this specification, but can describe themselves as using "FHIR consistent object models".
This is an old version of FHIR retained for archive purposes. Do not use for anything else
Implementers are welcome to experiment with the content defined here, but should note that the contents are subject to change without prior notice.
© HL7.org 2011 - 2012. FHIR v0.06 generated on Tue, Dec 4, 2012 00:04+1100. License