Exchange
This
page
is
part
of
the
FHIR
Specification
(v3.0.2:
STU
3).
(v3.5.0:
R4
Ballot
#2).
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 | Ballot Status : Trial Use |
FHIR resources can be used to build documents that represent a composition: a set of coherent 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"
"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"
"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
Provenance
statements
and
a
signature.
The composition resource is the foundation of the clinical document. It:
Any resource referenced directly in the Composition SHALL be included in the bundle when the document is assembled. Specifically, this means the following resource references:
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,
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,
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
may
might
not
represent
the
original
attested
content.
Implementation
Guides
may
restrict
document
narrative
and
display
behaviour
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"><Bundle xmlns="http://hl7.org/fhir"> <!-- metadata and type --> <link><relation value="stylesheet"/> <url value="[uri]"/><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
particular
documents
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,
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
be
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
|
| [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
|
Note:
While
these
end-points
are
defined
for
use
with
document
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 .
®©
HL7.org
2011+.
FHIR
Release
3
(STU;
v3.0.2-11200)
Mixed
Nomative/Trial
Use
Ballot
#2
(v3.5.0-14907)
generated
on
Thurs,
Oct
24,
2019
11:53+1100.
Sun,
Aug
19,
2018
21:54+1000.
QA
Page
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
|
Compare
to
DSTU2
DSTU3
|
Ballot
Comparison
|
|
Propose
a
change