2nd DSTU Draft For Comment
This page is part of the FHIR Specification (v0.4.0: DSTU 2 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 
. Page versions: R5 R4B R4 R3 R2
FHIR resources can be used to build documents that represent a composition: a set of coherent information that is a statement of healthcare information, particularly including clinical observations and services. A document is an immutable set of resources with a fixed presentation that is authored and/or attested by humans, organizations 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".
FHIR documents may be 'clinical' (focused on patient healthcare information) but may also serve non-clinical purposes (e.g. FHIR Implementation guides, practice guidelines, patient handouts, etc.) HL7 will develop profiles in the future giving additional guidance on appropriate representation of clinical documents in general as well as specific types of clinical documents (e.g. Consolidated CDA).
Note that FHIR defines both this document format and also a document reference resource. FHIR documents are for documents that are authored and assembled in FHIR, while the document reference resource is for general references to pre-existing documents.
All documents have the same structure: a Bundle of resources of type "document" that has a Composition resource as the first resource in the bundle, followed by a series of other resources referenced from the Composition resource that provides guidance on how they fit together. The bundle gathers all the content of the document into a single XML or JSON document which may be signed and managed as required. The resources include both human readable and computer processable portions. In addition, the bundle may include CSS stylesheets, provenance statements and a signature.
The composition resource is the foundation of the clinical document. It:
Any resource referenced directly in the Composition SHALL 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 construction system chooses to so do. Including these additional resources will make the document bigger, but will save applications from needing to retrieve the linked resources if they need them while processing the document. Thus, whether these linked resources should be included or not depends on the implementation environment.
The document bundle SHALL NOT include any resources not on this list:
There are two key identifiers on the document:
The document has several dates in it:
Document Bundles may be signed using digital signatures following the rules laid out in the digital signatures page. 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.
Once assembled into a bundle, the document is immutable - its content can never be changed, and the document id can never be reused. Note that the document may be represented in either XML or JSON, and interconverted between these or have its character encoding changed, all the while remaining the same document. However the content (the set of attested resources, and their order) and the presentation of the document cannot change. Any additional documents derived from the same composition SHALL have a different document id.
When the document is presented for human consumption, applications must present the collated narrative portions of the following resources in order:
The Composition resource 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 together.
The attested content of the document is the composition, the subject, and the resources directly referenced in the sections, rendered in the order defined above. Additional resources can be included in the bundle, but these are not attested content. Specifically, the attester attests to the presented form of the document.
The XML Tools reference implementation includes a XSLT transform that converts a document into browser-ready XHTML.
In addition to the basic style rules about Narratives, which must be followed, a document can reference or contain one or more stylesheets that contains additional styles that apply to the collated narrative. This is done by asserting stylesheet links on the feed:
<Bundle xmlns="http://hl7.org/fhir">
<!-- metadata and type -->
<link>
<relation value="stylesheet"/>
<url value="[uri]"/>
</link>
</Bundle>
The uri can be an absolute reference to a CSS stylesheet or a relative reference to a Binary resource that carries a CSS stylesheet. Stylesheet references can only refer to a CSS stylesheet - other forms of stylesheet are not acceptable.
Relative (internal) references SHOULD be used if the document is not safe to view without applying the specified stylesheet, as another location might not be available to the viewer due to technical problems or policy decisions.
Unless otherwise agreed in local trading partner agreements, applications displaying the collated narrative SHOULD use the stylesheets specified by the document. Parties entering into a trading agreement to do otherwise should consider the implications this action will have on their long term scope for document exchange very carefully. If the parties agree to use stylesheets that are not contained in the document, then it may be that they will never be able to share their documents safely in a more general context, such as a regional or national EHR or a global personal health record.
Document profiles are used to describe documents for a particular purpose. Document profiles may make rules about:
Applications should consider publishing conformance statements that identify particular documents they support. Documents can identify a profile that they conform to by placing a profile tag in a feed.category element - see Profile Tags for a discussion of the utility of this.
The authors/constructors and processors of Clinical Documents, whether human or software, have obligations that they must satisfy.
A document constructor is an application that creates a document. An author is a human, organization or device that uses the constructor to create a document. Between them, the constructor and the author may create new content resources and/or assemble already existing content resources while performing their tasks. They also have the following responsibilities:
A document processor is an application and/or human user that receives documents, and extracts data from them, or makes decisions because of them. The documents may be received directly from a document constructor, accessed via a document management system or forwarded by a third party. The document processor is responsible for ensuring that received documents are processed and/or rendered in accordance to this specification. A document processor has the obligation to assure that the following rules are followed:
In addition to these obligations, document receivers SHOULD carefully track the source of documents for new documents that supersede existing documents, particularly when the documents represent compositions that have been retracted. When documents have been replaced, they SHOULD either withdraw data extracted from superseded documents or warn users when they view the document or data taken from it.
There are several different RESTful end-points used when working with documents. The use of the various end-points can be best be described by considering the consequences of posting to them:
| End-Point | Type of Content | Description |
| [baseurl]/Bundle | Document Bundle | This works like a normal end point for managing a type of resource, but it works with whole document bundles - i.e. a read operation returns a bundle, an update gets a bundle and a search returns a bundle of bundles |
| [baseurl]/Composition | Composition Resource | The normal end point for managing composition resources. This can be used while building a document or after breaking a document up into its constituent resources or when using compositions separately from documents |
| [baseurl]/Binary | Document Bundle | Just store the entire document as a sequence of bytes and return exactly that sequence when requested. There is no way to find content in the /Binary end-point, so usually this would be associated with a Document Reference so that applications can find and process the document, though this is not required |
| [baseurl] (e.g. a transaction) | Document Bundle | Ignore the fact that the bundle is a document and process all of the resources that it contains as individual resources. Clients SHOULD not expect that a server that receives a document submitted using this method will be able to reassemble the document exactly. (Even if the server can reassemble the document (see below), the result cannot be expected to be in the same order, etc. Thus a document signature will very likely be invalid.) |
| [baseurl]/$mailbox | Document Bundle | Submit the
document to the server for processing. The exact processing the server performs is at the discretion of the
server. It MAY perform one or more of these actions:
Implementation Profiles should be careful when making rules about what happens when a document is submitted to the mailbox, as it would be easy to make rules such that a server cannot conform to more than one profile at a time. |
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 using any method desired.
A client can ask a server to generate a fully bundled document from a composition resource. For details, see Generate Document Operation.
© HL7.org 2011+. FHIR DSTU (v0.4.0-4167) generated on Mon, Feb 23, 2015 09:24+1100.
Links: What's a DSTU? |
Version History |
Compare to DSTU1 |
|
Propose a change