Clinical Document Architecture
(previously "Patient Record Architecture")
HL7 Meeting
St. Louis, Missouri
September 13, 2000
Bob Dolin, MD
Kaiser Permanente
1
Outline
•Objectives
•Overview of August 2000 Clinical Document
Architecture ballot proposal
•Introduction
•What is the CDA?
•The "A" in "CDA"
•Relationship of CDA to HL7 Messaging Standards
•Technical Specifications
•CDA Header
•CDA Body
•HL7 V3 Data Types
2
Disclaimer
•The models and examples presented here are based
on the August 2000 membership-level ballot draft.
While the ballot did pass, there will be some minor edits
before finalizing the standard.
•The examples displayed in the slides leave out required
components and introduce modifications to illustrate a
point. The examples in the other handout are complete and
accurate.
•The exact representation of CDA instances is contingent on
the outcome of the HL7 V3 data type DTD ballot.
3
Introduction
•Objectives
•Overview of August 2000 Clinical Document
Architecture ballot proposal
•Introduction
•What is the CDA?
•The "A" in "CDA"
•Relationship of CDA to HL7 Messaging Standards
•Technical Specifications
•CDA Header
•CDA Body
•HL7 V3 Data Types
4
Introduction
•What is the CDA?
The CDA is a document markup standard for the structure
and semantics of exchanged "clinical documents".
A clinical document is a documentation of observations and
other services with the following characteristics:
•Persistence
•Stewardship
•Potential for authentication
•Wholeness
•Human readability
A CDA document is a defined and complete information
object that can exist outside of a message, and can include
text, images, sounds, and other multimedia content.
5
Introduction
•What is the CDA? (cont.)
Key aspects of the CDA:
•CDA documents are encoded in Extensible Markup
Language (XML).
•CDA documents derive their meaning from the HL7
Reference Information Model (RIM ) and use HL7 V3
data types.
•The complete CDA will include a hierarchical set of
document specifications. This hierarchy is referred to as
an "architecture".
6
Introduction
•The "A" in "CDA"
CDA Level One DTD
CDA Level Two DTD
Level Two :: Progress Note DTD
Level Two :: Cardiology Progress Note DTD
Level Two :: Endocrine Progress Note DTD
Level Two :: Diabetes Progress Note DTD
CDA Level Three DTD
Level Three :: Progress Note DTD
Level Three :: Cardiology Progress Note DTD
Level Three :: Endocrine Progress Note DTD
Level Three :: Diabetes Progress Note DTD
CDA "Levels" - Quantum sets of specializations, to which
further constraints can be applied.
7
Introduction
•The "A" in "CDA" (cont.)
CDA Level One DTD*
CDA Level Two DTD
CDA Level Three DTD
•Level One :: RIM-derived document header. Body is
largely structural, although codes can be inserted.
•Level Two :: HL7 Templates can constrain the general
Level One DTD, resulting in Level Two DTDs.
•Level Three :: Clinical content can be marked up to the
extent that it is modeled in the RIM.
*The current spec only includes CDA Level One. Higher levels are under development.8
Introduction
•The "A" in "CDA" (cont.)
CDA Level One DTD
CDA Level Two DTD
CDA Level Three DTD
•Level One minimizes the technical barriers to entry, while
providing a "gentle introduction" to the HL7 RIM.
•Levels provide a migration pathway for iteratively adding
greater markup to clinical documents.
•Levels establish baselines for conformance claims.
9
Introduction
•Relationship of CDA to HL7 Messaging Standards
CDA documents are encapsulated as MIME packages
within HL7 messages
HL7 V2.x
HL7 V3
MSH|...
EVN|...
PID|...
PV1|...
TXA|...
OBX|1|ED|...
<service_cd>
<service_txt T="ED">
</service_txt>
</service_cd>
|...
10
Outline
•Objectives
•Overview of August 2000 Clinical Document
Architecture ballot proposal
•Introduction
•What is the CDA?
•The "A" in "CDA"
•Relationship of CDA to HL7 Messaging Standards
•Technical Specifications
•CDA Header
•CDA Body
•HL7 V3 Data Types
11
Technical Specifications
•Introduction
•CDA Header :: Specified in the CDA Header DTD;
derived using the V3 Message Development process.
•CDA Level One Body :: Specified in the CDA Level One
DTD; derived from document analysis, building on the
modeling employed by document markup standards.
•HL7 V3 Data Types :: An XML implementation of the
abstract data type specification used by both the CDA
and the HL7 Version 3 message specifications.
•A CDA Level One document references the CDA Level
One DTD (which references the CDA Header DTD,
which references the HL7 V3 data type DTD).
12
Technical Specifications
•Introduction :: Vocabulary Domains
•Vocabulary domains represent value sets for coded CDA
components.
•HL7-defined or drawn from HL7-recognized coding
systems.
•CNE (Coded, No Extensions) vs. CWE (Coded, With
Extensions)
•Vocabulary terms are transmitted via special data types
(CS, CE, CD)
13
Technical Specifications
Vocabulary domain for <confidentiality_cd> (CWE)
C ode
N
D
R
I
S
C
D isp la y N a m e
no rm al
clinicia n
restricted
ind ivid ual
sen sitive
celeb rity
D efin itio n
N o rm a l co nfid entiality.
O nly clin ician s m a y see this ite m .
R estricted access.
A cce ss o nly to ind ivid ual p erso n s.
S ensitive in fo rm atio n.
C eleb rities.
<!ELEMENT confidentiality_cd %CE-cont.model;>
<!ATTLIST confidentiality_cd
T NMTOKEN #FIXED "CE"
%CE-attrib.list;
...>
<confidentiality_cd V="N"
S="2.16.840.1.113883.5.10228" DN="normal"/>
14
Technical Specifications
Vocabulary domain for <document_relationship.type_cd> (CNE)
C ode
APND
RPLC
D isp la y N a m e
ap p end s
rep laces
D efin itio n
A n ap p end age to an e xistin g rep o rt.
A rep lace m e nt to an e xistin g rep o rt.
<!ELEMENT document_relationship.type_cd
%CS-cont.model;>
<!ATTLIST document_relationship.type_cd
T NMTOKEN #FIXED "CS"
V (APND|RPLC) #REQUIRED
... >
<document_relationship.type_cd V="APND"/>
15
CDA Header
•Overview
The CDA Header is specified by the CDA Header DTD
which is derived from a Hierarchical Description (HD),
using a method that closely parallels the V3 Message
Development Framework.
There are four logical components of the CDA Header:
1. Document information;
2. Encounter data;
3. Service actors (such as providers);
4. Service targets (such as patients).
16
CDA Header
HL7 Reference Information Model
HL7 CDA
HL7 V3 Message
<observation>
<service_cd V="6298-8" S="LOINC"
DN="POTASSIUM:SCNC:PT:BLD"/>
<result_dttm V="2000-05-22"/>
<value V="4.5" U="mg/dl"/>
</observation>
<levelone>
<clinical_document_header>
<document_information>
<encounter_data>
<service_actors>
<service_targets>
</clinical_document_header>
<body>
...
</body>
</levelone>
17
CDA Header
Reference Information Model
Header Information Model
• subset of RIM
• tighten constraints
• linearization
• additional constraints
XML DTD
<!ELEMENT birth_dttm
%TS-cont.model;>
• algorithm
Hierarchical Description
<!ATTLIST birth_dttm
%TS-attrib.list;
%common-atts;
HL7-NAME CDATA #FIXED 'birth_dttm'>
18
CDA Header
HL7 RIM
(MS Access
or
Rational
Rose)
X M L E le m e n t N a m e
clinical_document_header
id
document_type_cd
document_relationship
document_
relationship.type_cd
related_document
id
patient_encounter
id
D a ta T y p e
d o cu m en t_ service
II
CE
service_ relatio n ship
CS
service
II
p atient_ enco u nter
II
http://www.hl7.org/library/data-model/Rose_tooling/RoseTree_II.zip
C a rd in a lity
1 ..1
1 ..1
1 ..1
0 ..*
1 ..1
1 ..1
1 ..1
0 ..1
0 ..1
19
CDA Header
<clinical_document_header>
<id EX="a123" RT="2.16.840.1.113883.3.933"/>
<document_type_cd V="11488-4"
S="2.16.840.1.113883.6.1" DN="Consultation note"/>
<document_relationship>
<document_relationship.type_cd V="RPLC"/>
<related_document>
<id EX="a234" RT="2.16.840.1.113883.3.933"/>
</related_document>
</document_relationship>
<patient_encounter>
<id EX="KPENC1332" RT="2.16.840.1.113883.3.933"/>
X M L E le m e n t N a m e
clinical_document_header
id
document_type_cd
document_relationship
document_
relationship.type_cd
related_document
id
patient_encounter
id
D a ta T y p e
d o cu m en t_ service
II
CE
service_ relatio n ship
CS
service
II
p atient_ enco u nter
II
C a rd in a lity
1 ..1
1 ..1
1 ..1
0 ..*
1 ..1
1 ..1
1 ..1
0 ..1
0 ..1
20
CDA Header
•RIM 0.98 :: CDA Header Information Model
Stak eholder
addr : SET<AD>
phon : SET<TEL>
id : SET<II>
1
Service_relationship
type_cd : CV
Service_actor
type_cd : CV
tmr : IVL<TS>
0..*
signature_cd : CV
function_cd : CD
0..*
0..*
1
1
Service
Organization
nm : SET<ON>
0..*
1
id : SET<II>
service_cd : CD
activity_time : GTS
confidentiality_cd : SET<CV>
0..*
Patient_encounter
id : II
active_tmr : IVL<TS>
0..1 practice_setting_cd : CV
Person
birth_dttm : TS
administrative_gender_cd : CE
1
0..*
0..1
0..*
Service_target
type_cd : CV
tmr : IVL<TS>
Document_service
set_id : II
version_nbr : INT
copy_dttm : TS
origination_dttm : TS
21
CDA Header
•Document information
Stak eholder
addr : SET<AD>
phon : SET<TEL>
id : SET<II>
1
Service_relationship
type_cd : CV
Service_actor
type_cd : CV
tmr : IVL<TS>
0..*
signature_cd : CV
function_cd : CD
0..*
0..*
1
1
Service
Organization
nm : SET<ON>
0..*
1
id : SET<II>
service_cd : CD
activity_time : GTS
confidentiality_cd : SET<CV>
0..*
Patient_encounter
id : II
active_tmr : IVL<TS>
0..1 practice_setting_cd : CV
Person
birth_dttm : TS
administrative_gender_cd : CE
1
0..*
0..1
0..*
Service_target
type_cd : CV
tmr : IVL<TS>
Document_service
set_id : II
version_nbr : INT
copy_dttm : TS
origination_dttm : TS
22
CDA Header
•Encounter data
Stak eholder
addr : SET<AD>
phon : SET<TEL>
id : SET<II>
1
Service_relationship
type_cd : CV
Service_actor
type_cd : CV
tmr : IVL<TS>
0..*
signature_cd : CV
function_cd : CD
0..*
0..*
1
1
Service
Organization
nm : SET<ON>
0..*
1
id : SET<II>
service_cd : CD
activity_time : GTS
confidentiality_cd : SET<CV>
0..*
Patient_encounter
id : II
active_tmr : IVL<TS>
0..1 practice_setting_cd : CV
Person
birth_dttm : TS
administrative_gender_cd : CE
1
0..*
0..1
0..*
Service_target
type_cd : CV
tmr : IVL<TS>
Document_service
set_id : II
version_nbr : INT
copy_dttm : TS
origination_dttm : TS
23
CDA Header
•Service actors
Stak eholder
addr : SET<AD>
phon : SET<TEL>
id : SET<II>
1
Service_relationship
type_cd : CV
Service_actor
type_cd : CV
tmr : IVL<TS>
0..*
signature_cd : CV
function_cd : CD
0..*
0..*
1
1
Service
Organization
nm : SET<ON>
0..*
1
id : SET<II>
service_cd : CD
activity_time : GTS
confidentiality_cd : SET<CV>
0..*
Patient_encounter
id : II
active_tmr : IVL<TS>
0..1 practice_setting_cd : CV
Person
birth_dttm : TS
administrative_gender_cd : CE
1
0..*
0..1
0..*
Service_target
type_cd : CV
tmr : IVL<TS>
Document_service
set_id : II
version_nbr : INT
copy_dttm : TS
origination_dttm : TS
24
CDA Header
•Service targets
Stak eholder
addr : SET<AD>
phon : SET<TEL>
id : SET<II>
1
Service_relationship
type_cd : CV
Service_actor
type_cd : CV
tmr : IVL<TS>
0..*
signature_cd : CV
function_cd : CD
0..*
0..*
1
1
Service
Organization
nm : SET<ON>
0..*
1
id : SET<II>
service_cd : CD
activity_time : GTS
confidentiality_cd : SET<CV>
0..*
Patient_encounter
id : II
active_tmr : IVL<TS>
0..1 practice_setting_cd : CV
Person
birth_dttm : TS
administrative_gender_cd : CE
1
0..*
0..1
0..*
Service_target
type_cd : CV
tmr : IVL<TS>
Document_service
set_id : II
version_nbr : INT
copy_dttm : TS
origination_dttm : TS
25
CDA Header
document information
encounter data
service actors
service targets
26
CDA Header
•XML element identification
Every XML element within a CDA document has an
optional identifier, which must be unique within the
document. The identifier is an XML "ID" data type.
<!ATTLIST Every_CDA_ELEMENT
...
ID ID #IMPLIED
...>
27
CDA Header
•Document identification
(<id>, <set_id>, <version_nbr>, <document_type_cd>)
Every document has a required, globally-unique instance
identifier, <id>, an identifier that remains constant across all
document revisions that derive from a common root,
<set_id>, and a version number, <version_nbr>.
Every document has a required document type code,
<document_type_cd>. The externally-defined vocabulary
domain for <document_type_cd> is drawn from LOINC.
28
CDA Header
•Document time stamps
(<service_tmr>, <encounter_tmr>, <origination_dttm>,
<copy_dttm>, <participation_tmr> )
Some temporal events can be represented as a specific point
in time (indicated by "_dttm" and using the HL7 V3 TS
data type), while other temporal events include time
intervals (indicated by "_tmr" and using the HL7 V3
IVL_TS or GTS data type).
29
CDA Header
•Document relationships
(<document_relationship>, <fulfills_order>)
The CDA Header enables the explicit representation of the
relationship between documents. A clinical document can
append or replace another clinical document.
Documents may be generated in response to one or more
orders. The <fulfills_order> element points to fulfilled
orders.
30
CDA Header
•Encounter data
(<patient_encounter>, <id>, <practice_setting_cd>,
<encounter_tmr>, <service_location>)
Encounter data include a globally-unique identifier, the time
of the encounter, a location, and an optional practice setting
code, which is a categorization of the clinical setting (e.g.
cardiology clinic, primary care clinic, rehabilitation
hospital, skilled nursing facility) in which care is delivered.
31
CDA Header
•Service actors
(<authenticator>, <legal_authenticator>,
<intended_recipient>, <originator>,
<originating_organization>, <transcriptionist>,
<provider>, <service_actor>)
Service actors include those who authenticate the document,
those intended to receive a copy of the document, document
originators and transcriptionists, and health care providers
who participated in the service(s) being documented.
Service actors are capable of and accountable for their
independent decisions.
32
CDA Header
•Service actors (cont.)
33
CDA Header
•Service targets
(<patient>, <originating_device>, <service_target>)
Service targets are physical entities, including living
subjects and inanimate material, that are typically the
object of services being documented. Service targets include
the patient, other significant participants (such as family
members), and those devices that may have originated
portions of the document.
34
CDA Header
•Service targets (cont.)
35
CDA Header
•Localization
(<local_header>, <local_attr>)
The CDA adds markup declarations that enable
localization. The <local_header> element is an optionally
repeating, recursive element tacked on to the end of every
content model. The "descriptor" attribute describes the
element, and the value can be drawn from a local
vocabulary domain. The "ignore" attribute tells the
receiver to ignore just the local_header tag
(ignore="markup"), or to ignore the local_header tag and
all contained content (ignore="all"). The "render" attribute
indicates how the sender would render the contents. The
value can be drawn from a local vocabulary domain.
36
CDA Header
•Localization (cont.)
<!ELEMENT local_header
(#PCDATA |
local_header |
local_attr)* >
<!ATTLIST local_header
<!ELEMENT authenticator
(
authenticator.type_cd,
participation_tmr,
signature_cd,
person,
local_header*
)>
ignore (all | markup) "markup"
descriptor CDATA #IMPLIED
render CDATA #IMPLIED
ID ID #IMPLIED
xml:lang NMTOKEN #IMPLIED >
<!ELEMENT local_attr EMPTY>
<!ATTLIST local_attr
name NMTOKEN #REQUIRED
value CDATA #REQUIRED
ID ID #IMPLIED
xml:lang NMTOKEN #IMPLIED>
37
CDA Header
•Sample CDA document*
<clinical_document_header>
<id EX="a123" RT="2.16.840.1.113883.3.933"/>
<document_type_cd V="11488-4" S="2.16.840.1.113883.6.1"
DN="Consultation note"/>
<origination_dttm V="2000-04-07"/>
<document_relationship>
<document_relationship.type_cd V="RPLC"/>
<related_document>
<id EX="a234" RT="2.16.840.1.113883.3.933"/>
</related_document>
</document_relationship>
<patient_encounter>
<id EX="KPENC1332" RT="2.16.840.1.113883.3.933"/>
<encounter_tmr V="2000-04-07"/>
</patient_encounter>
<local_header ignore="all" descriptor="MyLocalTag">
... extra stuff that is only used locally ...
</local_header>
</clinical_document_header>
...
* Note that the exact representation is contingent on the outcome of the HL7 V3 data
38
type DTD ballot.
CDA Level One Body
•Overview
The CDA Level One Body is comprised of sections or a
single non-XML block. A section can contain "structures",
nested section's, and codes. CDA structures contain
"entries".
Document analysis was used to articulate requirements for
the CDA Level One Body. These are expressed in XML
using industry-standard constructs. The structural
components themselves are not part of RIM 0.98.
Where CDA entries are derivable from the RIM, they have
an XML representation that follows the style used for the
CDA Header.
39
CDA Level One Body
•Overview (cont.)
CDA "structures"
CDA "entries"
40
CDA Level One Body
•Shared XML Attributes
These attributes are assigned to all XML elements in the
CDA Level One Body. Their values are inherited by nested
content, unless overridden.
<!ATTLIST Every_CDA_Body_Element
...
ID ID #IMPLIED
confidentiality IDREFS #IMPLIED
originator IDREFS #IMPLIED
xml:lang NMTOKEN #IMPLIED
>
41
CDA Level One Body
•Non_xml body
The CDA <non_xml> container represents a document body
that is in some format other than XML. CDA's <non_xml>
uses the HL7 V3 Encoded Data data type to reference data
that is stored externally to the CDA Level One document (as
opposed to encapsulating the data within the CDA
document itself).
42
CDA Level One Body
•Captions
The CDA <caption> is a label for a container. The <caption>
element can occur in a <section>, <paragraph>, <list>,
<item>, or <table> element. A <caption> contains plain text
and may contain links, and can be coded using the
<caption_cd> element. The vocabulary domain for
<caption_cd> is externally-defined by LOINC.
43
CDA Level One Body
•CDA "structures"
(<paragraph>, <list>, <table>)
CDA "structures"
CDA "entries"
44
CDA Level One Body
•CDA "structures" (cont.)
Structures have optional captions.
A <paragraph> contains CDA "entries".
A <list> contains one or more <item>'s. An <item> contains
entries and nested structures.
The CDA <table> is a modification of the strict XHTML
table model. In CDA Level One, any information can be
presented as a table. The table markup is for presentation
purposes only and, unlike a database table, does not possess
meaningful field names.
45
CDA Level One Body
•CDA "structures" (cont.)
46
CDA Level One Body
•CDA "entries"
(character data, <link>, <coded_entry>, <content>,
<observation_media>, <local_markup>)
CDA "structures"
CDA "entries"
47
CDA Level One Body
•Link
The CDA <link> is a generic referencing mechanism based
on the HTML anchor tag. Multimedia that is part of the
attestable content of the document requires the use of
<observation_media>. Multimedia that is simply referenced
should use <link>.
<!ELEMENT link (link_html) >
<!ELEMENT link_html (#PCDATA) >
<!ATTLIST link_html
name
CDATA
#IMPLIED
href
CDATA
#IMPLIED
rel
CDATA
#IMPLIED
rev
CDATA
#IMPLIED
title
CDATA
#IMPLIED >
48
CDA Level One Body
•Coded_entry
The CDA <coded_entry> uses the HL7 V3 Concept
Descriptor data type to insert codes from HL7-recognized
coding schemes into CDA documents. Where there are no
suitable HL7-recognized codes available, locally-defined
codes can be used.
<content>
Asthma, with prior smoking history. Difficulty
weaning off steroids. Will try gradual taper.
<coded_entry>
<coded_entry.value V="D2-51000"
S="2.16.840.1.113883.6.5" DN="Asthma"/>
</coded_entry>
</content>
49
CDA Level One Body
•Content
The <content> element nests recursively, enabling wrapping
a string of text down to as small a chunk as desired. These
<content> elements can serve as anchors to be referenced by
<coded_entry> elements to indicate the original text that
supports the use of a code.
<content>
<content ID="String001">Asthma</content>,
with prior smoking history. Difficulty
weaning off steroids. Will try gradual taper.
<coded_entry>
<coded_entry.value ORIGTXT="String001"
V="D2-51000" S="2.16.840.1.113883.6.5"
DN="Asthma"/>
</coded_entry>
</content>
50
CDA Level One Body
•Observation_media
The <observation_media> element, derived from the RIM
Observation class, represents media that is logically part of
a CDA document, but is stored outside the document and
incorporated by reference (using the HL7 V3 Encoded Data
data type).
Physical Exam
Erythematous rash,
palmar surface, left
index finger.
<content>
Erythematous rash, palmar
surface, left index finger.
<observation_media>
<observation_media.value
MT="image/jpeg">
<REF V="rash.jpeg"/>
</observation_media.value>
</observation_media>
</content>
51
CDA Level One Body
•Localization
The implementation of localization in the CDA Level One
Body using the <local_markup> element parallels the
approach used in the CDA Header.
52
Outline
•Objectives
•Overview of August 2000 Clinical Document
Architecture ballot proposal
•Introduction
•What is the CDA?
•The "A" in "CDA"
•Relationship of CDA to HL7 Messaging Standards
•Technical Specifications
•CDA Header
•CDA Body
•HL7 V3 Data Types
53
Descargar

No Slide Title