Release
4
5
Preview
#1
Exchange
This
page
is
part
of
the
FHIR
Specification
(v4.0.1:
R4
-
Mixed
Normative
and
STU
)
in
it's
permanent
home
(it
will
always
be
available
at
this
URL).
(v4.2.0:
R5
Preview
#1).
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
Infrastructure
Work
Group
|
Maturity Level : 3 | Standards Status : Trial Use |
FHIR resources can be used to build documents that represent a composition: a coherent set of information that is a statement of healthcare information, 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 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" (see Conformance ).
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 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
provide
supporting
evidence
for
the
document.
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:
Resources referenced by the Composition as listed below 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 do so. 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 include only:
There are two key identifiers in 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
fullUri
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 directly referenced content within the document and the presentation of the document cannot change substantially (such that it changes the clinical meaning of the content). Any additional documents derived from the same composition SHALL have a different document id.
When the document is presented for human consumption, applications SHOULD present the collated narrative portions in order:
The
presentation
of
the
document
is
called
the
'attested
content'
of
the
document.
Additional
resources
can
be
included
in
the
bundle
(e.g.
resources
referenced
from
the
List
that
represent
the
section.content
SHOULD
be
in
the
bundle,
and
other
additional
resources
they
reference
can
be
included),
but
these
(and
any
narrative)
are
not
attested
content.
Specifically,
the
Composition.attester
attests
to
the
presented
form
of
the
document.
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.
If the document is presented in a different order from that given above, it might not represent the original attested content. Implementation Guides may restrict document narrative and display behavior further.
The XML Tools reference implementation includes a XSLT transform that converts an XML 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
url
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 for stylesheets, because the viewer may be unable to resolve external content at the time of viewing, due to technical problems or local policy decisions.
Any stylesheet referenced or used SHALL NOT alter the presentation in such a way that it changes the clinical meaning of the content.
Unless otherwise agreed in local trading partner agreements, applications displaying the collated narrative SHOULD use the stylesheets specified by the document (see security note ). 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
Capability
Statements
that
identify
document
types
they
support.
Documents
can
identify
a
profile
that
they
conform
to
by
placing
a
profile
identifier
in
the
Bundle.meta.profile
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 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. Note that if documents are POSTed using a create interaction the Bundle.id will change, but the Bundle.identifier will not. See Serving Bundles using the RESTful API for further comment |
| [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.). See Accepting other Bundle types for further details |
Note: While these end-points are defined for use with document-related resources and document bundles, it is not necessary to use them. Documents may be transferred between systems using any method desired. In addition, servers and/or specifications may define additional operations for handling documents beyond the options described above.
A client can ask a server to generate a fully bundled document from a composition resource. For details, see Generate Document Operation .
FHIR
®©
HL7.org
2011+.
FHIR
Release
4
(Technical
Correction
#1)
(v4.0.1)
CI
Build
hl7.fhir.core#4.2.0
(GitHub
f996518d66)
generated
on
Fri,
Nov
1,
Tue,
Dec
31,
2019
09:37+1100.
QA
Page
21:18+1100.
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
QA
Page
|
Compare
to
R3
R4
|
|
Propose
a
change