Exchange
This
page
is
part
of
the
Continuous
Integration
Build
of
FHIR
Specification
(v4.0.1:
R4
-
Mixed
Normative
and
STU
)
in
it's
permanent
home
(it
will
always
(will
be
available
incorrect/inconsistent
at
this
URL).
The
current
version
which
supercedes
this
version
is
5.0.0
.
For
a
full
list
of
available
versions,
see
times).
See
the
Directory
of
published
versions
.
Page
versions:
R5
R4B
R4
R3
R2
|
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
an
immutable
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.,
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.
XDS
.
Applications
claiming
that
declare
support
for
FHIR
documents
with
CapabilityStatement.document
are
asserting
conformance
to
the
rules
defined
on
this
framework
claim
to
be
conformant
to
"FHIR
documents"
(see
Conformance
).
page.
FHIR
documents
may
be
'clinical'
serve
clinical
purposes
(focused
on
patient
healthcare
information)
but
may
also
serve
and
non-clinical
purposes
(e.g.
FHIR
Implementation
guides,
(e.g.,
practice
guidelines,
patient
handouts,
etc.)
etc.).
HL7
will
has
plans
to
develop
profiles
in
the
future
giving
additional
guidance
on
appropriate
representation
of
clinical
documents
in
general
as
well
as
general,
specific
types
of
clinical
documents
(e.g.
(e.g.,
Consolidated
CDA).
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
document
reference
DocumentReference
resource
.
FHIR
documents
are
used
for
documents
that
are
authored
and
assembled
in
FHIR,
while
the
document
reference
DocumentReference
resource
is
for
general
references
to
pre-existing
documents.
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
evidence
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:
document,
it:
Resources referenced by the Composition as listed below SHALL be included in the bundle when the document is assembled:
Other
resources
that
When
these
resources
reference
other
resources,
the
referenced
resources
refer
to
may
SHOULD
also
be
included
in
the
bundle
if
the
document
construction
system
chooses
to
do
so.
Including
these
additional
bundle.
Omitting
referenced
resources
will
make
could
compromise
the
document
bigger
but
will
save
applications
from
needing
to
retrieve
integrity
and
wholeness
of
the
linked
resources
if
they
need
them
while
processing
document,
especially
when
considering
that
documents
have
legal
retention
periods
that
may
be
longer
than
the
document.
Thus,
whether
these
linked
life
of
the
FHIR
server
where
the
reference(s)
point
to.
In
rare
cases
the
referenced
resources
should
in
Composition
can
also
be
included
or
not
depends
on
contained
resources
within
Composition
provided
that
the
implementation
environment.
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.
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
Composition
SHALL
have
a
different
document
id.
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.
Additional
resources
can
be
included
in
the
bundle
(e.g.
The
text
of
resources
referenced
from
the
List
that
represent
the
section.content
SHOULD
be
in
the
bundle,
outside
Composition
and
other
additional
resources
they
reference
can
be
included),
but
these
(and
any
narrative)
the
subject
resource
are
not
considered
attested
content.
content
(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.
If
The
narrative
of
the
document
is
presented
in
subject
resource
(typically
a
different
order
from
that
given
above,
it
might
not
represent
Patient),
referenced
in
'Composition.subject'
should
clearly
identify
the
original
attested
content.
Implementation
Guides
may
restrict
document
narrative
subject
and
display
behavior
further.
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
contains
contain
additional
styles
that
apply
to
the
collated
narrative.
This
is
done
by
asserting
stylesheet
links
on
the
feed:
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
Release
4
(Technical
Correction
#1)
(v4.0.1)
R6
hl7.fhir.core#6.0.0-ballot3
generated
on
Fri,
Sun,
Nov
1,
2019
09:37+1100.
QA
Page
9,
2025
02:09+0000.
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
Glossary
|
QA
|
Compare
to
R3
R4
|
Compare
to
R5
|
Compare
to
Last
Ballot
|
|
Propose
a
change