6.8 Document リソース

Home ＞ Infrastructure ＞ Document [document]

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, 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".

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 other documents.

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 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 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 those contents are. Applications should consider publishing conformance statements that identify particular documents they support.

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

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.

Alternate definitions: Schema/Schematron, Resource Profile

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

• 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 document resource, the subject resource, and the resources referred to in the Document.section.content references. When a document is bundled, additional resources can be included, but these are not attested content
• 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.

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

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.

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. If the parties agree on a stylesheet that is not contained in the document, then it is likely that they will never be able to share their documents in a more general context, such as a regional or national EHR, or a global personal health record.

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

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 attesters are properly aware of the presentation of the document to which they are attesting

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, accessed via a document management system or forward by a third party. 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 orreplaces 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

• Document Bundles 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 for RESTful searches. The standard parameters also apply. See Searching for more information.