Exchange
This
page
is
part
of
the
FHIR
Specification
v6.0.0-ballot3:
Release
6
Ballot
(3rd
Draft)
(see
Ballot
Notes
).
The
current
version
is
5.0.0
.
For
a
full
list
Continuous
Integration
Build
of
available
versions,
see
FHIR
(will
be
incorrect/inconsistent
at
times).
See
the
Directory
of
published
versions
|
Responsible
Owner:
FHIR
Infrastructure
Work
Group
|
Standards
Status
:
|
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 a set of resources with a fixed presentation that is authored and/or attested by humans, organizations and devices.
A
FHIR
document
instance
is
a
Bundle
of
type
document
that
starts
with
a
Composition
and
contains
specific
frozen
versions
of
other
resources.
Changes
to
a
document
Bundle
may
risk
invalidating
the
attestation
present
within
the
document.
Implementations
SHOULD
have
policies
around
when
documents
can
be
'updated'
(new
version
of
the
same
instance)
vs.
when
a
distinct
document
needs
to
be
created,
as
well
as
what
types
of
change
are
permitted,
in
order
to
retain
attestation
validity.
These
rules
might
vary
based
on
the
type
of
document
(e.g.
(e.g.,
legal
documents,
clinical
documents,
etc.).
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 that declare support for FHIR documents with CapabilityStatement.document are asserting conformance to the rules defined on this page.
FHIR
documents
may
serve
clinical
purposes
(focused
on
patient
healthcare
information)
and
non-clinical
purposes
(e.g.
(e.g.,
practice
guidelines,
patient
handouts,
etc.).
HL7
has
plans
to
develop
profiles
in
the
future
giving
additional
guidance
on
appropriate
representation
of
clinical
documents
in
general,
specific
types
of
clinical
documents
(e.g.
(e.g.,
Consolidated
CDA),
and
other
non-clinical
documents
(Death
Certificate,
Medication
Registration
Information).
FHIR
documents
are
not
intended
to
capture
unbounded
data
sets
such
as
all
data
stored
in
an
EHR.
Rather,
consider
the
Bulk
Data
specification
for
use
cases
requiring
access
to
such
data
sets.
Note that FHIR defines both this document format (a document bundle containing a Composition resource and potentially other resources) and a DocumentReference resource . FHIR documents are used for documents that are authored and assembled in FHIR, while the DocumentReference resource is for general references to documents (which may include FHIR documents as well as PDFs, CDAs, etc.).
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
the
supporting
details
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
may
include
both
human
readable
and
computer
processable
portions.
In
addition,
the
bundle
may
include
CSS
stylesheets
,
Provenance
statements
and
a
signature.
including
signatures.
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:
When these resources reference other resources, the referenced resources SHOULD also be included in the bundle. Omitting referenced resources could compromise the integrity and wholeness of the document, especially when considering that documents have legal retention periods that may be longer than the life of the FHIR server where the reference(s) point to.
In rare cases the referenced resources in Composition can also be contained resources within Composition provided that the resource(s) in question meets the restrictions for the use of contained resources (see Contained Resources for more information).
The document bundle SHALL include only:
There are two key identifiers in the document:
The document has several dates in it:
If
there
is
a
need
to
have
a
digital
signature
on
a
Document
Bundles
Bundle,
this
may
be
signed
accomplished
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.
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. Any additional documents derived from the same Composition SHALL have a different Bundle.identifier.
When the document is presented for human consumption, applications SHOULD present the collated narrative portions in order:
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
presentation
of
the
document
is
called
the
'attested
content'
of
the
document.
The
text
of
resources
outside
Composition
and
the
subject
resource
are
not
considered
attested
content
(e.g.
(e.g.,
a
Condition
resource).
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.
The narrative of the subject resource (typically a Patient), referenced in 'Composition.subject' should clearly identify the subject and typically includes fields like name, identifier, etc.
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 contain additional styles that apply to the collated narrative. This is done by asserting stylesheet links on the Bundle:
<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
-
|
| [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]
|
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
R6
hl7.fhir.core#6.0.0-ballot3
generated
on
Tue,
Apr
1,
Mon,
Nov
10,
2025
12:26+1100.
15:23+0000.
Links:
Search
|
Version
History
|
Contents
|
Glossary
|
QA
|
Compare
to
R4
|
Compare
to
R5
|
Compare
to
Last
Ballot
|
|
Propose
a
change