This page is part of the FHIR Specification (v0.05: DSTU 1 Draft). 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 DocumentHeader - Content

Status: An infrastructure resource. This is an approved resource, and its status is 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

All documents have the same structure: a bundle that has a Document Header resource (below) first, followed by a series of other resources referenced from the Document header that 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 header 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.

The Document.id identifies the logical document. Multiple versions of the document may exist, each with their own unique bundle identifier (Atom feed.id). The means the Document.id maps to CDA ClinicalDocument.setId and the feed.id to ClinicalDocument.id.

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

There are two RESTful end-points defined for Documents:

• [baseurl]/documentheader/: a normal RESTful end point for document header resources
• [baseurl]/document/: a RESTful end point that serves documents as bundles. This is described below

The first end-point is used for working within the document contents, for instance, for building documents piecemeal, for auditing received documents or for providing a document registry. The second end-point is used for working with whole documents, such as providing a document repository. Servers may un-bundle documents received through the /document/ end-point, and make the document resources they contain available through the /documentheader/ end-point, but are not required to do so.

RESTful systems may also accept documents through their mailbox.

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

Resource Content

<DocumentHeader xmlns="http://hl7.org/fhir">
 <id><!-- 1..1 id Master Resource Id = document Id --></id>
 <instant><!-- 1..1 instant Document Creation Time --></instant>
 <type><!-- 1..1 CodeableConcept Kind of Document (LOINC if possible) --></type>
 <title d?><!-- 0..1 string Document Title --></title>
 <replaces><!-- 0..1 id If this document replaces another --></replaces>
 <enterer d?><!-- 0..1 Resource(Agent) The source of the data entry --></enterer>
 <subject><!-- 1..1 Resource(Patient|Group|Device) Who/what the document is about --></subject>
 <informant d?><!-- 0..1 Resource(Person) Who provided information in document --></informant>
 <author><!-- 1..* Resource(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 d?><!-- 0..1 dateTime When document attested --></time>
  <party d?><!-- 0..1 Resource(Agent|Organization) Who attested the document --></party>
 </attester>
 <recipient d?><!-- 0..* Resource(Agent|Organization) Expected to receive a copy  --></recipient>
 <custodian><!-- 1..1 Resource(Organization) Org which maintains the document --></custodian>
 <context d?><!-- 0..1 Resource(Any) The clinical item being documented --></context>
 <encounter d?><!-- 0..1 Resource(Admission|InterestOfCare) Context of the document --></encounter>
 <stylesheet d?><!-- 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 -->
  <type><!-- 0..1 CodeableConcept Type of section (recommended) --></type>
  <instant d?><!-- 0..1 instant Section Creation Time --></instant>
  <author><!-- 0..1 Resource(Agent) Who/what authored the section --></author>
  <enterer d?><!-- 0..1 Resource(Agent) The source of the data entry --></enterer>
  <subject><!-- 0..1 Resource(Patient|Group|Device) If section different to document --></subject>
  <informant d?><!-- 0..1 Resource(Person) Who provided information in section --></informant>
  <content d?><!-- 0..1 Resource(Any) The actual data for the section --></content>
  <text d?><!-- 0..1 Narrative Human Readable Text Summary of the section --></text>
  <section><!-- 0..* Content as for DocumentHeader.Section Nested Section --></section>
 </section>
 <extension><!-- 0..* Extension  See Extensions  --></extension>
 <text><!-- 1..1 Narrative Text summary of document, for human interpretation --></text>
</DocumentHeader>

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

Terminology Bindings

• DocumentHeader.type has the definition DocumentType: "Type of a clinical document". If an appropriate code exists in LOINC Document Types then it should be used
• DocumentHeader.attester.mode has the definition DocumentAuthenticationMode: "The way in which a person authenticated a document". Possible values:

  personal	The person authenticated the document in their personal capacity
  professional	The person authenticated the document in their professional capacity
  legal	The person authenticated the document and accepted legal responsibility for its content
  official	The organization authenticated the document as consistent with their policies and procedures

• DocumentHeader.section.type has the definition DocumentSectionType: "Type of a clinical document section". If an appropriate code exists in LOINC Section Types then it should be used

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:

• 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 author, subject, enterer and informant features are inherited in contained sections and need not be repeated. Specifying any of these in a section replaces the inherited value
• 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.

Presenting a Document

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 summarise 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

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 no their long term scope for document exchange very carefully.

Document Handling Obligations

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

Author Obligation

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 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

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

• 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 attester.

RESTful support for Document Bundles

The standard RESTful endpoints (such as [baseurl]/person/@{id} for a Person resource or [baseurl]/document/@{id} for the Document resource) handle the individual resources and not bundles (though, per the RESTful spec, they serve up atom feeds for the history, search and update operations). The Document framework defines an additional end-point for handling document bundles at [baseurl]/document/@{id}). In this context, the id is the id of the Document Header resource. The end-point supports the following operations:

Instance
read	Retrieve a document bundle
vread	Retrieve a particular version of a document
update	Post a document to the server.
delete	Delete a bundle.
validate	Check that the content would be acceptable as a submission
history	Returns a history for the document.
Manager
updates	Get a list of updates to resources of this type, optionally with some filter criteria
search	Search the document bundles based on some filter criteria. Supported search parameters atom.id - an id of a document (i.e. the feed.id in the atom) other parameters as for the document resource apply
create	Not supported - document ids are always provided by the author, and the document must be provided as an update

Note that the history, updates and search methods all return atom feeds that contain bundles - that is, atom feeds that contain entries where the content type is another atom feed. Atom feeds are only ever nested two levels deep (i.e. one atom feed containing a series of atom feeds that are bundles that contain resources).

Search Parameters

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

n : integer	Starting offset of the first record to return in the search set
count : integer	Number of return records requested. The server is not bound to conform
id : token	The id of the resource
type : qtoken	the type of the document
date : date	date equal to the document creation time
date-before : date	date before or equal to the document creation time
date-after : date	date after or equal to the document creation time
subject : qtoken	subject of the document
author : qtoken	author of the document
attester : qtoken	attester of the document
context : qtoken	context of the document
section-type : qtoken	code of the document
section-content : qtoken	content resource of the section

(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.05 generated on Sun, Sep 9, 2012 03:28+1000. License