. Page versions: R5 R4B R4 R3 R2This page is part of the FHIR Specification (v0.01: Historical Archive 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
This page describes how FHIR Resources can be used to build clinical documents, like CDA. Applications claiming conformance to this framework claim to be conformant to "FHIR documents".
Documents are a collections of resources that a fixed in scope and frozen in time, and authored and/or attested by a collection or humans, orgnisations and devices, and gathered together into a single aggregation using an atom feed. 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.
All documents have the same structure: an aggregation that has Document Resource first, followed by a series of other resources referenced from the Document resource.
The document resource identifies the document and it's purpose, sets the context of the document, and carries key information such as the subject and author, and divides the document up into sections that each contain a content resource, which is some other resource identified in this specification. Any resource referenced directly in the Document resource must be included in the aggregation when the document is assembled; other resources that these documents refer to may also be aggregated if the document originator chooses to.
Document profiles and/or application conformance statements can make additional rules about which resources must be aggregated along with the resources that are directly referenced in the Document resource. In addition, Document Profiles and conformance statements can specify what sections a document contains, and what the constraints on their content resource are.
Since documents are attested at a fixed point in time with known contents, any handling of documents must ensure that the content has not changed at all. Applications are allowed to extract content from the document and use it in other contexts, but it is no longer part of the document. When storing documents, applications may store the entire document as a single byte stream, which would ensure that it can be reproduced exactly, or they can disassemble the document into component resources (or another disassembly strategy), as long as the original document can be assembled in it's original form if the original document is required. Applications are not mandated to store all documents, though most actual usages will require the document to persist.
The standard RESTful framework, there is an manager for the Document resource which uses the standard HTTP Transactions applied to Document resources. In this fashion, a RESTful framework can be used to build a logical description of a document by updating the appropriate resources. Note that although this can form a logically complete description of the document a full document only exists once the resources that are part of the document are built into a single aggregation.
Note that the standard /document end point defined with the Document resource handles individual Document resources, not full documents that are aggregations. Using this resource directly is mostly confined to the process of constructing a document using the RESTful framework. The RESTful end point for full aggregated documents is /aggregations
Applications that handle and process documents are not required to make the individual constituent resources that are part of a document available through the their resource specific URL, though they may choose to do so.
Issues: images & attachments
Applications claiming to be conformant to "FHIR documents" may choose to publish a conformance statement that lists all the document types they support, and for each type, what the document and section content is, and which resources are aggregated (originator), or are required to be aggregated (recipient), along with constraint statements for the information content of the individual resources. The conformance statement is a resource with the name "DocumentConformance".
The same structure can be used to declare a document profile. Such profiles may be defined and published by HL7, other standards organisations, institutions, and projects.
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.01 generated on Mon, May 14, 2012 09:48+1000.