This 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

Resource Document - Content 2.3

Status: Approved infrastructure resource. Draft for comment

A documentation of healthcare-related information that is assembled together into a single statement of meaning that establishes its own context. A document is composed of a set of resources that include both human and computer readable portions. A human may attest to the accuracy of the human readable portion, and may authenticate and/or sign the entire whole. A document may be kept as a set of logically linked resources, or they may be bundled together in an atom feed.

FHIR resources can be used to build clinical documents that capture information about clinical observations and services. A clinical document is a bundle (a list of resources in an atom feed) that is fixed in scope, frozen in time and authored and/or attested as a set of logically contained resources by humans, organisations and devices. Documents built in this fashion may be exchanged between systems and also persisted in document storage and management systems, including systems such as IHE XDS. Applications claiming conformance to this framework claim to be conformant to "FHIR documents".

Document Content 2.3.1

All documents have the same structure: a bundle that has a Document resource (see below) first, followed by a series of other resources referenced from the Document header which provides guidance on how they fit together. The bundle gathers all the content of the document into a single XML document which may be signed and managed as required. The resources include both human and computer readable portions.

The document resource identifies the document and its purpose, sets the context of the document and carries key information such as the subject and author. It also divides the document up into a series of sections that contain other resources identified in this specification that carry the content. Any resource referenced directly in the Document resource must be included in the bundle when the document is assembled. Other resources that these referenced resources refer to may also be included in the bundle if the document originator chooses to.

Document profiles can make additional rules about which resources must be included in the bundle along with the resources that are directly referenced in the Document resource. In addition, Document Profiles can specify what sections a document contains and what the constraints on their contents are. Applications should consider publishing conformance statements that identify particular documents they support.

Document End-Points 2.3.2

There are two RESTful end-points used for Documents:

• [baseurl]/document/: a normal RESTful end point for document resources as standalone resources
• [baseurl]/binary/: for documents as bundles. Usually used with a document registry

Note: While these end-points are defined for use with document resources and document bundles, it is not necessary to use them. Documents may be transferred between systems by using the MailBox target, or by using any other method desired.

Resource Content 2.3.3

<Document xmlns="http://hl7.org/fhir">
 <information>  <!-- 1..1 Metadata and context for this document -->
  <id><!-- 0..1 Identifier logical identifier for document (version-independent) --></id>
  <versionId><!-- 0..1 Identifier version-specific identifier for document --></versionId>
  <instant><!-- 1..1 instant Document Creation Time --></instant>
  <class><!-- 0..1 Coding particular kind of document --></class>
  <type><!-- 1..1 CodeableConcept Kind of Document (LOINC if possible) --></type>
  <title><!-- 0..1 string Document Title --></title>
  <confidentialityCode><!-- 1..1 Coding as defined by Affinity Domain --></confidentialityCode>
  <subject><!-- 1..1 Resource(Person|Patient|Group|Device) Who/what the document is about --></subject>
  <author><!-- 1..* Resource(Person|Agent) Who/what authored the final document --></author>
  <attester>  <!-- 0..* Attests to accuracy of document -->
   <mode><!-- 1..1 code Personal | professional | legal | official --></mode>
   <time><!-- 0..1 dateTime When document attested --></time>
   <party><!-- 0..1 Resource(Person|Agent|Organization) Who attested the document --></party>
  </attester>
  <custodian><!-- 0..1 Resource(Organization) Org which maintains the document --></custodian>
  <event>  <!-- 0..1 The clinical event/act/item being documented -->
   <code><!-- 0..* CodeableConcept code(s) that apply to the event being documented --></code>
   <period><!-- 0..1 Period The period covered by the document --></period>
   <detail><!-- 0..* Resource(Any) Full details for the event(s) the document concents --></detail>
  </event>
  <encounter><!-- 0..1 Resource(Admission|InterestOfCare) Context of the document --></encounter>
  <facilityType><!-- 0..1 CodeableConcept type of organizational setting --></facilityType>
  <practiceSetting><!-- 0..1 CodeableConcept clinical speciality of the act --></practiceSetting>
 </information>
 <replaces><!-- 0..1 id If this document replaces another --></replaces>
 <provenance><!-- 0..* Resource(Provenance) Additional provenance about the document and it's parts --></provenance>
 <stylesheet><!-- 0..1 Attachment Stylesheet to use when rendering the document --></stylesheet>
 <representation><!-- 0..1 Attachment Alternative representation of the document --></representation>
 <section>  <!-- 0..* Document is broken into sections -->
  <code><!-- 0..1 CodeableConcept Classification of section (recommended) --></code>
  <subject><!-- 0..1 Resource(Patient|Group|Device) If section different to document --></subject>
  <content><!-- 0..1 Resource(Any) The actual data for the section --></content>
  <section><!-- 0..* Content as for Document.Section Nested Section --></section>
 </section>
 <extension><!-- 0..* Extension  See Extensions  --></extension>
 <text><!-- 1..1 Narrative Text summary of resource (for human interpretation) --></text>
</Document>

Alternate definitions: Schema/Schematron, RDF (to do), XML, XMI (to do), Resource Profile

Terminology Bindings

Path	Details	Strength
Document.information.type	LOINC Document Types	complete/preferred
Document.information.attester.mode	The way in which a person authenticated a document (see http://hl7.org/fhir/document-attestation-mode for values)	complete/required
Document.section.code	LOINC Section Types	complete/preferred

Constraints

• A document must have a representation, one or more sections or both (xpath: exists(f:representation) or exists(f:section))
• A document stylesheet must have a mime type of text/css (xpath on /stylesheet: f:mimeType = 'text/css')
• A section must have content or one or more sections, but not both. (xpath on /section: exists(f:content) != exists(f:section))

Notes: 2.3.4

• The author and the attester are often the same person, but this may not be the case in some clinical workflows
• The attester attests to the collated narrative portions of the resources
• The custodian is responsible for the maintenance of the document. Principally, they are responsible for the policy regarding persistence of the documents. They need not actually retain a copy of the document, but they should do so.
• The information part of the document header is shared between a document, and a document registry entry (XdsEntry)

Identifying a Document 2.3.5

There are two identifiers on the document information: id and versionId. These allow either a logical document id or a version specific id to be provided, or both. This supports multiple different identification strategies. The following combinations are allowed:

• A fully specified (both Identifier system and id) element is present for both id and versionId. This is the preferred option: globally unique identifiers for both version and non-version specify the document
• A full specified element for the id element, and a local id (no system) for the version number. This is equivalent to a document id, and a version number. In this case the version number is assumed to be unique within the version series of the document identified by the id element
• A fully specified versionId, with no id - this version of this document is identified, but there is no version independent reference. This is discouraged, as explicit replacement tracking will be required, and this can be broken by missing links in the version chain

Any other combinations do not globally uniquely identity a document, and are therefore not allowed.

Note that there is an additional identifier - the bundle identifier itself (atom feed.id). This must be an absolute URI, and in effect globally unique, but has no other particular meaning anywhere else in the specification. For a document, it can be populated with some URI that is extracted from the versionId or id above, or it can be a new UUID that has no other associated use. Implementers should not rely on its value matching one of the formal document identification elements.

Presenting a Document 2.3.6

The human display of the Document is the collated narrative portions of following resources (in order):

1. The Document itself
2. The Subject resource
3. Resources referenced in the section.content

The document narrative should summarize the important parts of the document header that are required to establish clinical context for the document (other than the subject, which is displayed in its own right). To actually build the combined narrative, simply append all the narrative <div> fragments.

Styling Documents 2.3.6.1

In addition to the basic style rules, which must be followed, a document can contain a style sheet that contains additional styles that apply to the collated narrative. Unless otherwise agreed in local trading partner agreements, applications displaying the collated narrative should use the style sheet provided in the document. Parties entering into such a trading agreement should consider the implications it will have on their long term scope for document exchange very carefully.

Document Handling Obligations 2.3.7

The authors and users of Clinical Documents, whether human or software, have obligations that they must satisfy.

Author Obligations 2.3.7.1

A document author is an application that creates a document resource. The author may create new content resources and/or assemble already existing content resources while doing so. A document author has the following responsibilities:

• Build a valid document header that conforms to the Document rules explained here and that only links to other valid resources
• Ensure that the content of the document and other resources conforms to any declared Profiles.
• Ensure that the presentation of the document is properly attested according to the information supplied in the attesters.

User Obligations 2.3.7.2

A document user is an application that receives or presents documents, or extracts data from them, or makes decisions because of them. The documents may be received directly from a document author or accessed via a document management system. The document user is responsible for ensuring that received documents are processed and/or rendered in accordance to this specification. A document recipient has the following obligations:

• When storing/transmitting a document, any method may be used as long as the bundled document can be (re-)assembled with sufficient integrity to validate a digital signature (i.e. it is legitimate to unbundle the resources and store them on a FHIR RESTful server, but this is not required)
• When presenting the narrative of the document, the rules described above must be followed
• A user is allowed to extract resources or data from the document for other use, but such data is no longer considered to be attested by the document author
• Wherever the data (or information derived from it) is displayed to a user, there should always be a way for the user to access a presentation of the original document
• It must correctly determine when a document has been superseded (according the statements made in the setId, version or replaces elements of received documents or those in the source document management system) and either withdraw data extracted from superseded documents, or warn users when they view the document

Implementation Notes 2.3.8

• Documents may be signed using digital signatures following the rules laid out in the Atom specification. The signature SHOULD be provided by a listed attester of the document and the signature SHOULD contain a KeyInfo element that contains a KeyName element whose value is a URI that matches the Atom link element value for the matching attester resource.

Search Parameters 2.3.9

Search Parameters for RESTful searches. The standard parameters also apply. See Searching for more information.

$page : integer	Starting offset of the first record to return in the search set	single
$count : integer	Number of return records requested. The server is not bound to conform	single
$id : token	The logical resource id associated with the resource (must be supported by all servers)	single
type : qtoken	the type of the document	union
date : date	date equal to the document creation time	single
date-before : date	date before or equal to the document creation time	single
date-after : date	date after or equal to the document creation time	single
subject : qtoken	subject of the document	union
author : qtoken	author of the document	union
attester : qtoken	attester of the document	union
context : qtoken	context of the document	union
section-type : qtoken	code of the document	union
section-content : qtoken	content resource of the section	union

(See Searching).

---

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