Exchange
This
page
is
part
of
the
FHIR
Specification
(v3.0.2:
STU
(v5.0.0-ballot:
R5
Ballot
-
see
ballot
notes
3).
).
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
:
|
|
Status:
draft.
Extension
maintained
by:
Health
Level
Seven
International
(Modeling
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
Methodology)
services.
A
document
is
a
frozen
set
of
resources
with
a
fixed
presentation
that
is
authored
and/or
attested
by
humans,
organizations
and
devices.
A document instance 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.) Strict limitations on document change are sometimes referred to as 'document immutability'.
Direction
(e.g.,
N,
S,
W,
E).
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 ).
Context
of
Use:
Use
FHIR
documents
may
be
'clinical'
(focused
on
data
type:
Address.line
patient
healthcare
information)
but
may
also
serve
non-clinical
purposes
(e.g.
practice
guidelines,
patient
handouts,
etc.).
HL7
will
develop
profiles
in
the
future
giving
additional
guidance
on
appropriate
representation
of
clinical
documents
in
general,
specific
types
of
clinical
documents
(e.g.
Consolidated
CDA),
and
other
non-clinical
documents.
usage
info:
insert
FHIR
documents
are
not
intended
to
capture
unbounded
data
sets
such
as
a
list
of
places
where
full
EHR.
Rather,
consider
the
Bulk
Data
specification
for
such
use
cases.
Note
that
FHIR
defines
both
this
extension
document
format
and
a
DocumentReference
resource
.
FHIR
documents
are
for
documents
that
are
authored
and
assembled
in
FHIR,
while
the
DocumentReference
resource
is
used
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
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:
Summary
Resources
referenced
by
the
Composition
as
listed
below
SHALL
be
included
in
the
bundle
when
the
document
is
assembled:
Full
Structure
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
Card.
for
more
information).
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
Type
Description
&
Constraints
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:
The
presentation
of
the
document
is
called
the
'attested
content'
of
the
document.
Additional
resources
included
in
the
document
that
are
not
part
of
the
presentation
of
the
document
are
not
considered
attested
content
(e.g.
a
Condition
Value
resource).
Specifically,
the
Composition.attester
attests
to
the
presented
form
of
extension
Documentation
the
document.
The
Composition
resource
narrative
should
summarize
the
important
parts
of
the
document
header
that
are
required
to
establish
clinical
context
for
this
format
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
Template
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>
JSON
Template
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.
Summary
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.
Full
Structure
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
|
|
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
|
|
| 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
|
XML
Template
<!-- ADXP-direction -->
< xmlns="http://hl7.org/fhir"
url="" >
<!-- from Element:
<
</extension>
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
JSON
Template
{ //
// from Element:
"
],
"
"
}
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
3
(STU;
v3.0.2-11200)
R5
Ballot
hl7.fhir.core#5.0.0-ballot
generated
on
Thurs,
Oct
24,
2019
11:53+1100.
QA
Page
Sat,
Sep
10,
2022
05:07+1000.
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
Glossary
|
QA
|
Compare
to
DSTU2
R4B
|
Compare
to
R5
Draft
|
|
Propose
a
change