This
page
is
part
of
the
FHIR
Specification
(v1.0.2:
DSTU
2).
The
current
version
which
supercedes
this
version
is
This page is part of the FHIR Specification (v1.4.0:
STU
3 Ballot 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
. For a full list of available versions, see the
Directory of published versions 
.
Page
versions:
. Page versions:
R5
R4B
R4
R3
R2
2.3.1
Clinical
Document
Architecture
(CDA)
on
FHIR
Clinical Document Architecture (CDA) on FHIR
2.3.1.1
What
is
CDA
on
FHIR?
What is CDA on FHIR?
CDA
on
FHIR
specifies
how
to
implement
CDA
R2
with
the
FHIR
CDA on FHIR specifies how to implement CDA R2 with the FHIR
Composition
resource.
The
original
HL7
Clinical
Document
Architecture
(CDA)
defined
the
structure
and
semantics
of
"clinical
documents"
for
the
purpose
of
exchange.
A
clinical
document
is
a
documentation
of
clinical
observations
and
services,
with
the
following
characteristics:
Persistence
-
A
clinical
document
continues
to
exist
in
an
unaltered
state,
for
a
time
period
defined
by
local
and
regulatory
requirements
(NOTE:
There
is
a
distinct
scope
of
persistence
for
a
clinical
document,
independent
of
the
persistence
of
any
XML-encoded
CDA
document
instance).
Stewardship
-
A
clinical
document
is
maintained
by
an
organization
entrusted
with
its
care.
Potential
for
authentication
-
A
clinical
document
is
an
assemblage
of
information
that
is
intended
to
be
legally
authenticated.
Context
-
A
clinical
document
establishes
the
context
for
its
contents.
Wholeness
-
Authentication
of
a
clinical
document
applies
to
the
whole
and
does
not
apply
to
portions
of
the
document
without
the
full
context
of
the
document.
Human
readability
-
A
clinical
document
is
human
readable.
A
CDA
document
on
FHIR
is
a
defined
and
complete
information
object
that
can
include
text,
images,
sounds,
and
other
multimedia
content.
resource.
The original HL7 Clinical Document Architecture (CDA) defined the structure and semantics of "clinical documents" for the purpose of exchange. A clinical document is a documentation of clinical observations and services, with the following characteristics:
-
Persistence - A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements (NOTE: There is a distinct scope of persistence for a clinical document, independent of the persistence of any XML-encoded CDA document instance).
-
Stewardship - A clinical document is maintained by an organization entrusted with its care.
-
Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated.
-
Context - A clinical document establishes the context for its contents.
-
Wholeness - Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document.
-
Human readability - A clinical document is human readable.
A CDA document on FHIR is a defined and complete information object that can include text, images, sounds, and other multimedia content.
2.3.1.2
Scope
of
the
CDA
on
FHIR
Scope of the CDA on FHIR
The
scope
of
CDA
on
FHIR
is
the
standardization
of
clinical
documents
for
exchange.
The scope of CDA on FHIR is the standardization of clinical documents for exchange.
The
data
format
of
clinical
documents
outside
of
the
exchange
context
(e.g.
the
data
format
used
to
store
clinical
documents)
is
not
addressed
in
this
specification.
The data format of clinical documents outside of the exchange context (e.g. the data format used to store clinical documents) is not addressed in this specification.
CDA
on
FHIR
does
not
specify
the
creation
or
management
of
documents,
only
their
exchange
markup.
While
it
may
be
possible
to
directly
use
the
CDA
Schema
in
a
document
authoring
environment,
such
use
is
not
the
primary
purpose
of
the
CDA
specification.
CDA on FHIR does not specify the creation or management of documents, only their exchange markup. While it may be possible to directly use the CDA Schema in a document authoring environment, such use is not the primary purpose of the CDA specification.
Document
management
is
critically
interdependent
with
the
CDA
specifications,
but
the
specification
of
document
management
messages
is
outside
the
scope
of
the
CDA.
Document management is critically interdependent with the CDA specifications, but the specification of document management messages is outside the scope of the CDA.
2.3.1.3
Goals
and
Design
Principles
Goals and Design Principles
The
goals
of
the
CDA
on
FHIR
are:
Give
priority
to
delivery
of
patient
care.
Allow
cost
effective
implementation
across
as
wide
a
spectrum
of
systems
as
possible.
Support
exchange
of
human-readable
documents
between
users,
including
those
with
different
levels
of
technical
sophistication.
Promote
longevity
of
all
information
encoded
according
to
this
architecture.
Enable
a
wide
range
of
post-exchange
processing
applications.
Be
compatible
with
a
wide
range
of
document
creation
applications.
Promote
exchange
that
is
independent
of
the
underlying
transfer
or
storage
mechanism.
Prepare
the
design
reasonably
quickly.
Enable
policy-makers
to
control
their
own
information
requirements
without
extension
to
this
specification.
A
number
of
design
principles
follow
from
consideration
of
the
above
goals:
This
architecture
must
be
compatible
with
XML
and
JSON.
This
architecture
must
be
compatible
with
representations
of
clinical
information
arising
from
other
HL7
committees.
Technical
barriers
to
use
of
the
architecture
should
be
minimized.
The
architecture
specifies
the
representation
of
instances
required
for
exchange.
The
architecture
should
impose
minimal
constraints
or
requirements
on
document
structure
and
content
required
for
exchange.
The
architecture
must
be
scalable
to
accommodate
fine-grained
markup
such
as
highly
structured
text
and
coded
data.
Document
specifications
based
on
this
architecture
should
accommodate
such
constraints
and
requirements
as
supplied
by
appropriate
professional,
commercial,
and
regulatory
agencies.
Document
specifications
for
document
creation
and
processing,
if
intended
for
exchange,
should
map
to
this
exchange
architecture.
CDA
documents
must
be
human
readable
using
widely-available
and
commonly-deployed
XML-aware
browsers
and
print
drivers
and
a
generic
CDA
style
sheet
written
in
a
standard
style
sheet
language.
Use
open
standards.
The goals of the CDA on FHIR are: -
Give priority to delivery of patient care.
Allow cost effective implementation across as wide a spectrum of systems as possible.
Support exchange of human-readable documents between users, including those with different levels of technical sophistication.
Promote longevity of all information encoded according to this architecture.
Enable a wide range of post-exchange processing applications.
Be compatible with a wide range of document creation applications.
Promote exchange that is independent of the underlying transfer or storage mechanism.
Prepare the design reasonably quickly.
Enable policy-makers to control their own information requirements without extension to this specification.
A number of design principles follow from consideration of the above goals:
-
This architecture must be compatible with XML and JSON.
-
This architecture must be compatible with representations of clinical information arising from other HL7 committees.
-
Technical barriers to use of the architecture should be minimized.
-
The architecture specifies the representation of instances required for exchange.
-
The architecture should impose minimal constraints or requirements on document structure and content required for exchange.
-
The architecture must be scalable to accommodate fine-grained markup such as highly structured text and coded data.
-
Document specifications based on this architecture should accommodate such constraints and requirements as supplied by appropriate professional, commercial, and regulatory agencies.
-
Document specifications for document creation and processing, if intended for exchange, should map to this exchange architecture.
-
CDA documents must be human readable using widely-available and commonly-deployed XML-aware browsers and print drivers and a generic CDA style sheet written in a standard style sheet language.
-
Use open standards.
2.3.1
General
CDA
on
FHIR
Concepts
General CDA on FHIR Concepts
2.3.1.1
Major
Components
of
a
CDA
on
FHIR
Document
Major Components of a CDA on FHIR Document
This
section
serves
as
a
high-level
introduction
to
the
major
components
of
a
CDA
document,
all
of
which
are
described
again
and
in
greater
detail
later
on.
The
intent
here
is
to
familiarize
the
reader
with
the
high-level
concepts
to
facilitate
an
understanding
of
the
sections
that
follow.
[EDITORS:
in
CDA
r2
there
is
a
bunch
of
detail
about
how
CDA
is
wrapped
-
and
an
example.
Consider
whether
the
discussion
is
relevant
here:
"A
CDA
document
is
wrapped
by
the
<ClinicalDocument>
element,
and
contains
a
header..."]
This section serves as a high-level introduction to the major components of a CDA document, all of which are described again and in greater detail later on. The intent here is to familiarize the reader with the high-level concepts to facilitate an understanding of the sections that follow. [EDITORS: in CDA r2 there is a bunch of detail about how CDA is wrapped - and an example. Consider whether the discussion is relevant here: "A CDA document is wrapped by the <ClinicalDocument> element, and contains a header..."]
2.3.1.2
Human
Readability
and
Rendering
CDA
Documents
Human Readability and Rendering CDA Documents
The
CDA
requirement
for
human
readability
guarantees
that
a
receiver
of
a
CDA
document
can
algorithmically
display
the
clinical
content
of
the
note
on
a
standard
Web
browser.
There
must
be
a
deterministic
way
for
a
recipient
of
an
arbitrary
CDA
document
to
render
the
attested
content.
Human
readability
shall
not
require
a
sender
to
transmit
a
special
style
sheet
along
with
a
CDA
document.
It
must
be
possible
to
render
all
CDA
documents
with
a
single
style
sheet
and
general-market
display
tools.
Human
readability
applies
to
the
authenticated
content.
There
may
be
additional
information
conveyed
in
the
document
that
is
there
primarily
for
machine
processing
that
is
not
authenticated
and
need
not
be
rendered.
When
structured
content
is
derived
from
narrative,
there
must
be
a
mechanism
to
describe
the
process
(e.g.
by
author,
by
human
coder,
by
natural
language
processing
algorithm,
by
specific
software)
by
which
machine-processable
portions
were
derived
from
a
block
of
narrative.
When
narrative
is
derived
from
structured
content,
there
must
be
a
mechanism
to
identify
the
process
by
which
narrative
was
generated
from
structured
data.
These
principles
and
requirements
have
led
to
the
current
approach,
where
the
material
to
be
rendered
is
placed
into
the
Section.content...[EDITORS:
current
design
doesn't
make
it
clear
where
to
consistently
find
narrative]
©
HL7.org
2011+.
FHIR
DSTU2
(v1.0.2-7202)
generated
on
Sat,
Oct
24,
2015
07:44+1100.
Links:
Search
The CDA requirement for human readability guarantees that a receiver of a CDA document can algorithmically display the clinical content of the note on a standard Web browser.
-
There must be a deterministic way for a recipient of an arbitrary CDA document to render the attested content.
-
Human readability shall not require a sender to transmit a special style sheet along with a CDA document. It must be possible to render all CDA documents with a single style sheet and general-market display tools.
-
Human readability applies to the authenticated content. There may be additional information conveyed in the document that is there primarily for machine processing that is not authenticated and need not be rendered.
-
When structured content is derived from narrative, there must be a mechanism to describe the process (e.g. by author, by human coder, by natural language processing algorithm, by specific software) by which machine-processable portions were derived from a block of narrative.
-
When narrative is derived from structured content, there must be a mechanism to identify the process by which narrative was generated from structured data.
These principles and requirements have led to the current approach, where the material to be rendered is placed into the Section.content...[EDITORS: current design doesn't make it clear where to consistently find narrative]
