CDA Framework - Final

1 Version 3 Standard:
2 Clinical Document
3 Architecture Framework
4
5 Release 1.0
6
7
Chair/Editor: Liora Alschuler, alschuler.spinosa
Robert H. Dolin, MD, Kaiser Permanente
Editor: Sandy Boyer, BSP, Consultant
Calvin Beebe, Mayo Clinic
Chair: Paul V. Biron, MLIS, Kaiser Permanente
Rachael Sokolowski, Magnolia Technologies
8
9 Table of Contents
10
11 1 INTRODUCTION..................................................................................................................................6
12 1.1 WHAT IS THE CDA?.........................................................................................................................6
13 1.1.1 Key aspects of the CDA............................................................................................................6
14 1.1.2 Scope of the CDA......................................................................................................................6
15 1.2 GOALS AND DESIGN PRINCIPLES......................................................................................................7
16 1.2.1 Goals.........................................................................................................................................7
17 1.2.2 Design Principles.....................................................................................................................7
18 1.3 SCOPE OF THE TECHNICAL SPECIFICATIONS IN THIS DOCUMENT......................................................7
19 2 CDA CONCEPTS...................................................................................................................................7
20 2.1 CDA DOCUMENT..............................................................................................................................7
21 2.2 DOCUMENT SCHEMAS AND DOCUMENT TYPE DEFINITIONS..............................................................8
22 2.3 DOCUMENT ARCHITECTURE..............................................................................................................8
23 2.4 SECURITY, CONFIDENTIALITY, AND DATA INTEGRITY.....................................................................9
24 2.5 RELATIONSHIP OF THE CDA TO HL7 MESSAGING STANDARDS......................................................9
25 2.5.1 CDA Documents and document management..........................................................................9
26 2.5.2 Sending a CDA document in a V2.x message.........................................................................10
27 2.5.3 Sending a CDA document in a V3 message............................................................................11
28 3 CDA TECHNICAL SPECIFICATIONS...........................................................................................13
29 3.1 INTRODUCTION................................................................................................................................13
30 3.2 CDA HEADER.................................................................................................................................14
1 Health Level Seven, © 2000. All rights reserved 1
2
1 3.2.1 Overview.................................................................................................................................14
2 3.2.2 Technical details.....................................................................................................................14
3 3.2.2.1 Common XML attributes.................................................................................................................14
4 3.2.2.1.1 XML element identification......................................................................................................14
5 3.2.2.2 Document information.....................................................................................................................15
6 3.2.2.2.1 Document identification............................................................................................................15
7 3.2.2.2.2 Document time stamps..............................................................................................................15
8 3.2.2.2.3 Document confidentiality..........................................................................................................16
9 3.2.2.2.4 Document relationships.............................................................................................................16
10 3.2.2.3 Encounter data.................................................................................................................................17
11 3.2.2.4 Service actors...................................................................................................................................18
12 3.2.2.4.1 People responsible for a clinical document...............................................................................18
13 3.2.2.4.2 Authenticators...........................................................................................................................19
14 3.2.2.4.3 Intended recipients....................................................................................................................19
15 3.2.2.4.4 Originators................................................................................................................................20
16 3.2.2.4.5 Transcriptionist.........................................................................................................................20
17 3.2.2.4.6 Healthcare providers.................................................................................................................20
18 3.2.2.4.7 Other service actors...................................................................................................................21
19 3.2.2.5 Service targets..................................................................................................................................22
20 3.2.2.5.1 Patient.......................................................................................................................................22
21 3.2.2.5.2 Originating device.....................................................................................................................22
22 3.2.2.5.3 Other service targets..................................................................................................................23
23 3.2.2.6 Localization.....................................................................................................................................23
24 3.2.3 Hierarchical Description........................................................................................................25
25 3.2.4 XML Document Type Definition.............................................................................................33
26 3.3 CDA LEVEL ONE BODY.................................................................................................................48
27 3.3.1 Overview.................................................................................................................................48
28 3.3.2 Technical details.....................................................................................................................48
29 3.3.2.1 Shared XML attributes.....................................................................................................................48
30 3.3.2.1.1 XML element identification......................................................................................................48
31 3.3.2.1.2 Confidentiality..........................................................................................................................48
32 3.3.2.1.3 Originators................................................................................................................................48
33 3.3.2.1.4 Language..................................................................................................................................49
34 3.3.2.2 Document body and sections...........................................................................................................49
35 3.3.2.2.1 Document body.........................................................................................................................49
36 3.3.2.2.2 Document sections....................................................................................................................50
37 3.3.2.2.3 Non_xml body..........................................................................................................................51
38 3.3.2.3 Document Structures........................................................................................................................52
39 3.3.2.3.1 Paragraphs................................................................................................................................52
40 3.3.2.3.2 Lists and list items....................................................................................................................52
41 3.3.2.3.3 Tabular material........................................................................................................................53
42 3.3.2.4 Document Entries............................................................................................................................54
43 3.3.2.4.1 Character data...........................................................................................................................54
44 3.3.2.4.2 Content.....................................................................................................................................54
45 3.3.2.4.3 Links.........................................................................................................................................55
46 3.3.2.4.4 Coded entries............................................................................................................................56
47 3.3.2.4.5 Observation media....................................................................................................................59
48 3.3.2.4.6 Localization..............................................................................................................................61
49 3.3.3 XML Document Type Definition.............................................................................................62
50 4 GLOSSARY..........................................................................................................................................73
51 5 APPENDICES (NON-NORMATIVE)...............................................................................................75
52 5.1 SAMPLES.........................................................................................................................................75
53 5.1.1 Sample document....................................................................................................................75
54 5.1.2 Sample CDA document ..........................................................................................................77
55 5.1.2.1 Sample CDA document with rich markup.......................................................................................77
56 5.1.2.2 Sample CDA document with minimal markup.................................................................................81
57 5.1.3 Sample XSLT stylesheet..........................................................................................................85
58 5.1.4 HTML rendition of sample CDA document............................................................................93
2
1 5.2 CDA LEVEL ONE BODY UML MODEL...........................................................................................96
2 5.3 CDA IMPLEMENTATION NOTES......................................................................................................99
3 5.3.1 Tables.....................................................................................................................................99
4 5.3.2 Validation and conformance..................................................................................................99
5 5.3.3 Localization..........................................................................................................................100
6 5.3.4 Transformation issues..........................................................................................................100
7 5.3.5 Representing authenticated content.....................................................................................101
8 5.4 REFERENCES.................................................................................................................................102
9 5.5 ACKNOWLEDGEMENTS..................................................................................................................103
10
11
12
13
2
1 Table of Figures
2
3 FIGURE 1. ILLUSTRATION OF CDA DOCUMENT HIERARCHY...........................................................................9
4 FIGURE 2. EXAMPLE OF A CDA DOCUMENT IN AN MDM (EVENT T02) MESSAGE........................................11
5 FIGURE 3. EXAMPLE OF A CDA DOCUMENT IN A VERSION 3 MESSAGE........................................................12
6 FIGURE 4. XML ID ATTRIBUTE......................................................................................................................15
7 FIGURE 5. XML CONTENT MODEL OF <LOCAL_HEADER>..............................................................................24
8 FIGURE 6. XML CONFIDENTIALITY ATTRIBUTE..............................................................................................48
9 FIGURE 7. XML ORIGINATOR ATTRIBUTE.......................................................................................................49
10 FIGURE 8. XML XML:LANG ATTRIBUTE.........................................................................................................49
11 FIGURE 9. XML CONTENT MODEL OF <BODY>..............................................................................................50
12 FIGURE 10. XML CONTENT MODEL OF <SECTION>........................................................................................50
13 FIGURE 11. XML CONTENT MODEL OF <CAPTION>.......................................................................................51
14 FIGURE 12. XML CONTENT MODEL OF <NON_XML>.....................................................................................52
15 FIGURE 13. XML CONTENT MODEL OF <PARAGRAPH>..................................................................................52
16 FIGURE 14. XML CONTENT MODEL OF <LIST> AND <ITEM>.........................................................................53
17 FIGURE 15. CHANGES TO THE STRICT XHTML TABLE MODEL IN CDA........................................................54
18 FIGURE 16. XML CONTENT MODEL OF <CONTENT>......................................................................................55
19 FIGURE 17. XML CONTENT MODEL OF <LINK> AND <LINK_HTML>.............................................................56
20 FIGURE 18. XML CONTENT MODEL OF <CODED_ENTRY>..............................................................................57
21 FIGURE 19. REFERENCING ORIGINAL TEXT WITH <CODED_ENTRY>..............................................................58
22 FIGURE 20. XML CONTENT MODEL OF <OBSERVATION_MEDIA>..................................................................60
23 FIGURE 21. XML CONTENT MODEL OF <LOCAL_MARKUP>...........................................................................61
24
25
2
1 Table of Tables
2
3 TABLE 1. VOCABULARY DOMAIN FOR <EXAMPLE_CODED_CDA_COMPONENT> (CWE)..............................13
4 TABLE 2. EXAMPLE CONCEPTS FOR <EXAMPLE_CODED_CDA_COMPONENT> (CWE)..................................14
5 TABLE 3. EXAMPLE CONCEPTS FOR <DOCUMENT_TYPE_CD> (CWE)...........................................................15
6 TABLE 4. VOCABULARY DOMAIN FOR <CONFIDENTIALITY_CD> (CWE).......................................................16
7 TABLE 5. VOCABULARY DOMAIN FOR <DOCUMENT_RELATIONSHIP.TYPE_CD> (CNE)................................17
8 TABLE 6. VOCABULARY DOMAIN FOR <FULFILLS_ORDER.TYPE_CD> (CNE)................................................17
9 TABLE 7. VOCABULARY DOMAIN FOR <PRACTICE_SETTING_CD> (CWE).....................................................18
10 TABLE 8. VOCABULARY DOMAIN FOR <PERSON_NAME.TYPE_CD> (CWE)...................................................18
11 TABLE 9. VOCABULARY DOMAIN FOR <AUTHENTICATOR.TYPE_CD> (CNE).................................................19
12 TABLE 10. VOCABULARY DOMAIN FOR <LEGAL_AUTHENTICATOR.TYPE_CD> (CNE)..................................19
13 TABLE 11. VOCABULARY DOMAIN FOR <SIGNATURE_CD> (CNE)................................................................19
14 TABLE 12. VOCABULARY DOMAIN FOR <INTENDED_RECIPIENT.TYPE_CD> (CNE).......................................20
15 TABLE 13. VOCABULARY DOMAIN FOR <ORIGINATOR.TYPE_CD> (CNE)......................................................20
16 TABLE 14. VOCABULARY DOMAIN FOR <ORIGINATING_ORGANIZATION.TYPE_CD> (CNE)..........................20
17 TABLE 15. VOCABULARY DOMAIN FOR <TRANSCRIPTIONIST.TYPE_CD> (CNE)...........................................20
18 TABLE 16. VOCABULARY DOMAIN FOR <PROVIDER.TYPE_CD> (CNE)..........................................................21
19 TABLE 17. VOCABULARY DOMAIN FOR <FUNCTION_CD> (CWE).................................................................21
20 TABLE 18. VOCABULARY DOMAIN FOR <SERVICE_ACTOR.TYPE_CD> (CWE)..............................................22
21 TABLE 19. VOCABULARY DOMAIN FOR <PATIENT.TYPE_CD> (CNE)............................................................22
22 TABLE 20. VOCABULARY DOMAIN FOR <ADMINISTRATIVE_GENDER_CD> (CWE).......................................22
23 TABLE 21. VOCABULARY DOMAIN FOR <ORIGINATING_DEVICE.TYPE_CD> (CNE).......................................23
24 TABLE 22. VOCABULARY DOMAIN FOR <RESPONSIBILITY.TYPE_CD> (CWE)...............................................23
25 TABLE 23. VOCABULARY DOMAIN FOR <SERVICE_TARGET.TYPE_CD> (CWE).............................................23
26 TABLE 24. HIERARCHICAL DESCRIPTION OF CDA HEADER...........................................................................25
27 TABLE 25. EXAMPLE CONCEPTS FOR <CAPTION_CD> (CWE)........................................................................50
28 TABLE 26. EXAMPLE CONCEPTS FOR <CODED_ENTRY.VALUE>.....................................................................56
29 TABLE 27. HIERARCHICAL DESCRIPTION OF <OBSERVATION_MEDIA>..........................................................59
30
31
2
1 1 Introduction
2 1.1 What is the CDA?

3 The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the
4 structure and semantics of "clinical documents"1 for the purpose of exchange. A clinical document contains
5 observations and services and has the following characteristics:
6
7  Persistence – A clinical document continues to exist in an unaltered state, for a time period defined by
8 local and regulatory requirements.2
9
10  Stewardship – A clinical document is maintained by a person or organization entrusted with its care.
11
12  Potential for authentication - A clinical document is an assemblage of information that is intended to
13 be legally authenticated.
14
15  Wholeness - Authentication of a clinical document applies to the whole and does not apply to portions
16 of the document without the full context of the document.
17
18  Human readability – A clinical document is human readable.
19
20 A CDA document is a defined and complete information object that can include text, images, sounds, and
21 other multimedia content.
22 1.1.1 Key aspects of the CDA

23 Key aspects of the CDA include:
24
25  CDA documents are encoded in Extensible Markup Language (XML).
26  CDA documents derive their meaning from the HL7 Reference Information Model (RIM 3) and use the
27 HL7 Version 3 Data Types, Release 1.
28  The complete CDA will include a hierarchical set of document specifications. This hierarchy is
29 referred to as an "architecture".
30
31 Many of the standards that have contributed to the development of the CDA are listed in 5.4 References
32 and general acknowledgments are given in 5.5 Acknowledgements.
33 1.1.2 Scope of the CDA

34 The scope of the CDA is the standardization of clinical documents for exchange.
35
36 The data format of clinical documents outside of the exchange context is not addressed in this specification.
37 The clinical content of CDA documents is defined in the RIM. The CDA does not model clinical content,
38 but does standardize the markup of the structure and semantics needed for exchange of clinical documents.
39
40 CDA documents can be transmitted in HL7 messages designed to transfer clinical documents. The
41 specification for such messages is outside the scope of the CDA, although this standard does specify how to
1 1
Terms defined in the glossary are cited in double quotes on first mention within this document. Acronyms
2 are not quoted but are expanded in the glossary.
3 2
There is a distinct scope of persistence for a clinical document, independent of the persistence of any
4 XML-encoded CDA document instance.
5 3
The Clinical Document Architecture is based on the HL7 Reference Information Model, Version 0.98,
6 which reflects agreements made through and including the July 2000 RIM Harmonization meeting.
8
1 package CDA documents within HL7 messages (see 2.5.2 Sending a CDA document in a V2.x message
2 and 2.5.3 Sending a CDA document in a V3 message).
3
4 The CDA does not specify the creation or management of documents, only their exchange markup.
5 Document management is critically interdependent with the CDA specifications, but the specification of
6 document management messages is outside the scope of the CDA. (For more on this, see 2.5.1 CDA
7 Documents and document management).
8 1.2 Goals and Design Principles
9 1.2.1 Goals
10 The goals of the CDA are:
11 1. Give priority to delivery of patient care.
12 2. Allow cost effective implementation across as wide a spectrum of systems as possible.
13 3. Support exchange of human-readable documents between users, including those with different levels
14 of technical sophistication.
15 4. Promote longevity of all information encoded according to this architecture.
16 5. Enable a wide range of post-exchange processing applications.
17 6. Be compatible with a wide range of document creation applications.
18 7. Promote exchange that is independent of the underlying transfer or storage mechanism.
19 8. Prepare the design reasonably quickly.
20 9. Enable policy-makers to control their own information requirements without extension to this
21 specification.
22 1.2.2 Design Principles

23 A number of design principles follow from consideration of the above goals.
24 1. This architecture must be compatible with XML and the HL7 RIM.
25 2. Technical barriers to use of the architecture should be minimized.
26 3. The architecture specifies the schemas required for exchange.
27 4. The architecture should impose minimal constraints or requirements on document structure and content
28 required for exchange.
29 5. The architecture must be scalable to accommodate fine-grained markup such as highly structured text
30 and coded data.
31 6. Document specifications based on this architecture should accommodate such constraints and
32 requirements as supplied by appropriate professional, commercial, and regulatory agencies.
33 7. Document specifications for document creation and processing, if intended for exchange, should map
34 to this exchange architecture.
35 8. CDA documents must be human readable using widely-available and commonly-deployed XML-
36 aware browsers and print drivers and a generic CDA style sheet written in a standard style sheet
37 language
38 10. Use open standards.
39 1.3 Scope of the technical specifications in this document

40 This document presents the CDA concepts and architecture that comprise the complete CDA framework,
41 and presents the technical specifications for the root of the architecture known as "CDA Level One". CDA
42 Level One specifies a complete document structure, and as such can stand alone, prior to the completion of
43 the specification of the complete architecture.
2
1 2 CDA Concepts
2 2.1 CDA Document

3 A CDA document is comprised of a header, referred to as the "CDA Header", and a body, which at CDA
4 Level One is referred to as the "CDA Level One Body". The CDA Header identifies and classifies the
5 document and provides information on authentication, the encounter, the patient, and the provider. The
6 body contains the clinical report.
7
8 The CDA Level One Body is comprised of nested containers. There are four types of containers: sections,
9 paragraphs, lists, and tables. Containers have contents and optional captions. Contents include plain text,
10 links, and multimedia.
11
12 Both the header and the body use the data types defined in the HL7 RIM.
13 2.2 Document schemas and document type definitions

14 A "schema" is a specification or set of constraints for a class of documents. A "document type definition"
15 (DTD) is one type of schema used for both SGML and XML documents. At this writing, the DTD is the
16 only standardized schema for markup languages. The World Wide Web Consortium (W3C) is moving
17 toward standardization of "XML Schemas", which represent a more expressive way of specifying the
18 constraints for a class of documents. As soon as these are adopted and implemented, the CDA will adopt
19 XML Schemas. This specification is expressed using DTDs.
20
21 CDA Level One is specified by the CDA Level One DTD. This DTD incorporates the CDA Header DTD,
22 which is defined as an XML entity. The CDA Header DTD incorporates the HL7 Version 3 Data Types,
23 Release 1 DTD, also defined as an XML entity. A CDA Level One document references the CDA Level
24 One DTD.
25
26 Terminology note: The term "document type" is ambiguous. In XML, "document type" is typically equated
27 with "DTD". In the RIM, "document type" is equated with the type code of a document (such as the code
28 for a "Consultation Note" or a "Discharge Summary"). This document uses "DTDs" when referring to
29 XML document types and uses "document type codes" when referring to the type code of a document, and
30 avoids the phrase "document type".
31 2.3 Document architecture

32 The CDA is envisioned as an extensible and hierarchical set of document specifications that, in aggregate,
33 define the semantics and structural constraints necessary for the representation of clinical documents. This
34 set of specifications is called an architecture to distinguish it from a specification based on a single
35 document schema or a set of document schemas with ambiguous or undefined relationships.
36
37 In this architecture, relationships between document specifications are defined by specialization and
38 inheritance. Use of an architecture avoids imposition of unacceptably rigid constraints on local document
39 implementation and facilitates interoperability.
40
41 "Levels" within the architecture represent a quantum set of specializations, to which further constraints can
42 be applied:
43  CDA Level One is the root of the hierarchy and is the most general document specification. RIM
44 classes are used in the specification of the document header, while the document body is largely
45 structural, although terms from controlled vocabulary can be applied.
46  "CDA Level Two" will be a specialization of CDA Level One. It will constrain the set of allowable
47 structures and semantics based on document type code, and may add additional markup.
48  "CDA Level Three" will be a specialization of CDA Level Two that will add additional markup,
49 enabling clinical content to be formally expressed to the extent that is it modeled in the RIM.
50
2
1 Levels are extensible laterally – that is, the markup granularity of all schemas within a given level is
2 roughly the same but each schema expresses a different set of constraints.
3
4 The CDA Level One DTD permits use of any valid document type code and section code, but there is only
5 one CDA Level One DTD for all types of clinical documents, regardless of content. Above Level One,
6 there will be distinct XML DTDs for different types of clinical documents. Thus, at Level One, it is
7 possible to differentiate a "Consultation Note" from a "Discharge Summary" because the two will have
8 distinct document type code values in the document instance. Above Level One, it will be possible to
9 specify additional constraints on a document based on whether it is a "Consultation Note" or a "Discharge
10 Summary" by creating distinct XML DTDs for each document type code.
11
12 An illustration of one possible hierarchy of CDA DTDs is shown here4:
13
14 Figure 1. Illustration of CDA Document Hierarchy
15 CDA Level One

16 CDA Level Two
17 Level Two :: Progress Note
18 Level Two :: Cardiology Progress Note
19 Level Two :: Endocrinology Progress Note
20 Level Two :: Diabetes Mellitus Progress Note
21 CDA Level Three
22 Level Three :: Progress Note
23 Level Three :: Cardiology Progress Note
24 Level Three :: Endocrinology Progress Note
25 Level Three :: Diabetes Mellitus Progress Note
26
27 Note that the clinical content of CDA documents is invariant across all levels of the architecture. Each level
28 makes possible the computer-processible expression of richer shared semantics. Thus a single report can be
29 marked up as a Level One, a Level Two, or a Level Three document and its clinical content will not vary.
30 What will vary between the levels are:
31
32  The degree to which clinical content can be machine processible in an exchange context.
33  The degree to which clinical document specifications can impose constraints on content.
34
35 2.4 Security, Confidentiality, and Data Integrity

36 Application systems sending and receiving CDA documents are responsible for meeting all legal
37 requirements for document authentication, confidentiality, and retention (see 2.5.1 CDA Documents and
38 document management). For communications over public media, cryptographic techniques for
39 source/recipient authentication and secure transport of encapsulated documents may be required, and
40 should be addressed with commercially available tools outside the scope of this standard.
41
42 The CDA does provide confidentiality status information to aid application systems in managing access to
43 sensitive data. Confidentiality status may apply to the entire document (see 3.2.2.2.3 Document
44 confidentiality) or to specified segments of the document (see 3.3.2.1.2 Confidentiality).
45 2.5 Relationship of the CDA to HL7 Messaging Standards

46 A CDA document is a defined and complete information object that can exist outside of a messaging
47 context and/or can be a MIME-encoded payload within an HL7 message. Thus, the CDA complements
48 HL7 messaging specifications.
1 4
An ontology of clinical document type codes is under development by a consortium of standards and
2 vocabulary organizations. See the draft paper, “Proposal for an Ontology for Exchange of Clinical
3 Documents” published July 19, 2000 at http://www.hl7.org/special/dotf/dotf.htm.
5
1 2.5.1 CDA Documents and document management
2 Clinical documents can be revised, and they can be appended to existing documents. Ideally, an updated
3 document would declare itself as obsolete, and would contain an explicit pointer to a more recent version.
4 This would lessen the chances of a healthcare provider basing treatment decisions on erroneous or
5 incomplete data.
6
7 In practice, however, it is impossible to guarantee an explicit forward pointer from an outdated version to
8 the newer version. Without a process that tracks the chain of custody of clinical documents and all of their
9 copies, there can be no way to guarantee that a clinical document being viewed has not been subsequently
10 revised.
11
12 To minimize the risk of viewing superseded information, there is a critical interdependence between
13 clinical documents and document management systems. If CDA documents are viewed outside the context
14 of a document management system, it cannot be known with certainty whether or not the viewed document
15 has been revised. HL7 messages that carry CDA documents (such as the MDM messages in HL7 V2.x)
16 convey critical contextual information that ensures accurate viewing of clinical data.
17 2.5.2 Sending a CDA document in a V2.x message

18 From the perspective of a V2.x message, a CDA document is a multimedia object, to be exchanged as a
19 Multipurpose Internet Mail Extensions (MIME, RFC 2046) package, encoded as an encapsulated data type
20 (ED). We name our MIME types per the recommendations in the Internet Draft (draft RFC) XML Media
21 Types, (http://www.imc.org/draft-murata-xml).
22
23 CDA documents are to be exchanged in the OBX segment, in any message that can exchange documents
24 (such as MDM and ORU). Within the OBX segment, the MIME package is encoded as a V2.x
25 encapsulated data type. The value of OBX.2 (Field 00570 Value Type) should be set to "ED".
26
27 OBX 5 (Field 00573 Observation Value) contains the MIME package, encoded as an encapsulated data
28 type. The components of the data type in OBX.5 should be valued as follows:
29
30  Set the value of the 2nd component (type of data) to equal "multipart".
31
32  Set the value of the 3rd component (data subtype) to equal "x-hl7-cda-level-one".
33
34  Set the value of the 4th component (encoding) to equal "A". (Note that a MIME package is not itself
35 Base64-encoded. Rather, entities within the MIME package are Base64-encoded. A MIME package is
36 sent as ASCII text. Therefore, the correct value for the 4th component of the encapsulated data type is
37 "A", not "Base64".)
38
39  Set the value of the 5th component (data) to equal the MIME package itself. Every entity within the
40 MIME package must be Base64-encoded. As stated in HL7 V2.3.1 (Chapter 2, Section 2.8.16.5
41 ED.Data), "the data component must be scanned before transmission for HL7 delimiter characters (and
42 other non-printing ASCII or non-ASCII characters such as LineFeed), and any found must be escaped
43 by using the HL7 escape sequences defined in Section 2.9 'Use of escape sequences in text fields'. On
44 the receiving application, the data field must be de-escaped after being parsed". As a result, CR/LF
45 sequences required in the MIME package need to be escaped (i.e., converted to "\X0D0A\") prior to
46 transmission. The content type of the first MIME entity is set to "application/x-hl7-cda-level-
47 one+xml", and should contain the CDA document itself. Multimedia objects referenced by the CDA
48 document that need to be transmitted with the CDA document are to be placed in successive entities of
49 the MIME package.
50
2
1 Figure 2. Example of a CDA document in an MDM (event T02) message.
2 MSH|...
3 EVN|...
4 PID|...
5 PV1|...
6 TXA|...
7 OBX|1|ED|11492-6^History and Physical^LN||

8 ^multipart^x-hl7-cda-level-one^A^
9 MIME-Version: 1.0
10 Content-Type: multipart/mixed; boundary="HL7-CDA-boundary"
11 Content-Transfer-Encoding: Base64
12 --HL7-CDA-boundary
13 Content-Type: application/x-hl7-cda-level-one+xml
14
15 ... Base64-encoded CDA document ...
16
18 Content-Type: image/JPEG
19
20 ... Base64 image ...
21
22 --HL7-CDA-boundary--
23 |...
24 2.5.3 Sending a CDA document in a V3 message

25 From the perspective of a V3 message, a CDA document is a multimedia object, to be exchanged as a
26 MIME package, encoded as an encoded data type (ED). We name our MIME types per the
27 recommendations in the Internet Draft (draft RFC) for XML Media Types, (http://www.imc.org/draft-
28 murata-xml).
29
30 CDAdocuments can be exchanged in any message that can exchange documents. The Service.txt RIM
31 attribute contains the MIME package, encoded as an encoded data type. The components of the data type
32 should be valued as follows:
33
34  Set the value of the ED.media_descriptor to equal "multipart/x-hl7-cda-level-one".
35
36  Set the value of ED.data to equal the MIME package itself. Every entity within the MIME package
37 must be Base64-encoded. XML delimiters that occur within MIME boundary identifiers must be
38 escaped, using standard XML escaping rules. The content type of the first MIME entity is set to
39 "application/x-hl7-cda-level-one+xml", and should contain the CDA document itself. Multimedia
40 objects referenced by the CDA document that need to be transmitted with the CDA document are to be
41 placed in successive entities of the MIME package.
2
1
2 Figure 3. Example of a CDA document in a Version 3 message.5
3 <someMessage>
4 <Service.service_cd V="11488-4"
5 S="2.16.840.1.113883.6.1" DN="Consultation note"/>
6 <Service.txt MT="multipart/x-hl7-cda-level-one">
7 MIME-Version: 1.0
8 Content-Type: multipart/mixed; boundary="HL7-CDA-boundary"
9 Content-Transfer-Encoding: Base64
11 Content-Type: application/x-hl7-cda-level-one+xml
12
13 ... Base64-encoded CDA document ...
14
16 Content-Type: image/JPEG
17
18 ... Base64 image ...
19
20 --HL7-CDA-boundary--
21 </Service.txt>
22 </someMessage>
1 5
Note that the exact representation is contingent on the outcome of the HL7 Version 3 Data Types, Release
2 1 DTD ballot.
4
1 3 CDA Technical Specifications
2 3.1 Introduction
3 As noted above, CDA Level One is specified by the CDA Level One DTD. This DTD incorporates the
4 CDA Header DTD, which is defined as an XML entity. The CDA Header DTD incorporates the HL7
5 Version 3 Data Types, Release 1 DTD, also defined as an XML entity. A CDA Level One document
6 references the CDA Level One DTD.
7
8 Technically, CDA Level One is specified by three components:
9
10  The CDA Header is specified by the CDA Header DTD which is derived from a Hierarchical
11 Description (HD), using a method that closely parallels the V3 Message Development Framework
12 (see 5.4 References).
13  The CDA Level One Body is specified in the CDA Level One DTD and is derived from document
14 analysis, building on the modeling employed by document markup standards.
15  The HL7 Version 3 Data Types, Release 1 DTD is an XML implementation of the abstract data
16 type specification used by both the CDA and the HL7 Version 3 message specifications. 6
17
18 The CDA element <levelone>7 is the root element of a CDA Level One document. The <levelone>
19 element, declared in the CDA Level One DTD, contains a <clinical_document_header> and a <body>. The
20 details of <clinical_document_header> are explained in the next section (see 3.2 CDA Header), followed
21 by the details of the <body> (see 3.3 CDA Level One Body).
22
23 Vocabulary domains represent value sets for coded CDA components. These domains can include HL7-
24 defined concepts or can be drawn from HL7-recognized coding systems such as LOINC or SNOMED.
25 Vocabulary domains have a coding strength that can be "Coded, No Extensions" (CNE), in which case the
26 only allowable values for the CDA component are those in the vocabulary domain; or "Coded, With
27 Extensions" (CWE), in which case values other than those in the vocabulary domain (such as local codes)
28 can be used if necessary8. Every vocabulary domain has a unique HL7-assigned identifier, and every
29 concept within a vocabulary domain has a unique code. A coded CDA component may constrain its use of
30 an associated vocabulary domain to a stated subset.
31
32 Where a coded CDA component is associated with an HL7-defined vocabulary domain, the standard
33 specifies the coding strength (CWE vs. CNE) and enumerates the allowable concepts with a code, display
34 name, and definition for each concept, as shown in the following example:
35
36 Table 1. Vocabulary domain for <example_coded_CDA_component> (CWE)
Code Display Name Definition
G go To proceed.
S stop To refrain from proceeding.
37
38
1 6
The HL7 Version 3 Data Types, Release 1 abstract specification and the XML implementation of those
2 data types are being separately balloted by the Control Query Technical Committee, in parallel with this
3 document. The data type specification is the work product of an open task force that was charged in
4 Summer 1998 by the Control Query Technical Committee to redesign data types for HL7 Version 3. A
5 working document that contained the specification has been presented to the Technical Steering Committee
6 in 1999. The data type specification has been approved through the RIM harmonization process, and the
7 data types are part of the RIM.
8 7
In the descriptive text of this document, XML element names are surrounded by angle brackets (<>).
9 8
CNE vocabulary domains are enumerated in the XML DTD such that a CDA document containing a value
10 outside the enumerated set is invalid.
12
1 Where a coded CDA component is associated with an externally-defined vocabulary domain, the standard
2 specifies the coding strength (CWE vs. CNE), and an example of allowable concepts of that domain (with a
3 code, display name, and code system identifier for each concept), as shown in the following example:
4
5 Table 2. Example concepts for <example_coded_CDA_component> (CWE)
Code Display Name Code System* Code System Name
18733-6 Ambulatory visit 2.16.840.1.113883.6.1 LOINC
note
18742-7 Arthroscopy report 2.16.840.1.113883.6.1 LOINC
6 *Code systems in HL7 V2.x were identified by HL7-assigned abbreviations. HL7 now assigns ISO identifiers instead
7 of abbreviations.
8 3.2 CDA Header
9 3.2.1 Overview
10 The purpose of the CDA Header is to enable clinical document exchange across and within institutions;
11 facilitate clinical document management; and facilitate compilation of an individual patient's clinical
12 documents into a lifetime electronic patient record.
13
14 There are four logical components of the CDA Header:
15 (1) Document information;
16 (2) Encounter data;
17 (3) Service actors (such as providers); and
18 (4) Service targets (such as patients).
19
20 Document information identifies the document, defines confidentiality status, and describes relationships to
21 other documents and orders. Encounter data describes the setting in which the documented encounter
22 occurred. Service actors include those who authenticate the document, those intended to receive a copy of
23 the document, document originators and transcriptionists, and health care providers who participated in the
24 service(s) being documented. Service targets include the patient, other significant participants (such as
25 family members), and those devices that may have originated portions of the document.
26 3.2.2 Technical details
27 3.2.2.1 Common XML attributes
28 3.2.2.1.1 XML element identification

29 Every XML element within a CDA document has an optional identifier, which must be unique within the
30 document. The identifier is an XML "ID" data type9. Values of XML attributes of type "IDREF" or
31 "IDREFS" must match the value of an ID attribute on some element within the document.
32
1 9
This document discusses both XML data types and HL7 Version 3 Data Types, Release 1. Unless
2 otherwise qualified, the term "data type” refers to HL7 Version 3 Data Types, Release 1.
4
1 Figure 4. XML ID attribute
2 <!ATTLIST Every_CDA_ELEMENT
3 ...
4 ID ID #IMPLIED
5 ...>
6 3.2.2.2 Document information
7 3.2.2.2.1 Document identification

8 Every document has a required, globally-unique instance identifier, <id>; an optional identifier that remains
9 constant across all document revisions that derive from a common original document, <set_id>; and an
10 optional version number, <version_nbr>. These identifiers are useful in the management of addenda and
11 replacements (as described in 3.2.2.2.4 Document relationships). An original report is the first version of a
12 report, and gets a new globally unique <id> value. An original report also gets a new value for <set_id>,
13 and has the value of <version_nbr> set to equal "1".
15 Every document has a required document type code, <document_type_cd>. The externally-defined
16 vocabulary domain for <document_type_cd> is drawn from LOINC.10
17
18 Table 3. Example concepts for <document_type_cd> (CWE)
Code Display Name Code System Code System Name
18733-6 Ambulatory visit 2.16.840.1.113883.6.1 LOINC
note
18742-7 Arthroscopy report 2.16.840.1.113883.6.1 LOINC
18743-5 Autopsy report 2.16.840.1.113883.6.1 LOINC
18745-0 Cardiac 2.16.840.1.113883.6.1 LOINC
catheterization report
11488-4 Consultation note 2.16.840.1.113883.6.1 LOINC
18747-6 CT report 2.16.840.1.113883.6.1 LOINC
11490-0 Discharge note 2.16.840.1.113883.6.1 LOINC
11520-4 Echocardiogram 2.16.840.1.113883.6.1 LOINC
report
15507-7 Emergency visit note 2.16.840.1.113883.6.1 LOINC
11492-6 History and physical 2.16.840.1.113883.6.1 LOINC
note
11504-8 Operative note 2.16.840.1.113883.6.1 LOINC
11505-5 Procedure note 2.16.840.1.113883.6.1 LOINC
11506-3 Progress note 2.16.840.1.113883.6.1 LOINC
11522-0 Radiology report 2.16.840.1.113883.6.1 LOINC
11519-6 Social service report 2.16.840.1.113883.6.1 LOINC
11529-5 Surgical pathology 2.16.840.1.113883.6.1 LOINC
report
18761-7 Transfer summary 2.16.840.1.113883.6.1 LOINC
11542-8 Visit note 2.16.840.1.113883.6.1 LOINC
19 3.2.2.2.2 Document time stamps

20 There are many temporal events that come into play when creating and validating a CDA document. Some
21 of the relevant times are part of the document information, while other times relate to the encounter, and
22 the time during which various service actors and targets played a role. Some temporal events can be
23 represented as a specific point in time (indicated by an XML element name ending in "_dttm" and using the
24 "point in time" data type), while other temporal events include time points or time intervals (indicated by an
1 10
We anticipate that document type codes in LOINC will be supplemented by codes conforming to the
2 proposed document ontology. See the draft paper, "Proposal for an Ontology for Exchange of Clinical
3 Documents" published July 19, 2000 at http://www.hl7.org/special/dotf/dotf.htm.
5
1 XML element name ending in "_tmr" and using the "interval of time" or the "general time specification"
2 data type).
3
4 The <service_tmr> represents the time the service being documented took place. It is required unless there
5 is an encounter associated with the service in which case <encounter_tmr>, which represents the time of
6 the encounter, is required, and <service_tmr> need not be recorded 11. Both <service_tmr> and
7 <encounter_tmr> can be expressed as a point in time or a time interval.
8
9 The <origination_dttm> represents the time an original document is initiated (e.g. dictated or input into a
10 software interface). If a document is subsequently revised, the value of <origination_dttm> remains
11 unchanged.
12
13 The <copy_dttm> represents the time a document is released (i.e. copied or sent to a display device) from a
14 document management system that maintains revision control over the document. Once valued, it cannot be
15 changed. The intent of <copy_dttm> is to give the viewer of the document some notion as to how long the
16 document has been out of the safe context of its document management system.
17
18 Other time stamps in the document lifecycle are recorded through their association with the various service
19 actors and service targets. Thus, there is a time associated with document authentication, origination,
20 transcription, provider and other service actors’ participation, and patient and other service targets’
21 participation.
22 3.2.2.2.3 Document confidentiality

23 The CDA Header indicates document confidentiality status. Implementers may include a single document
24 confidentiality status indicator in the header that will apply to the entire document. To assign different
25 levels of confidentiality to different portions of the document, implementers can include more than one
26 confidentiality status indicator in the header. Portions of the body are associated with one of the codes
27 through reference (see 3.3.2.1.2 Confidentiality). Values for confidentiality status should be drawn from the
28 ServiceConfidentiality vocabulary domain.
29
30 Table 4. Vocabulary domain for <confidentiality_cd> (CWE)
Code Print Display Name Definition
C celebrity Celebrities are people of public interest including employees, whose information
require special protection.
D clinician Only clinicians may see this item, billing and administration persons can not access
this item without special permission.
I individual Access only to individual persons who are mentioned explicitly as actors of this
service and whose actor type warrants that access.
N normal Normal confidentiality rules (according to good health care practice) apply, that is,
only authorized individuals with a medical or business need may access this item.
R restricted Restricted access, i.e. only to providers having a current care relationship to the
patient.
S sensitive Information for which the patient seeks heightened confidentiality. Sensitive
information is not to be shared with family members.
T taboo Information not to be disclosed or discussed with patient except through physician
assigned to patient in this case. Example use is a new fatal diagnosis or finding,
such as malignancy or HIC.
31 3.2.2.2.4 Document relationships
32 3.2.2.2.4.1 Relationships between documents

33 The CDA Header enables the explicit representation of the relationships between documents. These
34 relationships rely on document identifiers described above (see 3.2.2.2.1 Document identification). An
35 original report is the first version of a report, and gets a new globally unique <id> value, a new value for
1 11
Note that the XML DTD does not express this constraint in such a way that a validating XML processor
2 can enforce conformance.
4
1 <set_id>, and has the value of <version_nbr> set to equal "1".
2
3 An addendum is an appendage to an existing report that contains supplemental information. The appendage
4 is itself an original report, as described in the previous paragraph. The parent report being appended is
5 referenced via <document_relationship>, with <document_relationship.type_cd> set to equal "APND" (for
6 "appends"). The parent report being appended remains in place and its content and status are unaltered.
7
8 A replacement report replaces an existing report. The replacement report gets a new globally unique <id>
9 value, while the replacement report uses the same value for <set_id> as the parent report being replaced,
10 and increments the value of <version_nbr> by 1. (Note that <version_nbr> must be incremented by one
11 when a report is replaced, but can also be incremented more often to meet local requirements.) The parent
12 report is considered superseded, but is still retained in the system for historical reference. The parent report
13 being replaced is referenced via a <document_relationship>, with <document_relationship.type_cd> set to
14 equal "RPLC" (for "replaces").
15
16 The following table summarizes allowable values for <document_relationship.type_cd>.
17
18 Table 5. Vocabulary domain for <document_relationship.type_cd>
19 (CNE)
APND appends An addendum is an appendage to an existing report that contains supplemental
information. The appendage is itself an original report that is related to the parent
report. The parent report being appended remains in place and its content and status
are unaltered.
RPLC replaces A replacement report replaces an existing report. The state of the parent report
being replaced becomes "superseded", but is still retained in the system for
historical reference.
20 3.2.2.2.4.2 Relationship to orders

21 Documents may be generated in response to one or more orders. The <fulfills_order> component of the
22 CDA Header enables the explicit representation of the relationship to orders by expressing the globally
23 unique identifier(s) of the orders that have been fulfilled. The following table summarizes allowable values
24 for <fulfills_order.type_cd>.
25
26 Table 6. Vocabulary domain for <fulfills_order.type_cd> (CNE)
FLFS fulfills (order) A service that was done in fulfillment of an ordered service description. A fulfilled
service may differ from an ordered (or planned) service description.
27 3.2.2.3 Encounter data

28 Encounter data include an optional, globally-unique encounter identifier; a required encounter time stamp;
29 and an optional encounter location, which includes a globally unique location identifier and an address.
30
31 The <service_tmr> represents the time the service being documented took place. It is required unless there
32 is an encounter associated with the service, in which case <encounter_tmr> (which represents the time of
33 the encounter) is required, and <service_tmr> need not be recorded12. Both <service_tmr> and
34 <encounter_tmr> can be expressed as a point in time or a time interval.
35
36 An encounter also includes an optional practice setting code, <practice_setting_cd>, which is a
37 categorization of the clinical setting (e.g. cardiology clinic, primary care clinic, rehabilitation hospital,
38 skilled nursing facility) in which care is delivered. (Note that there is a many-to-many relationship between
39 practice setting and the physical location where care is delivered. Thus, a particular room can provide the
1 12
4
1 location for cardiology clinic one day, and for primary care clinic another day; and cardiology clinic today
2 might be held in one physical location, but in another physical location tomorrow.)
3
4 Values for <practice_setting_cd> should be drawn from the PracticeSetting vocabulary domain.
5
6 Table 7. Vocabulary domain for <practice_setting_cd> (CWE)
Code Implies Display Name*
OF Outpatient facility
CARD OF Cardiology clinic
GIM OF General internal medicine clinic
PC OF Primary care clinic
RHEUM OF Rheumatology clinic
SPMED OF Sports medicine clinic
WND OF Wound clinic
HU Hospital unit
CCU HU Coronary care unit
ER HU Emergency room
ICU HU Intensive care unit
PHU HU Psychiatric hospital unit
RHU HU Rehabilitation hospital unit
HOSP Hospital
GACH HOSP General acute care hospital
RH HOSP Rehabilitation hospital
NCCF Nursing or Custodial Care Facility
SNF NCCF Skilled nursing facility
RTF Residential treatment facility
SURF RTF Substance use rehabilitation facility
7 *Note that there are no definitions for these concepts included in RIM 0.98.
8 3.2.2.4 Service actors

9 All people and materials involved with a CDA document can potentially be associated with the document
10 as either service actors (described here) or service targets (described next, see 3.2.2.5 Service targets).
11 Service actors include those who authenticate the document, those intended to receive a copy of the
12 document, document originators and transcriptionists, and health care providers who participated in the
13 service(s) being documented. Service actors are capable of and accountable for their independent decisions.
14 3.2.2.4.1 People responsible for a clinical document

15 Several CDA Header components represent people and organizations that play a role in the document or
16 the services documented. While these components can represent different people, it is often the case that
17 the same person will be represented as the value for more than one of these components (e.g. the person
18 originating a document also authenticates it). In such cases, the person should be included as the value for
19 each appropriate component.
20
21 The role that a person is playing is specified by the type_cd components (e.g. <authenticator.type_cd>,
22 <service_actor.type_cd>). While the role may be suggested by the XML element name, the type_cd values
23 are the definitive indication13.
24
25 Every person has a required globally unique identifier, an optional set of physical addresses and
26 telecommunications addresses, and an optional set of names. A person's name has an effective date,
27 <effective_tmr>, and a code, drawn from the PersonNamePurpose vocabulary domain, that specifies the
28 type of name. The following table summarizes allowable values for the <person_name.type_cd>.
29
30 Table 8. Vocabulary domain for <person_name.type_cd> (CWE)
A Artist / Stage name Includes writer's pseudonym, stage name, etc.
C License name A name recorded on a license, record, certificate, etc (if different from
1 Where there is only one allowable value for type_cd, it is modeled as a fixed attribute in the XML DTD.
13
3
legal name)
I Indigenous / Tribal e.g. Chief Red Cloud.
name
L Legal name A person's full legal name.
R Religious name e.g. Sister Mary Francis, Brother John.
1 3.2.2.4.2 Authenticators
2 The CDA is a standard that specifies the structure of exchanged clinical documents. In the case where a
3 local document is transformed into a CDA document for exchange, authentication occurs on the local
4 document, and that fact is reflected in the exchanged CDA document. A CDA document can reflect the
5 unauthenticated, authenticated, or legally authenticated state. The unauthenticated state exists when no
6 authentication information has been recorded (i.e., it is the absence of being either authenticated or legally
7 authenticated).
8
9 An authenticated document exists when a provider has attested to the accuracy of the document. A
10 document can be authenticated by zero or more people. The following table, drawn from the ServiceActor
11 vocabulary domain, summarizes allowable values for <authenticator.type_cd>.
12
13 Table 9. Vocabulary domain for <authenticator.type_cd> (CNE)
Code Display Nmae Definition
VRF verifier A person who verifies (authenticates) the correctness and appropriateness of the
document.
14
15 A legally authenticated document exists when the individual who is legally responsible for the document
16 has attested to its accuracy. The following table, drawn from the ServiceActor vocabulary domain,
17 summarizes allowable values for <legal_authenticator.type_cd>.
18
19 Table 10. Vocabulary domain for <legal_authenticator.type_cd>
20 (CNE)
SPV supervisor (legal A person who is legally responsible for (and legally authenticates) the service
authenticator) carried out by a performer. A supervisor is not necessarily present in an action, but
is accountable for the action through the power to delegate, and the duty to review
actions with the performing actor after the fact.
21
22 The <participation_tmr> element is used to indicate the time of authentication or legal authentication.
23
24 Both authentication and legal authentication require that a document has been signed manually or
25 electronically by the responsible individual. While electronic signatures are not part of the CDA Header,
26 the CDA Header does require the acquisition of signature to be documented, via the <signature_cd>
27 component. The following table, drawn from the ServiceActorSignature vocabulary domain, summarizes
28 allowable values for <signature_cd>.
29
30 Table 11. Vocabulary domain for <signature_cd> (CNE)
S signed A signature for the service is on file from this actor.
X required A signature for the service is required of this actor.
31
32 The <signature_cd> can be used to distinguish between intended and actual authenticators. A value of "S"
33 indicates that the signature has been obtained and is on file, whereas a value of "X" indicates that the actor
34 is an intended authenticator or legal authenticator.
35 3.2.2.4.3 Intended recipients

36 Intended recipients are those people to whom a copy of the document is to be sent. The CDA Header can
37 specify one or more intended recipients. The following table, drawn from the ServiceActor vocabulary
38 domain, summarizes allowable values for <intended_recipient.type_cd>.
2
1
2 Table 12. Vocabulary domain for <intended_recipient.type_cd> (CNE)
TRC tracker A person who may receive copies of exchange about this service.
3 3.2.2.4.4 Originators
4 3.2.2.4.4.1 Originating person

5 CDA documents can be originated (authored) by humans and/or by machines. The <originator> element is
6 used to indicate human origination, and the <originating_device> element is used to indicate machine
7 origination (see 3.2.2.5.2 Originating device). The CDA Header requires the specification of one or more
8 document originators, but does not require that there be a human originator14. The <participation_tmr>
9 element is used to indicate the time of origination. The following table, drawn from the ServiceActor
10 vocabulary domain, summarizes allowable values for <originator.type_cd>.
11
12 Table 13. Vocabulary domain for <originator.type_cd> (CNE)
AUT author (originator) A person who originates (e.g., dictates) a document.
13 3.2.2.4.4.2 Originating organization

14 The CDA Header can specify the organization from which the document originates and that is in charge of
15 maintaining the document. The following table, drawn from the ServiceActor vocabulary domain,
16 summarizes allowable values for <originating_organization.type_cd>.
17
18 Table 14. Vocabulary domain for <originating_organization.type_cd>
19 (CNE)
CST custodian An organization who originates and is in charge of maintaining the document.
20 3.2.2.4.5 Transcriptionist
21 The CDA Header can specify a transcriptionist. The <participation_tmr> element is used to indicate the
22 time of transcription. The following table, drawn from the ServiceActor vocabulary domain, summarizes
23 allowable values for <transcriptionist.type_cd>.
24
25 Table 15. Vocabulary domain for <transcriptionist.type_cd> (CNE)
ENT data entry person A person entering the data into the originating system.
26 3.2.2.4.6 Healthcare providers

27 The CDA Header requires the specification of one or more healthcare providers who participated in the
28 service(s) being documented. The <participation_tmr> element is used to indicate the time of participation.
29 The following table, drawn from the ServiceActor vocabulary domain, summarizes allowable values for the
30 required <provider.type_cd>.
31
32 Table 16. Vocabulary domain for <provider.type_cd> (CNE)
ASS assistant performer A person assisting in a service through his substantial presence and involvement.
This includes: assistants, technicians, associates, or whatever the job titles may be.
CON consultant An advisor participating in the service by performing evaluations and making
1 14
2 can enforce conformance, since both <originator> and <originating_device> are optional, but at least one or
3 the other must be present.
5
recommendations.
PRF performer A person who actually and principally carries out the action. Need not be the
principal responsible actor, e.g. a surgery resident operating under supervision of
attending surgeon.
1
2 The optional <function_cd> describes the business function of the provider in more detail. The following
3 table, drawn from the ServiceActorFunction vocabulary domain, summarizes allowable values for
4 <function_cd>.
5
6 Table 17. Vocabulary domain for <function_cd> (CWE)
ADMPHYS admitting physician A physician who admitted a patient to a hospital or other care unit that is the context
of this service.
ANEST anesthesist In a typical anesthesia setting an anesthesiologist or anesthesia resident in charge of
the anesthesia and life support, but only a witness to the surgical procedure itself.
To clarify responsibilities anesthesia should always be represented as a separate
service related to the surgery.
ANRS anesthesia nurse In a typical anesthesia setting the nurse principally assisting the anesthesiologist
during the critical periods.
ATTPHYS attending physician A physician who is primarily responsible for a patient during the hospitalization,
which is the context of the service.
DISPHYS discharging physician A physician who discharged a patient from a hospital or other care unit that is the
context of this service.
FASST first assistant surgeon In a typical surgery setting the assistant facing the primary surgeon. The first
assistant performs parts of the operation and assists in others (e.g., incision,
approach, electrocoutering, ligatures, sutures.)
MDWF midwife A person (usually female) helping a woman deliver a baby. Responsibilities vary
locally, ranging from a mere optional assistant to a full required participant,
responsible for (normal) births and pre- and post-natal care for both mother and
baby.
NASST nurse assistant In a typical surgery setting the non-sterile nurse handles material supply from the
stock, forwards specimen to pathology, and helps with other non-sterile tasks (e.g.,
phone calls, etc.)
PCP primary care physician The healthcare provider that holds primary responsibility for the overall care of a
patient.
PRISURG primary surgeon In a typical surgery setting the primary performing surgeon.
RNDPHYS rounding physician A physician who made rounds on a patient in a hospital or other care center.
SASST second assistant In a typical surgery setting the assistant who primarily holds the hooks.
surgeon
SNRS scrub nurse In a typical surgery setting the nurse in charge of the instrumentation.
TASST third assistant In a typical surgery setting there is rarely a third assistant (e.g., in some Hip
operations the third assistant postures the affected leg.)
7
8 Note that the <function_cd> component designates the actual function performed in the service being
9 documented. This is different from a role associated with a person or a profession- or specialty-code. For
10 instance, the function "anesthetist" is not necessary served by an anesthesiologist.
11 3.2.2.4.7 Other service actors

12 In addition to the specific service actors described above, other people occasionally play a role in certain
13 circumstances or with certain types of documents. The CDA Header can specify one or more of these
14 people via the <service_actor> component. The <participation_tmr> element is used to indicate the time of
15 participation. The <signature_cd> is used as described above (see 3.2.2.4.2 Authenticators) to differentiate
16 actual vs. intended participation. The identity of the person or organization serving as actor must be
17 specified. The following table, drawn from the ServiceActor vocabulary domain, suggests values for
18 <service_actor.type_cd>.
19
20 Table 18. Vocabulary domain for <service_actor.type_cd> (CWE)
CBC call-back contact A contact (often not individual) to whom immediate questions for clarification
should be directed (e.g., a care facility to be called by phone number.)
CNS consenter The person giving consent to the service (usually the patient himself or a legal
2
guardian.)
INF informant A source of reported information (e..g a next of kin who answers questions about the
patient's history.)
REF referrer A person having referred the subject of the service to the performer (e.g. referring
physician.)
WIT witness A person witnessing the action happening without doing anything. A witness is not
necessarily aware, much less approves of anything stated in the service event.
1 3.2.2.5 Service targets

2 Service targets are physical entities, including living subjects and inanimate material, that are typically the
3 object of services being documented. Service targets include the patient, other significant participants (such
4 as family members), and those devices that may have originated portions of the document.
5 3.2.2.5.1 Patient
6 The CDA Header requires one and only one value for <patient>. The value of the <patient> component
7 indicates whose medical record this document belongs to. By default, the <patient> is also the principal
8 subject of the service(s) being documented. If that is not the case, the CDA Header allows other service
9 targets to be specified (see 3.2.2.5.3 Other service targets). The <participation_tmr> element is used to
10 indicate the time of participation. The following table, drawn from the ServiceTargetType vocabulary
11 domain, summarizes allowable values for <patient.type_cd>.
12
13 Table 19. Vocabulary domain for <patient.type_cd> (CNE)
PAT patient The patient target indicates whose patient medical record this service is part of.
PATSBJ patient subject Implies that the patient is the subject of the service.
14
15 The <patient> is defined as having the same components as any other person (see 3.2.2.4.1 People
16 responsible for a clinical document), plus a date of birth, <birth_dttm>, and a gender,
17 <administrative_gender_cd>. The following table, drawn from the AdministrativeGender vocabulary
18 domain, summarizes allowable values for <administrative_gender_cd>.
19
20 Table 20. Vocabulary domain for <administrative_gender_cd> (CWE)
F Female A patient that can share a hospital room with someone of the female gender.
M Male A patient that can share a hospital room with someone of the male gender.
21
22 A <patient> has two types of identifiers. The first type of identifier can be used for any individual and
23 belongs to a person independent of affiliation with a healthcare service provider (see 3.2.2.4.1 People
24 responsible for a clinical document). The second type of identifier is used by a healthcare service provider
25 to identify a patient with whom they have a relationship. This second type of identifier is used only for
26 people in their role as patient under the auspices of a single provider organization. This identifier is
27 represented by the <is_known_by > element and the <is_known_to > element identifies the healthcare
28 provider.
29 3.2.2.5.2 Originating device

30 CDA documents can be originated (authored) by humans and/or by machines. The <originator> element is
31 used to state human origination (see 3.2.2.4.4.1 Originating person), and the <originating_device> element
32 is used to indicate machine origination. The CDA Header requires the specification of one or more
33 document originators, but does not require that there be a human originator15.
34
35 The optionally repeating CDA component <originating_device> indicates those devices used to originate
36 portions of a CDA document. The <participation_tmr> element is used to indicate the time of origination.
1 15
2 can enforce conformance, since both <originator> and <originating_device> are optional, but at least one or
3 the other must be present.
5
1 The following table, drawn from the ServiceTargetType vocabulary domain, summarizes allowable values
2 for <originating_device.type_cd>.
3
4 Table 21. Vocabulary domain for <originating_device.type_cd> (CNE)
ODV originating device A device that originates all or part of a document.
5
6 Each originating device has a unique identifier and falls under the responsibility of one or more
7 stakeholders, and the responsible parties for a device can be specified in the CDA Header using the
8 <responsibility> component. The <responsiblity_tmr> element is used to indicate the time during which the
9 stakeholder assumed the type of responsiblity indicated by the <responsibility.type_cd> element. The
10 following table, drawn from the MaterialResponsibility vocabulary domain, suggests values for
11 <responsibility.type_cd>.
12
13 Table 22. Vocabulary domain for <responsibility.type_cd> (CWE)
MNT maintainer A person in charge of the maintenance of a material. Assumes responsibility for
proper operation, quality, and safety.
14 3.2.2.5.3 Other service targets

15 In addition to the specific service targets described above, other people occasionally may play a role in
16 certain circumstances or with certain types of documents. The CDA Header can specify one or more of
17 these people via the <service_target> component. The <participation_tmr> element is used to indicate the
18 time of participation. The following table, drawn from the ServiceTargetType vocabulary domain, suggests
19 values for <service_target.type_cd>.
20
21 Table 23. Vocabulary domain for <service_target.type_cd> (CWE)
BBY baby In an obstetric service, the baby.
BEN beneficiary Target on behalf of whom the service happens, but that is not necessarily present in
the service.
DIR direct target Target that is substantially present in the service and which is directly affected by
the service action.
MTH mother In an obstetric service, the mother.
NOK proxy Someone who is the subject of the service on behalf of the patient. For example, a
family member who is the subject of a teaching service in the patient's matters.
SBJ subject The principal target that the service acts on. E.g. a specimen in a lab observation, a
patient's family member (teaching).
22 3.2.2.6 Localization
23 Locally-defined markup must be used when local semantics have no corresponding representation in the
24 CDA specification. CDA seeks to standardize the highest level of shared meaning while providing a clean
25 and standard mechanism for tagging meaning that is not shared. This is achieved with the CDA
26 <local_header> element. For additional implementation notes on localization, see Appendix 5.3.3
27 Localization and 5.3.4 Transformation issues.
28
29
30 The <local_header> element is optionally repeating, and recursive. The "descriptor" attribute describes the
31 element, and the value can be drawn from a local vocabulary domain. The "ignore" attribute tells the
32 receiver to ignore just the <local_header> tag (ignore="markup"), or to ignore the <local_header> tag and
33 all contained content (ignore="all"). The "render" attribute indicates how the sender would render the
34 contents. The value can be drawn from a local vocabulary domain. The human language of contained
35 character data can be specified using the xml:lang attribute (see 3.3.2.1.4 Language). The nested
36 <local_attr> element is provided to make it easier to map local XML attribute values into local markup.
37
2
1 Figure 5. XML content model of <local_header>
2 <!ELEMENT local_header (#PCDATA | local_header | local_attr)* >
3 <!ATTLIST local_header
4 ignore (all | markup) "markup"
5 descriptor CDATA #IMPLIED
6 render CDATA #IMPLIED
7 ID ID #IMPLIED
8 xml:lang NMTOKEN #IMPLIED >
9 <!ELEMENT local_attr EMPTY>
10 <!ATTLIST local_attr
11 name NMTOKEN #REQUIRED
12 value CDATA #REQUIRED
13 ID ID #IMPLIED
14 xml:lang NMTOKEN #IMPLIED>
15
2
1 3.2.3 Hierarchical Description
2 See 1999 HL7 Message Development Framework for detailed description of this table structure.
3
4 Table 24. Hierarchical description of CDA Header
Row Row Class or RIM RIM XML in XML Element Source Data Type Car Vocabulary Coding Man- De- Con-
# Type Property of Source Element Element of dina Domain Strngth datory fault straint
Class Class Name Name Element lity * Value #
(Attribute or
Association)
1. class service document_ document_ clinical_document_ Root N document 1..1 M
service service_as_ header _service
clinical_
document_
header
2. attr id document_ id id clinical_document_ D II 1..1 M
service header
3. attr set_id document_ set_id set_id clinical_document_ D II 0..1 M
service header
4. attr version_nbr document_ version_ version_nbr clinical_document_ D INT 0..1 M
service nbr header
5. attr service_cd document_ service_cd document_type_cd clinical_document_ D CE 1..1 DocumentType CWE
service header (2.16.840.1.1138
83.6.1.10870)
6. attr activity_ document_ activity_ service_tmr clinical_document D GTS 0..1 M C0
dttm service dttm _header
7. attr origination_ document_ origination_ origination_dttm clinical_document_ D TS 1..1 M
dttm service dttm header
8. attr copy_dttm document_ copy_dttm copy_dttm clinical_document_ D TS 0..1 M
service header
9. attr confidentiality document_ confidentiality confidentiality_cd clinical_document_ D SET <CE> 0..1 ServiceConfident CWE N C1
_cd service _cd header iality
(2.16.840.1.1138
83.5.10228)
10. assoc is_source_ document_ is_source_for_ document_ clinical_document_ N service_ 0..* M
for service service_ relationship header relationship
relationship
11. attr type_cd service_ type_cd document_ document_ D CS 1..1 ServiceRelations CNE M C2
relationship relationship. relationship hip
type_cd (2.16.840.1.1138
83.5.10317)
12. assoc has_target service_ has_ target_ related_ document_ N service 1..1 M
relationship service document relationship

2
(Attribute or
Association)
13. attr id document_ id id related_document D II 1..1 M
service
14. attr set_id document_ set_id set_id related_document D II 0..1 M
service
15. attr version_nbr document_ version_nbr version_nbr related_document D INT 0..1 M
service
16. assoc is_source_ document_ is_source_for_ fulfills_order clinical_document_ N service_ 0..1 M
for service service_ header relationship
relationship
17. attr type_cd service_ type_cd fulfills_order. fulfills_order D CS 1..1 ServiceRelations CNE M FLFS C3
relationship type_cd hip
(2.16.840.1.1138
83.5.10317)
18. assoc has_target service_ has_target_ order fulfills_order N service 1..* M
relationship service
19. attr id document_ id id order D II 1..1 M
service
20. assoc is_assigned_ document_ is_assigned_ patient_encounter clinical_document_ N patient_ 0..1 M
to service to_patient_ header encounter
encounter
21. attr id patient_ id id patient_encounter D II 0..1 M
encounter
22. attr practice_ patient_ practice_ practice_ patient_encounter D CE 0..1 PracticeSetting CWE
setting_ encounter setting_ setting_ (2.16.840.1.1138
cd cd cd 83.5.10588)
23. attr active_tmr patient_ active_tmr encounter_tmr patient_encounter D IVL_TS 1..1 M
encounter
24. assoc has patient_ has_master_ service_ patient_encounter N master_ 0..1 M
encounter patient_ location patient_
service_ service_
location location
25. attr id master_ id id service_location D II 0..1 M
patient_
service_
location
26. attr addr master_ addr addr service_location D AD 0..1 M
patient_
service_
location
27. assoc has document_ has_ authenticator clinical_document N service_ 0..* M
service service_ _header actor

2
(Attribute or
Association)
actor
28. attr type_cd service_ type_cd authenticator. authenticator D CS 1..1 ServiceActor CNE M VRF C4
actor type_cd (2.16.840.1.1138
83.5.10246)
29. attr tmr service_ tmr participation_ authenticator D IVL_TS 1..1 M
actor tmr
30. attr signature_cd service_ signature_cd signature_cd authenticator D CS 1..1 ServiceActorSig CNE M S
actor nature
(2.16.840.1.1138
83.5.10282)
31. assoc participation service_ participation_ person authenticator N person 1..1 M
_of actor of_person
32. attr id stakeholder id id person D SET <II> 1..1 M
33. assoc has person has_ person_name person N person_ 0..* M
person_name name
34. attr effective_tmr person_ effective_tmr effective_ person_name D IVL_TS 0..1 M
name tmr
35. attr nm person_ nm nm person_name D PN 1..1 M
name
36. attr type_cd person_ person_name. person_name. person_name D CE 0..1 PersonNamePurp CWE
name type_cd type_cd ose
(2.16.840.1.1138
83.5.200)
37. attr addr stakeholder addr addr person D SET <AD> 0..1 M
38. attr phon stakeholder phon telecom person D SET 0..1 M
<TEL>
39. assoc has document_ has_ legal_ clinical_document N service_ 0..1 M
service service_ authenticator _header actor
actor
40. attr type_cd service_ type_cd legal_ legal_ D CS 1..1 ServiceActor CNE M SPV C5
actor authenticator. authenticator (2.16.840.1.1138
type_cd 83.5.10246)
41. attr tmr service_ tmr participation_ legal_ D IVL_TS 1..1 M
actor tmr authenticator
42. attr signature_cd service_ signature_cd signature_cd legal_ D CS 1..1 ServiceActorSig CNE M S
actor authenticator nature
(2.16.840.1.1138
83.5.10282)
43. assoc participation service_ participation_ person legal_ U person 1..1 M
_of actor of_person authenticator

2
(Attribute or
Association)
44. assoc has document_ has_ intended_recipient clinical_document N service_ 0..* M
actor
45. attr type_cd service_ type_cd intended_ intended_recipient D CS 1..1 ServiceActor CNE M TRC C6
actor recipient. (2.16.840.1.1138
type_cd 83.5.10246)
46. assoc participation service_ participation_ person intended_recipient U person 1..1 M
_of actor of_person
47. assoc has document_ has_ originator clinical_document N service_ 0..* M C7
actor
48. attr type_cd service_ type_cd originator. originator D CS 1..1 ServiceActor CNE M AUT C8
actor type_cd (2.16.840.1.1138
83.5.10246)
49. attr tmr service_ tmr participation_ originator D IVL_TS 1..1 M
actor tmr
50. assoc participation service_ participation_ person originator U person 1..1 M
_of actor of_person
51. assoc has document_ has_ originating_ clinical_document N service_ 0..1 M
service service_ organization _header actor
actor
52. attr type_cd service_ type_cd originating_ originating_ D CS 0..1 ServiceActor CNE M CST C9
actor organization. organization (2.16.840.1.1138
type_cd 83.5.10246)
53. assoc participation service_ participation_ organization originating_ U organizatio 1..1 M
_of actor of_ organization n
organization
54. attr id stakeholder id id organization D SET <II> 0..1 M
55. attr nm organizatio nm organization. organization D SET <ON> 0..1 M
n nm
56. attr addr stakeholder addr addr organization D SET <AD> 0..1 M
57. assoc has document_ has_ transcriptionist clinical_document N service_ 0..1 M
actor
58. attr type_cd service_ type_cd transcriptionist transcriptionist D CS 1..1 ServiceActor CNE M ENT C10
actor .type_cd (2.16.840.1.1138
83.5.10246)
59. attr tmr service_ tmr participation_ transcriptionist D IVL_TS 0..1 M
actor tmr
60. assoc participation service_ participation_ person transcriptionist U person 1..1 M

2
(Attribute or
Association)
_of actor of_person
61. assoc has document_ has_ provider clinical_document N service_ 1..* M
actor
62. attr type_cd service_ type_cd provider. provider D CS 1..1 ServiceActor CNE M PRF C11
actor type_cd (2.16.840.1.1138
83.5.10246)
63. attr function_cd service_ function_cd function_cd provider D CE 0..1 ServiceActorFun CWE
actor ction
(2.16.840.1.1138
83.5.10267)
64. attr tmr service_ tmr participation_ provider D IVL_TS 0..1 M
actor tmr
65. assoc participation service_ participation_ person provider U person 1..1 M
_of actor of_person
66. assoc has document_ has_ service_actor clinical_document N service_ 0..* M
actor
67. attr type_cd service_ type_cd service_actor. service_actor D CE 1..1 ServiceActor CWE
actor type_cd (2.16.840.1.1138
83.5.10246)
68. attr tmr service_ tmr participation_ service_actor D IVL_TS 0..1 M
actor tmr
69. attr signature_cd service_ signature_cd signature_cd legal_ D CS 0..1 ServiceActorSig CNE M S
actor authenticator nature
(2.16.840.1.1138
83.5.10282)
70. assoc participation service_ participation_ person_or_ service_actor N person | 1..1 M
_of actor of_stakeholder organization organizatio
n
71. assoc has document_ has_ patient clinical_document N service_ 1..1 M
target
72. attr type_cd service_ type_cd patient.type_cd patient D CS 1..1 ServiceTargetTy CNE M PATS C12
target pe BJ
(2.16.840.1.1138
83.5.10285)
73. attr tmr service_ tmr participation_ patient D IVL_TS 0..1 M
target tmr
74. assoc participation service_ participation_ person patient U person 1..1 M
_of target of_person

2
(Attribute or
Association)
75. assoc is_known_by person is_known_by is_known_by patient N person_ 0..* M
provider_
association
76. attr id person_ id id is_known_by N SET<II> 1..1 M
provider_
association
77. assoc is_known_to person_ is_known_to is_known_to is_known_by N healthcare_ 1..1 M
provider_ service_
association provider
78. attr id healthcare_ id id is_known_to N SET<II> 1..1 M
service_
provider
79. attr birth_dttm person birth_dttm birth_dttm patient D TS 0..1 M
80. attr administrative person administrative administrative_ patient D CE 0..1 AdministrativeG CWE
_gender_cd _gender_cd gender_cd ender
(2.16.840.1.1138
83.5.1)
81. assoc has document_ has_service_ originating_device clinical_document N service_ 0..* M C13
service target _header target
82. attr type_cd service_ type_cd originating_ originating_device D CS 1..1 ServiceTargetTy CNE M ODV C14
target device.type_cd pe
(2.16.840.1.1138
83.5.10285)
83. attr tmr service_ tmr participation_ originating_device D IVL_TS 0..1 M
target tmr
84. assoc participation service_ participation_ device originating_device N device 1..1 M
_of target of_material
85. attr id device id id device D SET <II> 1..* M
86. assoc is_the device is_the_ responsibility device N responsibili 0..* M
responsibility ty
87. attr type_cd responsibili type_cd responsi responsibility D CE 0..1 MaterialResponsi CWE
ty bility. bility
type_cd (2.16.840.1.1138
83.5.10416)
88. attr tmr responsibili tmr responsi responsibility D IVL_TS 0..1 M
ty bility_
tmr
89. assoc of responsibili of_person person responsibility U person 1..1 M
ty
90. assoc has document_ has_ service_target clinical_document N service_ 0..* M

2
(Attribute or
Association)
target
91. attr type_cd service_ type_cd service_target. service_target D CE 1..1 ServiceTargetTy CWE
target type_cd pe
(2.16.840.1.1138
83.5.10285)
92. attr tmr service_ tmr participation_ service_target D IVL_TS 0..1 M
target tmr
93. assoc participation service_ participation_ person service_target U person 1..1 M
_of target of_person
1
2 C0 :: <service_tmr> is required unless there is an encounter associated with the service in which case <encounter_tmr>, which represents the time of the
3 encounter, is required, and <service_tmr> need not be recorded.
4 C1 :: The ServiceConfidentiality vocabulary domain is constrained to only include: "C", "D", "I", "N", "R", "S", "T". (See also 3.2.2.2.3 Document
5 confidentiality.)
6 C2 :: The ServiceRelationship vocabulary domain is constrained to only include: "APND", "RPLC". (See also 3.2.2.2.4.1 Relationships between documents.)
7 C3 :: The ServiceRelationship vocabulary domain is constrained to only include: "FLFS". (See also 3.2.2.2.4.2 Relationship to orders.)
8 C4 :: The ServiceActor vocabulary domain is constrained to only include: "VRF". (See also 3.2.2.4.2 Authenticators.)
9 C5 :: The ServiceActor vocabulary domain is constrained to only include: "SPV". (See also 3.2.2.4.2 Authenticators.)
10 C6 :: The ServiceActor vocabulary domain is constrained to only include: "TRC". (See also 3.2.2.4.3 Intended recipients.)
11 C7 :: There must be at least one <originator> or <originating_device>.
12 C8 :: The ServiceActor vocabulary domain is constrained to only include: "AUT". (See also 3.2.2.4.4.1 Originating person.)
13 C9 :: The ServiceActor vocabulary domain is constrained to only include: "CST". (See also 3.2.2.4.4.2 Originating organization.)
14 C10 :: The ServiceActor vocabulary domain is constrained to only include: "ENT". (See also 3.2.2.4.5 Transcriptionist.)
15 C11 :: The ServiceActor vocabulary domain is constrained to only include: "ASS", "CON", "PRF". (See also 3.2.2.4.6 Healthcare providers.)
16 C12 :: The ServiceTargetType vocabulary domain is constrained to only include: "PAT", "PATSBJ". (See also 3.2.2.5.1 Patient.)
17 C13 :: There must be at least one <originator> or <originating_device>.
18 C14 :: The ServiceTargetType vocabulary domain is constrained to only include: "ODV". (See also 3.2.2.5.2 Originating device.)
19
20
21 * Abbreviations used in Hierarchical Description
22
Abbreviation Appears in column Definition
CNE Coding Strength If a vocabulary domain is "Coded, No Extensions" (CNE) , then the only allowable values for the CDA
component are those in the vocabulary domain.

2
CWE Coding Strength If a vocabulary domain is "Coded, With Extensions" (CWE), then values other than those in the vocabulary
domain (such as local codes) can be used if necessary.
M Mandatory If an element is present, it may not contain a null value. Note that the column labeled "cardinality" determines
whether or not an element must be present. The column labeled "mandatory" determines whether or not
elements that are present are allowed to contain null values.
AD Data Type Address data type.
CE Data Type Coded With Equivalents data type
CS Data Type Coded Simple Value data type.
GTS Data Type General Time Specification data type.
II Data Type Instance Identifier data type.
INT Data Type Integer data type.
IVL_TS Data Type Interval of Time data type.
ON Data Type Organization Name data type.
PN Data Type Person Name data type.
ST Data Type String data type.
TS Data Type Time Stamp data type.
assoc Row Type This row is defining the use of a RIM association.
attr Row Type This row is defining the use of a RIM attribute.
D Source of Element The RIM attribute described in this row is modeled as the data type stated in the "Data Type" column.
N Source of Element This is the first time that the RIM attribute described in this row appears in this Hierarchical Description.
U Source of Element The RIM attribute in this row has already been defined in this Hierarchical Description and is being reused.

2
1 3.2.4 XML Document Type Definition
2 
17
18
19 
29
30 <!ENTITY % HL7V3.0-datatypes PUBLIC
31 "-//HL7//DTD V3DT 1.0//EN"
32 "v3DT_1.0.dtd" >
33 %HL7V3.0-datatypes;
34
35 
43
44 <!ENTITY % common_atts "
45 ID ID #IMPLIED "
46 >
47
48 
2
1
2 <!ELEMENT clinical_document_header (
3 id,
4 set_id?,
5 version_nbr?,
6 document_type_cd,
7 service_tmr?,
8 origination_dttm,
9 copy_dttm?,
10 confidentiality_cd*,
11 document_relationship*,
12 fulfills_order?,
13 patient_encounter?,
14 authenticator*,
15 legal_authenticator?,
16 intended_recipient*,
17 originator*,
18 originating_organization?,
19 transcriptionist?,
20 provider+,
21 service_actor*,
22 patient,
23 originating_device*,
24 service_target*,
25 local_header*)>
26 <!ATTLIST clinical_document_header
27 %common_atts;
28 HL7-NAME CDATA #FIXED 'document_service_as_clinical_document_header'
29 T CDATA #FIXED 'service'
30 RIM-VERSION CDATA #FIXED '0.98'>
31
32 
49
50 
3
4 
12
13 <!ELEMENT id %II-cont.model;>
14 <!ATTLIST id
15 %II-attrib.list;
16 %common_atts;
17 HL7-NAME CDATA #FIXED 'id'>
18
19 <!ELEMENT set_id %II-cont.model;>
20 <!ATTLIST set_id
21 %II-attrib.list;
22 %common_atts;
23 HL7-NAME CDATA #FIXED 'set_id'>
24
25 <!ELEMENT version_nbr %INT-cont.model;>
26 <!ATTLIST version_nbr
27 %INT-attrib.list;
28 %common_atts;
29 HL7-NAME CDATA #FIXED 'version_nbr'>
30
31 <!ELEMENT document_type_cd %CE-cont.model;>
32 <!ATTLIST document_type_cd
33 %CE-attrib.list;
34 %common_atts;
35 HL7-NAME CDATA #FIXED 'service_cd'>
36
37 
45
46 <!ELEMENT service_tmr %GTS-cont.model;>
47 <!ATTLIST service_tmr
48 %GTS-attrib.list;
49 %common_atts;
50 HL7-NAME CDATA #FIXED 'service_tmr'>
51
52 <!ELEMENT origination_dttm %TS-cont.model;>
53 <!ATTLIST origination_dttm
54 %TS-attrib.list;
55 %common_atts;
56 HL7-NAME CDATA #FIXED 'origination_dttm'>
57
2
1 <!ELEMENT copy_dttm %TS-cont.model;>
2 <!ATTLIST copy_dttm
3 %TS-attrib.list;
4 %common_atts;
5 HL7-NAME CDATA #FIXED 'copy_dttm'>
6
7 
15
16 <!ELEMENT confidentiality_cd %CE-cont.model;>
17 <!ATTLIST confidentiality_cd
18 %CE-attrib.list;
19 %common_atts;
20 HL7-NAME CDATA #FIXED 'confidentiality_cd'>
21
22 
31
32 <!ELEMENT document_relationship (
33 document_relationship.type_cd,
34 related_document,
35 local_header*)>
36 <!ATTLIST document_relationship
37 %common_atts;
38 HL7-NAME CDATA #FIXED 'is_source_for_service_relationship'
39 T CDATA #FIXED 'service_relationship'>
40
41 <!ELEMENT document_relationship.type_cd %CS-cont.model;>
42 <!ATTLIST document_relationship.type_cd
43 T NMTOKEN #FIXED "CS"
44 V (APND|RPLC) #REQUIRED
45 V-T NMTOKEN #FIXED "ST"
46 V-HL7_NAME CDATA #FIXED "code"
47 DN CDATA #IMPLIED
48 DN-T NMTOKEN #FIXED "ST"
49 DN-HL7_NAME CDATA #FIXED "displayName"
50 %common_atts;
51 HL7-NAME CDATA #FIXED 'type_cd'>
52
53 <!ELEMENT related_document (
54 id,
55 set_id?,
56 version_nbr?,
57 local_header*)>
2
1 <!ATTLIST related_document
2 %common_atts;
3 HL7-NAME CDATA #FIXED 'has_target_service'
4 T CDATA #FIXED 'service'>
5
6 <!ELEMENT fulfills_order (
7 fulfills_order.type_cd,
8 order+,
9 local_header*)>
10 <!ATTLIST fulfills_order
11 %common_atts;
12 HL7-NAME CDATA #FIXED 'is_source_for_service_relationship'
13 T CDATA #FIXED 'service_relationship'>
14
15 <!ELEMENT fulfills_order.type_cd %CS-cont.model;>
16 <!ATTLIST fulfills_order.type_cd
18 V CDATA #FIXED "FLFS"
24 %common_atts;
26
27 <!ELEMENT order (
28 id,
29 local_header*)>
30 <!ATTLIST order
31 %common_atts;
32 HL7-NAME CDATA #FIXED 'has_target_service'
33 T CDATA #FIXED 'service'>
34
35 
49
50 <!ELEMENT patient_encounter (
51 id?,
52 practice_setting_cd?,
53 encounter_tmr,
54 service_location?,
55 local_header*)>
56 <!ATTLIST patient_encounter
57 %common_atts;
2
1 HL7-NAME CDATA #FIXED 'is_assigned_to_patient_encounter'
2 T CDATA #FIXED 'patient_encounter'>
3
4 <!ELEMENT practice_setting_cd %CE-cont.model;>
5 <!ATTLIST practice_setting_cd
6 %CE-attrib.list;
7 %common_atts;
8 HL7-NAME CDATA #FIXED 'practice_setting_cd'>
9
10 <!ELEMENT encounter_tmr %IVL_TS-cont.model;>
11 <!ATTLIST encounter_tmr
12 %IVL_TS-attrib.list;
13 %common_atts;
14 HL7-NAME CDATA #FIXED 'encounter_tmr'>
15
16 <!ELEMENT service_location (
17 id?,
18 addr?,
19 local_header*)>
20 <!ATTLIST service_location
21 %common_atts;
22 HL7-NAME CDATA #FIXED 'has_master_patient_service_location'
23 T CDATA #FIXED 'master_patient_service_location'>
24
25 <!ELEMENT addr %AD-cont.model;>
26 <!ATTLIST addr
27 %AD-attrib.list;
28 %common_atts;
29 HL7-NAME CDATA #FIXED 'addr'>
30
31 
43
44 
53
54 <!ELEMENT person (
55 id+,
56 person_name*,
57 addr*,
2
1 telecom*,
2 local_header*)>
3 <!ATTLIST person
4 %common_atts;
5 HL7-NAME CDATA #FIXED 'participation_of_person'
6 T CDATA #FIXED 'person'>
7
8 <!ELEMENT person_name (
9 effective_tmr?,
10 nm,
11 person_name.type_cd?,
12 local_header*)>
13 <!ATTLIST person_name
14 %common_atts;
15 HL7-NAME CDATA #FIXED 'has_person_name'
16 T CDATA #FIXED 'person_name'>
17
18 <!ELEMENT effective_tmr %IVL_TS-cont.model;>
19 <!ATTLIST effective_tmr
21 %common_atts;
22 HL7-NAME CDATA #FIXED 'effective_tmr'>
23
24 <!ELEMENT nm %PN-cont.model;>
25 <!ATTLIST nm
26 %PN-attrib.list;
27 %common_atts;
28 HL7-NAME CDATA #FIXED 'nm'>
29
30 <!ELEMENT person_name.type_cd %CE-cont.model;>
31 <!ATTLIST person_name.type_cd
32 %CE-attrib.list;
33 %common_atts;
35
36 <!ELEMENT telecom %TEL-cont.model;>
37 <!ATTLIST telecom
38 %TEL-attrib.list;
39 %common_atts;
40 HL7-NAME CDATA #FIXED 'phon'>
41
42 
51
52 <!ELEMENT authenticator (
53 authenticator.type_cd,
54 participation_tmr,
55 signature_cd,
56 person,
57 local_header*)>
2
1 <!ATTLIST authenticator
2 %common_atts;
3 HL7-NAME CDATA #FIXED 'has_service_actor'
4 T CDATA #FIXED 'service_actor'>
5
6 <!ELEMENT authenticator.type_cd %CS-cont.model;>
7 <!ATTLIST authenticator.type_cd
9 V CDATA #FIXED "VRF"
15 %common_atts;
17
18 <!ELEMENT participation_tmr %IVL_TS-cont.model;>
19 <!ATTLIST participation_tmr
21 %common_atts;
22 HL7-NAME CDATA #FIXED 'tmr'>
23
24 <!ELEMENT signature_cd %CS-cont.model;>
25 <!ATTLIST signature_cd
27 V (S|X) "S"
33 %common_atts;
34 HL7-NAME CDATA #FIXED 'signature_cd'>
35
36 <!ELEMENT legal_authenticator (
37 legal_authenticator.type_cd,
39 signature_cd,
40 person,
41 local_header*)>
42 <!ATTLIST legal_authenticator
43 %common_atts;
46
47 <!ELEMENT legal_authenticator.type_cd %CS-cont.model;>
48 <!ATTLIST legal_authenticator.type_cd
50 V CDATA #FIXED "SPV"
56 %common_atts;
2
1
2 
10
11 <!ELEMENT intended_recipient (
12 intended_recipient.type_cd,
13 person,
14 local_header*)>
15 <!ATTLIST intended_recipient
16 %common_atts;
19
20 <!ELEMENT intended_recipient.type_cd %CS-cont.model;>
21 <!ATTLIST intended_recipient.type_cd
23 V CDATA #FIXED "TRC"
29 %common_atts;
31
32 
41
42 <!ELEMENT originator (
43 originator.type_cd,
45 person,
46 local_header*)>
47 <!ATTLIST originator
48 %common_atts;
51
52 <!ELEMENT originator.type_cd %CS-cont.model;>
53 <!ATTLIST originator.type_cd
55 V CDATA #FIXED "AUT"
2
1 DN CDATA #IMPLIED
4 %common_atts;
6
7 <!ELEMENT originating_organization (
8 originating_organization.type_cd,
9 organization,
10 local_header*)>
11 <!ATTLIST originating_organization
12 %common_atts;
15
16 <!ELEMENT originating_organization.type_cd %CS-cont.model;>
17 <!ATTLIST originating_organization.type_cd
19 V CDATA #FIXED "CST"
25 %common_atts;
27
28 <!ELEMENT organization (
29 id*,
30 organization.nm*,
31 addr*,
32 local_header*)>
33 <!ATTLIST organization
34 %common_atts;
35 HL7-NAME CDATA #FIXED 'participation_of_organization'
36 T CDATA #FIXED 'organization'>
37
38 <!ELEMENT organization.nm %ON-cont.model;>
39 <!ATTLIST organization.nm
40 %ON-attrib.list;
41 %common_atts;
42 HL7-NAME CDATA #FIXED 'nm'>
43
44 
52
53 <!ELEMENT transcriptionist (
54 transcriptionist.type_cd,
55 participation_tmr?,
56 person,
57 local_header*)>
2
1 <!ATTLIST transcriptionist
2 %common_atts;
5
6 <!ELEMENT transcriptionist.type_cd %CS-cont.model;>
7 <!ATTLIST transcriptionist.type_cd
9 V CDATA #FIXED "ENT"
15 %common_atts;
17
18 
26
27 <!ELEMENT provider (
28 provider.type_cd,
29 function_cd?,
31 person,
32 local_header*)>
33 <!ATTLIST provider
34 %common_atts;
37
38 <!ELEMENT provider.type_cd %CS-cont.model;>
39 <!ATTLIST provider.type_cd
41 V (ASS|CON|PRF) "PRF"
47 %common_atts;
49
50 <!ELEMENT function_cd %CE-cont.model;>
51 <!ATTLIST function_cd
52 %CE-attrib.list;
53 %common_atts;
54 HL7-NAME CDATA #FIXED 'function_cd'>
55
56 
7
8 <!ELEMENT service_actor (
9 service_actor.type_cd,
11 signature_cd?,
12 (person | organization),
13 local_header*)>
14 <!ATTLIST service_actor
15 %common_atts;
18
19 <!ELEMENT service_actor.type_cd %CE-cont.model;>
20 <!ATTLIST service_actor.type_cd
21 %CE-attrib.list;
22 %common_atts;
24
25 
36
37 
46
47 <!ELEMENT patient (
48 patient.type_cd,
50 person,
51 is_known_by*,
52 birth_dttm?,
53 administrative_gender_cd?,
54 local_header*)>
55 <!ATTLIST patient
56 %common_atts;
57 HL7-NAME CDATA #FIXED 'has_service_target'
2
1 T CDATA #FIXED 'service_target'>
2
3 <!ELEMENT patient.type_cd %CS-cont.model;>
4 <!ATTLIST patient.type_cd
6 V (PAT|PATSBJ) "PATSBJ"
9 DN CDATA #IMPLIED
12 %common_atts;
14
15 <!ELEMENT is_known_by (
16 id+,
17 is_known_to,
18 local_header*)>
19 <!ATTLIST is_known_by
20 %common_atts;
21 HL7-NAME CDATA #FIXED 'is_known_by'
22 T CDATA #FIXED 'person_provider_association'>
23
24 <!ELEMENT is_known_to (
25 id+,
26 local_header*)>
27 <!ATTLIST is_known_to
28 %common_atts;
29 HL7-NAME CDATA #FIXED 'is_known_to'
30 T CDATA #FIXED 'healthcare_service_provider'>
31
32 <!ELEMENT birth_dttm %TS-cont.model;>
33 <!ATTLIST birth_dttm
34 %TS-attrib.list;
35 %common_atts;
36 HL7-NAME CDATA #FIXED 'birth_dttm'>
37
38 <!ELEMENT administrative_gender_cd %CE-cont.model;>
39 <!ATTLIST administrative_gender_cd
40 %CE-attrib.list;
41 %common_atts;
42 HL7-NAME CDATA #FIXED 'administrative_gender_cd'>
43
44 
53
54 <!ELEMENT originating_device (
55 originating_device.type_cd,
57 device,
2
1 local_header*)>
2 <!ATTLIST originating_device
3 %common_atts;
6
7 <!ELEMENT originating_device.type_cd %CS-cont.model;>
8 <!ATTLIST originating_device.type_cd
10 V CDATA #FIXED "ODV"
16 %common_atts;
18
19 <!ELEMENT device (
20 id+,
21 responsibility*,
22 local_header*)>
23 <!ATTLIST device
24 %common_atts;
25 HL7-NAME CDATA #FIXED 'participation_of_material'
26 T CDATA #FIXED 'device'>
27
28 <!ELEMENT responsibility (
29 responsibility.type_cd?,
30 responsibility_tmr?,
31 person,
32 local_header*)>
33 <!ATTLIST responsibility
34 %common_atts;
35 HL7-NAME CDATA #FIXED 'is_the_responsibility'
36 T CDATA #FIXED 'responsibility'>
37
38 <!ELEMENT responsibility.type_cd %CE-cont.model;>
39 <!ATTLIST responsibility.type_cd
40 %CE-attrib.list;
41 %common_atts;
43
44 <!ELEMENT responsibility_tmr %IVL_TS-cont.model;>
45 <!ATTLIST responsibility_tmr
47 %common_atts;
48 HL7-NAME CDATA #FIXED 'tmr'>
49
50 
2
1
2 <!ELEMENT service_target (
3 service_target.type_cd,
5 person,
6 local_header*)>
7 <!ATTLIST service_target
8 %common_atts;
11
12 <!ELEMENT service_target.type_cd %CE-cont.model;>
13 <!ATTLIST service_target.type_cd
14 %CE-attrib.list;
15 %common_atts;
17
18 
43
44 <!ELEMENT local_header (#PCDATA | local_header | local_attr)* >
45 <!ATTLIST local_header
49 %common_atts;
51
56 %common_atts;
2
1 3.3 CDA Level One Body
2 3.3.1 Overview
3 The CDA element <levelone> is the root element of a CDA Level One document. The <levelone> element
4 contains a <clinical_document_header> and a <body>. The <clinical_document_header> is derived from
5 the RIM, as described in detail above (see 3.2 CDA Header). The <body> is comprised of either <section>
6 elements, or a <non_xml> element, which is used when the document body is in some format other then
7 XML. A CDA <section> can contain "structures", nested <section> elements, and <coded_entry> elements.
8 CDA structures include the <paragraph>, <list>, and <table> elements. These structures contain CDA
9 "entries", which include the <content>, <link>, <coded_entry>, <observation_media>, and
10 <local_markup> elements, in addition to plain character data.
11
12 Where CDA entries are derivable from the RIM, as is currently only the case for the <observation_media>
13 element, they have an associated Hierarchical Description (HD) and an XML representation that follows
14 the style used for the CDA Header.
15
16 Document analysis was used to articulate requirements for the CDA Level One Body. These are expressed
17 in XML using industry-standard constructs. The structural components themselves are not part of RIM
18 0.98. The Unified Modeling Language (UML) model of the CDA Level One Body included in the
19 appendix (see 5.2 CDA Level One Body UML model) is presented as a non-normative tool to aid in
20 understanding the XML DTD.
21 3.3.2 Technical details
22 3.3.2.1 Shared XML attributes

23 Elements in the CDA Level One Body share a set of XML attributes. Some of these attributes are declared
24 in the CDA Header DTD and used in the document body, while other attributes are declared in the CDA
25 Level One DTD for use specifically in the document body.
26 3.3.2.1.1 XML element identification

27 Every XML element within a CDA document has an optional identifier, which must be unique within the
28 document. (See 3.2.2.1.1 XML element identification).
29 3.3.2.1.2 Confidentiality
30 The confidentiality attribute can occur on any element within the CDA body. The CDA Header contains an
31 optionally repeating element <confidentiality_cd> (see 3.2.2.2.3 Document confidentiality). The
32 confidentiality attribute on CDA Body elements can reference one or more of the confidentiality values in
33 the CDA Header using XML IDREFS. The value(s) referenced must be XML ID(s) in the
34 <confidentiality_cd> element of the CDA Header. Confidentiality is inherited by nested content, unless
35 overridden.
36
37 Figure 6. XML confidentiality attribute
39 ...
40 confidentiality IDREFS #IMPLIED
41 ...>
42 3.3.2.1.3 Originators
2
1 The originator attribute can occur on any element within the CDA body. The CDA Header contains
2 optionally repeating elements <originator> (see 3.2.2.4.4.1 Originating person) and <originating_device>
3 (see 3.2.2.5.2 Originating device). The originator attribute on an element within the CDA Body can
4 reference one or more of these values using XML IDREFS. The value(s) referenced must be XML ID(s) in
5 the <originator> or <originating_device> element of the CDA Header. Origination is inherited by nested
6 content, unless overridden.
7
8 Figure 7. XML originator attribute
10 ...
11 originator IDREFS #IMPLIED
12 ...>
13 3.3.2.1.4 Language
14 The human language of character data can be specified using the xml:lang attribute as defined in the XML
15 1.0 Recommendation:
16
17 "A special attribute named xml:lang may be inserted in documents to specify the language used in
18 the contents and attribute values of any element in an XML document. In valid documents, this
19 attribute, like any other, must be declared if it is used. The values of the attribute are language
20 identifiers as defined by the IETF (Internet Engineering Task Force) RFC 1766: Tags for the
21 Identification of Languages, ed. H. Alvestrand. 1995."
22
23 The value of the xml:lang attribute is inherited by nested content, unless overridden.
24
25 Figure 8. XML xml:lang attribute
27 ...
28 xml:lang NMTOKEN #IMPLIED
29 ...>
30
31 3.3.2.2 Document body and sections
32 3.3.2.2.1 Document body

33 The CDA <body> occurs in the <levelone> element. All CDA documents have exactly one <body>. The
34 <body> contains either one or more <section> elements (see 3.3.2.2.2 Document sections) or a single
35 <non_xml> data segment (see 3.3.2.2.3 Non_xml body).
36
37 The <body> has an optional local identifier (see 3.3.2.1.1 XML element identification), an optional set of
38 confidentiality status flags (see 3.3.2.1.2 Confidentiality), and an optional set of originators (see 3.3.2.1.3
39 Originators). The human language of contained character data can be specified using the xml:lang attribute
40 (see 3.3.2.1.4 Language).
41
2
1 Figure 9. XML content model of <body>
2 <!ELEMENT body (section+ | non_xml) >
3 <!ATTLIST body
4 ID ID #IMPLIED
8 3.3.2.2.2 Document sections

9 The CDA <section> is a container used to wrap other containers. A <section> can occur in the <body>, or
10 can be nested within another <section>. A <section> has an optional <caption> (see 3.3.2.2.2.1 Captions),
11 followed by nested <section> elements or structures (see 3.3.2.3 Document Structures), followed by
12 optionally repeating <coded_entry> elements (see 3.3.2.4.4 Coded entries).
13
14 Each <section> has an optional local identifier (see 3.3.2.1.1 XML element identification), an optional set
15 of confidentiality status flags (see 3.3.2.1.2 Confidentiality), and an optional set of originators (see 3.3.2.1.3
17 (see 3.3.2.1.4 Language).
18
19 Figure 10. XML content model of <section>
20 <!ELEMENT section (caption?, (paragraph | list | table |

21 section)*, coded_entry*)>
22 <!ATTLIST section
23 ID ID #IMPLIED
27 3.3.2.2.2.1 Captions
28 The CDA <caption> is a label for a container. The <caption> element can occur in a <section>,
29 <paragraph>, <list>, <item>, or <table> element. A <caption> contains plain text and may contain links
30 (see 3.3.2.4.3 Links), and can be coded using the <caption_cd> element. A <caption_cd> is optional and
31 non-repeatable, and must occur first within a <caption>16. The vocabulary domain for <caption_cd>,
32 DocumentSectionType, is externally-defined by LOINC. Example <caption_cd> values, drawn from the
33 DocumentSectionType vocabulary domain, are shown in the following table.
34
35 Table 25. Example concepts for <caption_cd> (CWE)
10154-3 Chief complaint 2.16.840.1.113883.6.1 LOINC
10155-0 History of allergies 2.16.840.1.113883.6.1 LOINC
10156-8 History of childhood 2.16.840.1.113883.6.1 LOINC
diseases
10157-6 History of family 2.16.840.1.113883.6.1 LOINC
member diseases
11349-8 History of past 2.16.840.1.113883.6.1 LOINC
1 16
4
illness
10167-5 History of surgical 2.16.840.1.113883.6.1 LOINC
procedures
10182-4 History of travel 2.16.840.1.113883.6.1 LOINC
11384-5 Physical 2.16.840.1.113883.6.1 LOINC
examination
10187-3 Review of systems 2.16.840.1.113883.6.1 LOINC
8716-3 Vital signs 2.16.840.1.113883.6.1 LOINC
1
2 Each <caption> has an optional local identifier (see 3.3.2.1.1 XML element identification), an optional set
3 of confidentiality status flags (see 3.3.2.1.2 Confidentiality), and an optional set of originators (see 3.3.2.1.3
5 (see 3.3.2.1.4 Language).
6
7 Figure 11. XML content model of <caption>
8 <!ELEMENT caption (#PCDATA | link | caption_cd)*>
9 <!ATTLIST caption
10 ID ID #IMPLIED
14 <!ELEMENT caption_cd %CE-cont.model;>
15 <!ATTLIST caption_cd
16 %CE-attrib.list;
17 ID ID #IMPLIED
21 3.3.2.2.3 Non_xml body

22 The CDA <non_xml> container represents a document body that is in some format other than XML. CDA's
23 <non_xml> is an encoded data type (ED), which is used only to reference data that is stored externally to
24 the CDA Level One document. To incorporate non-XML data within an XML document, see 3.3.2.4.5
25 Observation media.
26
27 The <non_xml> element has an optional local identifier (see 3.3.2.1.1 XML element identification), an
28 optional set of confidentiality status flags (see 3.3.2.1.2 Confidentiality), and an optional set of originators
29 (see 3.3.2.1.3 Originators). The human language of contained character data can be specified using the
30 xml:lang attribute (see 3.3.2.1.4 Language).
31
2
1 Figure 12. XML content model of <non_xml>
2 <!ELEMENT non_xml %ED-cont.model;>
3 <!ATTLIST non_xml
4 %ED-attrib.list;
5 ID ID #IMPLIED
9 3.3.2.3 Document Structures
10 3.3.2.3.1 Paragraphs
11 The CDA <paragraph> can occur in a <section>, <item>, or table cell (<td>). A <paragraph> has an
12 optional <caption> (see 3.3.2.2.2.1 Captions), followed by zero or more <content> elements (see 3.3.2.4.2
13 Content).
14
15 Each <paragraph> has an optional local identifier (see 3.3.2.1.1 XML element identification), an optional
16 set of confidentiality status flags (see 3.3.2.1.2 Confidentiality), and an optional set of originators (see
17 3.3.2.1.3 Originators). The human language of contained character data can be specified using the xml:lang
18 attribute (see 3.3.2.1.4 Language).
19
20 Figure 13. XML content model of <paragraph>
21 <!ELEMENT paragraph (caption?, content*) >
22 <!ATTLIST paragraph
23 ID ID #IMPLIED
27 3.3.2.3.2 Lists and list items

28 The CDA <list> can occur in a <section>, <item>, or table cell (<td>). A <list> has an optional <caption>
29 (see 3.3.2.2.2.1 Captions), and contains one or more <item> elements. The list_type attribute specifies
30 whether the <list> is ordered or unordered (with unordered being the default). Use an ordered list when the
31 ordering of list items is meaningful.
32
33 Each <list> has an optional local identifier (see 3.3.2.1.1 XML element identification), an optional set of
36 (see 3.3.2.1.4 Language).
37
38 The CDA <item> only occurs within a <list>. An <item> has an optional <caption> (see 3.3.2.2.2.1
39 Captions), and may contain <content> (see 3.3.2.4.2 Content) and nested structures (see 3.3.2.3 Document
40 Structures).
41
2
1 Each <item> has an optional local identifier (see 3.3.2.1.1 XML element identification), an optional set of
4 (see 3.3.2.1.4 Language).
5
6 Figure 14. XML content model of <list> and <item>
7 <!ELEMENT list (caption?, item+)>
8 <!ATTLIST list
9 list_type (ordered | unordered) "unordered"
10 ID ID #IMPLIED
14 <!ELEMENT item (caption?, (content | paragraph | list | table)*)>
15 <!ATTLIST item
16 ID ID #IMPLIED
20 3.3.2.3.3 Tabular material

21 In CDA Level One, any information can be presented as a table. The table markup is for presentation
22 purposes only and, unlike a database table, does not possess meaningful field names. The CDA <table> can
23 occur in a <section> or <item>. A <table> has an optional <caption> (see 3.3.2.2.2.1 Captions).
24
25 CDA modifies the strict XHTML table model (see 5.4 References and Appendix 5.3.1 Tables) by removing
26 formatting tags and by setting the content model of cells to be similar to the contents of other CDA
27 containers. The <th> element is modeled analogously to the <caption> element (see 3.3.2.2.2.1 Captions),
28 and like the <caption> element, the <caption_cd> is optional and non-repeatable, and must occur first.
29
30 Each element in the table model has an optional local identifier (see 3.3.2.1.1 XML element identification),
31 an optional set of confidentiality status flags (see 3.3.2.1.2 Confidentiality), and an optional set of
32 originators (see 3.3.2.1.3 Originators). The human language of contained character data can be specified
33 using the xml:lang attribute (see 3.3.2.1.4 Language).
34
2
1 Figure 15. Changes to the strict XHTML table model in CDA
2 Change this:
3 <!ELEMENT caption %Inline;>
4 To this:
6
7 Change these XML attributes:
8 %attrs;
9 To these:
10 ID ID #IMPLIED
14
15 Change this:
16 <!ELEMENT td %Flow;>
17 to this:
18 <!ELEMENT td (#PCDATA | content | link | coded_entry |

19 observation_media | paragraph | list | local_markup)*>
20
21 change this:
22 <!ELEMENT th %Flow;>
23 to this:
24 <!ELEMENT th (#PCDATA | link | caption_cd)*>
25 3.3.2.4 Document Entries
26 3.3.2.4.1 Character data

27 CDA character data (i.e., XML #PCDATA) occurs in <content>, <local_markup>, <caption>,
28 <link_html>, or table cells (both <td> and <th>).
29 3.3.2.4.2 Content
30 CDA <content> occurs in <local_markup>, table cells (<td>), <paragraph>, <item>, and nested within
31 <content>. The <content> element contains zero or more entries (see 3.3.2.4 Document Entries).
32
33 The <content> element can nest recursively, which enables wrapping a string of plain text down to as small
34 a chunk as desired. These <content> elements can serve as anchors, and <coded_entry.value> elements can
35 reference these anchors to indicate the original text that supports the use of a coded entry. (See 3.3.2.4.4
36 Coded entries for more detail.)
37
2
1 Each <content> element has an optional local identifier (see 3.3.2.1.1 XML element identification), an
3 (see 3.3.2.1.3 Originators). The human language of contained character data can be specified using the
5
6 Figure 16. XML content model of <content>
7 <!ELEMENT content (#PCDATA | content | link | coded_entry |

8 observation_media | local_markup)*>
9 <!ATTLIST content
10 ID ID #IMPLIED
14 3.3.2.4.3 Links
15 The CDA <link> is a generic referencing mechanism and occurs within <content>, <local_markup>, table
16 cells (<td>), or <caption>. A <link> contains a single required <link_html> element.
17
18 Each <link> has an optional local identifier (see 3.3.2.1.1 XML element identification), an optional set of
21 (see 3.3.2.1.4 Language).
22
23 The CDA <link_html> can only occur within a <link>. Each <link_html> has an optional local identifier
24 (see 3.3.2.1.1 XML element identification), an optional set of confidentiality status flags (see 3.3.2.1.2
25 Confidentiality), and an optional set of originators (see 3.3.2.1.3 Originators). The human language of
26 contained character data can be specified using the xml:lang attribute (see 3.3.2.1.4 Language).
27
28 The CDA link mechanism is based on the HTML anchor tag. Several groups (see 5.4 References) are
29 actively developing formal link specifications. When a suitable open standard is available and
30 implemented, it will be reviewed with the intent to incorporate it into the CDA Level One specification.
31
32 Multimedia that is integral to a document, and part of the attestable content of the document requires the
33 use of <observation_media> (see 3.3.2.4.5 Observation media). Multimedia that is simply referenced by the
34 document and not an integral part of the document should use <link>.
35
2
1 Figure 17. XML content model of <link> and <link_html>
2 <!ELEMENT link (link_html) >
3 <!ATTLIST link
4 ID ID #IMPLIED
8 <!ELEMENT link_html (#PCDATA) >
9 <!ATTLIST link_html
10 name CDATA #IMPLIED
11 href CDATA #IMPLIED
12 rel CDATA #IMPLIED
13 rev CDATA #IMPLIED
14 title CDATA #IMPLIED
15 ID ID #IMPLIED
19 3.3.2.4.4 Coded entries

20 The CDA element <coded_entry> inserts codes from HL7-recognized coding schemes into CDA
21 documents. Where there are no suitable HL7-recognized codes available, locally-defined codes can be
22 used. The use of <coded_entry> in CDA Level One is unrestricted, and the primary intent of
23 <coded_entry> is to facilitate document indexing, search and retrieval, and to provide a standard
24 convention for insertion of locally-meaningful codes.
25
26 The <coded_entry> element can occur in <section>, <content>, <local_markup>, or table cells (<td>). A
27 <coded_entry> contains an optional instance identifier, <coded_entry.id>, and a value,
28 <coded_entry.value>, which is modeled as an HL7 concept descriptor (CD) data type.
29
30 Each <coded_entry> has an optional local identifier (see 3.3.2.1.1 XML element identification), an optional
31 set of confidentiality status flags (see 3.3.2.1.2 Confidentiality), and an optional set of originators (see
32 3.3.2.1.3 Originators). The human language of contained character data can be specified using the xml:lang
34
35 Example <coded_entry.value> values are shown in the following table.
36
37 Table 26. Example concepts for <coded_entry.value>
D2-51000 Asthma 2.16.840.1.113883.6.5 SNOMED
D3-14000 Ischemic heart 2.16.840.1.113883.6.5 SNOMED
disease
D6-B7300 Muscle carnitine 2.16.840.1.113883.6.5 SNOMED
deficiency
6298-4 POTASSIUM:SCN 2.16.840.1.113883.6.1 LOINC
2
C:PT:BLD
5196-1 HEPATITIS B 2.16.840.1.113883.6.1 LOINC
VIRUS SURFACE
AG:ACNC:PT:SER
14909-6 SALICYLATES:SC 2.16.840.1.113883.6.1 LOINC
NC:PT:SER/PLAS
2428-1 HOMOCYSTEINE: 2.16.840.1.113883.6.1 LOINC
MCNC:PT:PLAS
997.61 Neuroma of 2.16.840.1.113883.6.3 ICD9CM
amputation stump
253.6 Syndrome of 2.16.840.1.113883.6.3 ICD9CM
inappropriate ADH
production
836.60 Open dislocation of 2.16.840.1.113883.6.3 ICD9CM
knee
1
2 Figure 18. XML content model of <coded_entry>
3 <!ELEMENT coded_entry (coded_entry.id?, coded_entry.value,

4 local_markup*)>
5 <!ATTLIST coded_entry
6 ID ID #IMPLIED
10 <!ELEMENT coded_entry.id %II-cont.model;>
11 <!ATTLIST coded_entry.id
12 %II-attrib.list;
13 ID ID #IMPLIED >
14 <!ELEMENT coded_entry.value %CD-cont.model;>
15 <!ATTLIST coded_entry.value
16 %CD-attrib.list;
17 ID ID #IMPLIED >
18
19 The <coded_entry.value> element can explicitly reference the original text within the document that
20 supports the use of the code. The process involves:
21
22  Assign a value to the XML ID attribute of the element that wraps the #PCDATA to be referenced.
23 (Because the <content> element is recursive, you can wrap as small a chunk of text as you want.)
24
25  The original text attribute (ORIGTXT) of the CD data type references the appropriate ID attribute.
26
27  The <coded_entry.value> element can be located in any legal position in the document.
28
2
1 Figure 19. Referencing original text with <coded_entry>17
2 In the first case, <coded_entry> is used to simply insert a code

3 into a CDA document, without referencing the original text:
4 <content>
5 Asthma, with prior smoking history. Difficulty weaning off

6 steroids. Will try gradual taper.
7 <coded_entry>
8 <coded_entry.value
9 V="D2-51000" S="2.16.840.1.113883.6.5" DN="Asthma"/>
10 </coded_entry>
11 </content>
12
13 In the second case, <coded_entry> explicitly references the
14 original text that supports the assigned code:
15 <content>
16 <content ID="String001">Asthma</content>, with prior smoking

17 history. Difficulty weaning off steroids. Will try gradual
18 taper.
19 <coded_entry>
20 <coded_entry.value ORIGTXT="String001"
21 V="D2-51000" S="2.16.840.1.113883.6.5" DN="Asthma"/>
22 </coded_entry>
23 </content>
24
25
1 17
Note that the exact mechanism and representation of intra-document referencing is contingent on the
2 outcome of the HL7 Version 3 Data Types, Release 1 DTD ballot.
4
1 3.3.2.4.5 Observation media
2 The <observation_media> element represents media that is logically a part of a CDA document, but is stored outside the document and incorporated by
3 reference. Multimedia that is integral to a document, and part of the attestable content of the document, requires the use of <observation_media>. Multimedia
4 that is simply referenced by the document and not an integral part of the document should use <link> (see 3.3.2.4.3 Links). Note that CDA's
5 <observation_media> is used only to reference data that is stored externally.
6
7 The CDA element <observation_media> is derived from the RIM Observation class. The <observation_media> element can occur in <content>, table cells
8 (<td>), or <local_markup>. An <observation_media> contains an optional instance identifier, <observation_media.id>, and a value, <observation_media.value>,
9 which is modeled as an HL7 encoded data (ED) data type.
10
11 The CDA does not take advantage of ED's ability to Base64 encode images and other observation media and include them directly in a document instance file.
12 Several groups (see 5.4 References) are actively developing formal specifications for packaging binary data within XML documents. When a suitable open
13 standard for direct incorporation of binary data is available and implemented, it will be incorporated into the CDA Level One specification.
14
15 Each <observation_media> has an optional local identifier (see 3.3.2.1.1 XML element identification), an optional set of confidentiality status flags (see 3.3.2.1.2
16 Confidentiality), and an optional set of originators (see 3.3.2.1.3 Originators). The human language of contained character data can be specified using the
18
19 Table 27. Hierarchical description of <observation_media>
(Attribute of
Association)
1. class observation observation observation_ observation_media observation_ N observation 1..1 M
as_ media _media
observation_
media
2. attr id observation id observation_media. observation_ D II 0..1 M
id media
3. attr value observation value observation_media. observation_ D ED 1..1 M
value media
20
21 * Abbreviations used in Hierarchical Description
22
Abbreviation Appears in column Definition
M Mandatory If an element is present, it may not contain a null value. Note that the column labeled "cardinality" determines

2
whether or not an element must be present. The column labeled "mandatory" determines whether or not
elements that are present are allowed to contain null values.
ED Data Type Encoded data data type.
II Data Type Instance Identifier data type.
attr Row Type This row is defining the use of a RIM attribute.
D Source of Element The RIM attribute described in this row is modeled as the data type stated in the "Data Type" column.
N Source of Element This is the first time that the RIM attribute described in this row appears in this Hierarchical Description.
1
2
3 Figure 20. XML content model of <observation_media>
4 <!ELEMENT observation_media (observation_media.id?, observation_media.value, local_markup*)>
5 <!ATTLIST observation_media
6 ID ID #IMPLIED
10 <!ELEMENT observation_media.id %II-cont.model;>
11 <!ATTLIST observation_media.id
12 %II-attrib.list;
13 ID ID #IMPLIED >
14 <!ELEMENT observation_media.value %ED-cont.model;>
15 <!ATTLIST observation_media.value
16 %ED-attrib.list;
17 ID ID #IMPLIED >
18

2
1 3.3.2.4.6 Localization
2 The implementation of localization in the CDA Level One Body using the <local_markup> element
3 parallels the implementation described above for the CDA Header (see 3.2.2.6 Localization). For additional
4 implementation notes on localization, see Appendix 5.3.3 Localization and 5.3.4 Transformation issues.
5
6 The <local_markup> element can occur in <coded_entry>, <observation_media>, <content>, table cells
7 (<td>), and can be nested in <local_markup>. The <local_markup> element contains zero or more entries
8 (see 3.3.2.4 Document Entries).
9
10 Each <local_markup> has an optional local identifier (see 3.3.2.1.1 XML element identification), an
12 (see 3.3.2.1.3 Originators). The language of contained character data can be specified using the xml:lang
14
15 The descriptor attribute describes the element, and the value can be drawn from a local vocabulary domain.
16 The ignore attribute tells the receiver to ignore just the <local_markup> tag (ignore="markup"), or to
17 ignore the <local_markup> tag and all contained content (ignore="all"). The render attribute indicates how
18 the sender would render the contents. The value can be drawn from a local vocabulary domain. The nested
19 <local_attr> element makes it easier to map local XML attribute values into the CDA.
20
21 Figure 21. XML content model of <local_markup>
22 <!ELEMENT local_markup (#PCDATA | content | link | coded_entry |

23 observation_media | local_markup | local_attr)* >
24 <!ATTLIST local_markup
28 ID ID #IMPLIED
36 ID ID #IMPLIED
38
2
1 3.3.3 XML Document Type Definition
2 
15
16
17 
25
26 <!ENTITY % CDA-Header-1.0 PUBLIC
27 "-//HL7//DTD CDA Header 1.0//EN"
28 "header_1.0.dtd" >
29 %CDA-Header-1.0;
30
31
32 
9
10 <!ENTITY % body_atts "
11 %common_atts;
15 ">
16
17 <!ENTITY % entries "#PCDATA | content | link | coded_entry |
18 observation_media | local_markup">
19
20 <!ENTITY % structures "paragraph | list | table">
21
22
23 
42
43 <!ELEMENT levelone (clinical_document_header, body) >
44 <!ATTLIST levelone
45 %body_atts;
46 >
47
48
49 
16
17 <!ELEMENT body (section+ | non_xml) >
18 <!ATTLIST body
19 %body_atts;
20 >
21
22 <!ELEMENT section (caption?,(%structures; | section)*, coded_entry*)>
23 <!ATTLIST section
24 %body_atts;
25 >
26
27 <!ELEMENT non_xml %ED-cont.model;>
28 <!ATTLIST non_xml
29 %common_atts;
32 %ED-attrib.list;
33 >
34
35
36 
45
46 
5
6 <!ELEMENT content (%entries;)*>
7 <!ATTLIST content
8 %body_atts;
9 >
10
11
12 
39
40 <!ELEMENT link (link_html) >
41 <!ATTLIST link
42 %body_atts;
43 >
44
45 <!ELEMENT link_html (#PCDATA) >
46 <!ATTLIST link_html
47 name CDATA #IMPLIED
48 href CDATA #IMPLIED
49 rel CDATA #IMPLIED
50 rev CDATA #IMPLIED
51 title CDATA #IMPLIED
52 %body_atts;
53 >
54
55
56 
15
16 <!ELEMENT coded_entry (coded_entry.id?, coded_entry.value,
17 local_markup*)>
18 <!ATTLIST coded_entry
19 %body_atts;>
20
21 <!ELEMENT coded_entry.id %II-cont.model;>
22 <!ATTLIST coded_entry.id
23 %common_atts;
24 %II-attrib.list; >
25
26 <!ELEMENT coded_entry.value %CD-cont.model;>
27 <!ATTLIST coded_entry.value
28 %CD-attrib.list;
29 %common_atts;>
30
31 
53
54 <!ELEMENT observation_media (observation_media.id?,
55 observation_media.value, local_markup*)>
56 <!ATTLIST observation_media
57 %body_atts;
2
1 HL7-NAME CDATA #FIXED 'observation'
2 T CDATA #FIXED 'observation'>
3
4 <!ELEMENT observation_media.id %II-cont.model;>
5 <!ATTLIST observation_media.id
6 %common_atts;
7 %II-attrib.list;
8 HL7-NAME CDATA #FIXED 'id'>
9
10 <!ELEMENT observation_media.value %ED-cont.model;>
11 <!ATTLIST observation_media.value
12 %common_atts;
13 %ED-attrib.list;
14 HL7-NAME CDATA #FIXED 'value'>
15
16
17 
35
36 <!ELEMENT local_markup (%entries; | local_attr)* >
37 <!ATTLIST local_markup
41 %body_atts;
42 >
43
44
45 
54
55 
8
9 <!ELEMENT paragraph (caption?, content*) >
10 <!ATTLIST paragraph
11 %body_atts;
12 >
13
14
15 
32
33 <!ELEMENT list (caption?, item+)>
34 <!ATTLIST list
35 %body_atts;
36 list_type (ordered | unordered) "unordered"
37 >
38
39 <!ELEMENT item (caption?, (content | %structures;)*)>
40 <!ATTLIST item
41 %body_atts;
42 >
43
44
45 
32
33 
34
35 <!ENTITY % Character "CDATA">
36 
37
38 <!ENTITY % Length "CDATA">
39 
40
41 <!ENTITY % MultiLength "CDATA">
42 
43
44 <!ENTITY % Number "CDATA">
45 
46
47 <!ENTITY % Pixels "CDATA">
48 
49
50 <!ENTITY % Text "CDATA">
51
52 
54
55 
56
57 
8 <!ENTITY % TFrame "(void|above|below|hsides|lhs|rhs|vsides|box|border)">
9
10 
16
17 <!ENTITY % TRules "(none | groups | rows | cols | all)">
18
19 
24 <!ENTITY % cellhalign
25 "align (left|center|right|justify|char) #IMPLIED
26 char %Character; #IMPLIED
27 charoff %Length; #IMPLIED"
28 >
29
30 
31 <!ENTITY % cellvalign
32 "valign (top|middle|bottom|baseline) #IMPLIED"
33 >
34
35 <!ELEMENT table
36 (caption?, (col*|colgroup*), thead?, tfoot?, (tbody+|tr+))>
38 <!ELEMENT caption_cd %CE-cont.model;>
39 <!ELEMENT thead (tr)+>
40 <!ELEMENT tfoot (tr)+>
41 <!ELEMENT tbody (tr)+>
42 <!ELEMENT colgroup (col)*>
43 <!ELEMENT col EMPTY>
44 <!ELEMENT tr (th|td)+>
46 <!ELEMENT td (%entries; | paragraph | list)*>
47
48 <!ATTLIST table
49 %body_atts;
50 summary %Text; #IMPLIED
51 width %Length; #IMPLIED
52 border %Pixels; #IMPLIED
53 frame %TFrame; #IMPLIED
54 rules %TRules; #IMPLIED
55 cellspacing %Length; #IMPLIED
56 cellpadding %Length; #IMPLIED
57 >
2
1
2 <!ATTLIST caption
3 %body_atts;
4 >
5
6 <!ATTLIST caption_cd
7 %body_atts;
8 %CE-attrib.list;
9 >
10
11 
15 <!ATTLIST colgroup
16 %body_atts;
17 span %Number; "1"
18 width %MultiLength; #IMPLIED
19 %cellhalign;
20 %cellvalign;
21 >
22
23 
35 <!ATTLIST col
36 %body_atts;
37 span %Number; "1"
38 width %MultiLength; #IMPLIED
39 %cellhalign;
40 %cellvalign;
41 >
42
43 
55 <!ATTLIST thead
56 %body_atts;
57 %cellhalign;
2
1 %cellvalign;
2 >
3
4 <!ATTLIST tfoot
5 %body_atts;
6 %cellhalign;
7 %cellvalign;
8 >
9
10 <!ATTLIST tbody
11 %body_atts;
12 %cellhalign;
13 %cellvalign;
14 >
15
16 <!ATTLIST tr
17 %body_atts;
18 %cellhalign;
19 %cellvalign;
20 >
21
22 
23 <!ENTITY % Scope "(row|col|rowgroup|colgroup)">
24
25 
26
27 <!ATTLIST th
28 %body_atts;
29 abbr %Text; #IMPLIED
30 axis CDATA #IMPLIED
31 headers IDREFS #IMPLIED
32 scope %Scope; #IMPLIED
33 rowspan %Number; "1"
34 colspan %Number; "1"
35 %cellhalign;
36 %cellvalign;
37 >
38
39 <!ATTLIST td
40 %body_atts;
41 abbr %Text; #IMPLIED
42 axis CDATA #IMPLIED
43 headers IDREFS #IMPLIED
44 scope %Scope; #IMPLIED
45 rowspan %Number; "1"
46 colspan %Number; "1"
47 %cellhalign;
48 %cellvalign;
49 >
50
2
1 4 Glossary
2
Term or Abbreviation Definition
Architecture An architecture for structured documents defines relationships between documents and
document specifications in terms of specialization and inheritance (see also CDA
architecture)
ASCII American Standard Code for Information Interchange, a common 8-bit character
encoding
CDA Clinical Document Architecture
CDA document A defined and complete information object that can exist outside of a messaging context
and/or can be a payload within an HL7 message. Includes the CDA Header and CDA
Body.
CDA Level One DTD The CDA Level One specification, expressed as an XML DTD.
Clinical document 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.
 Stewardship – A clinical document is maintained by a person or organization

entrusted with its care.
 Potential for authentication - A clinical document is an assemblage of information

that is intended to be legally authenticated.
 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.

Clinical Document The architecture described by this proposal
Architecture (CDA)
CNE Coded, No Extensions
Coded, No Extensions If a vocabulary domain is "Coded, No Extensions" (CNE) , then the only allowable
(CNE) values for the CDA component are those in the vocabulary domain.
Coded, With Extensions If a vocabulary domain is "Coded, With Extensions" (CWE), then local codes and other
(CWE) values not in the vocabulary domain can be used if necessary.
Conformance A valid document that complies with all of the HL7 rules and constraints [see also 5.3.2
Validation and conformance]
CWE Coded, With Extensions
Declaration See XML declaration
Document type declaration Contains or points to the markup declarations that provide a grammar for a class of
documents; (see DTD)
Document type definition A grammar for a class of documents; a type of XML schema
(DTD)
DTD Document Type Definition
Granularity The relative size of a defined unit; in the context of this specification, granularity refers
to the size of an information unit where <section> would be course grained and a data
point would be fine grained.
HD Hierarchical Description
Hierarchical Description Serialization of subset of RIM objects, attributes, and associations with constraints on
(HD) usage presented in table form. (Similar to the Hierarchical Message Description [HMD]
defined in the 1999 HL7 Message Development Framework [MDF]).
HL7 Health Level Seven
2
HTML Hypertext Markup Language, a specification of the W3C
Legal authentication A completion status in which a document has been signed manually or electronically by
the individual who is legally responsible for that document. This is the most mature state
in the workflow progression.
Level A quantum set of specializations within the CDA
Level One CDA Level One. The lowest, coarsest-grained level in the HL7 Clinical Document
Architecture
Level Three CDA Level Three. The third, most detailed level of the HL7 Clinical Document
Architecture
Level Two CDA Level Two. The second level of the HL7 Clinical Document Architecture
Local document The original, authenticated form of a document. Typically, local documents will not be
limited to CDA markup.
LOINC Logical Observations, Identifiers, Names, and Codes
(http://www.regenstrief.org/loinc/loinc.htm)
Markup Computer-processible annotations within a multimedia document. In the context of this
specification, markup syntax is according to the XML Recommendation
MDF HL7 Message Development Framework
MIME Multipurpose Internet Mail Extensions (MIME, RFC 2046)
Prolog An XML document structure. “Front matter” consisting of the XML Declaration and a
Document Type Declaration
Reference Information An information model used as the ultimate defining reference for all HL7 standards.
Model (RIM)
RIM Reference Information Model
Schema A formal definition of the structure and content of a class of document. (See also XML
Schemas)
Semantic In the context of a technical specification, semantic refers to the meaning of an element
as distinct from its syntax. Syntax can change without affecting semantics.
SGML Standard Generalized Markup Language, ISO 8879:1986(E) as amended and corrected
SNOMED Systematized Nomenclature of Medicine (http://www.snomed.org/)
Source document See "Local document".
UML Unified Modeling Language, a specification of the Object Management Group (OMG)
(http://www.omg.org/technology/uml/)
URI Uniform Resource Indicator
Valid document A document which meets all of the validity constraints in the XML Specification
W3C The World Wide Web Consortium, an international industry consortium
(http://www.w3.org)
Well-formed document A document which meets all of the well-formedness constraints in the XML
Specification
XHTML XHTML 1.0. A Reformulation of HTML 4 in XML 1.0. W3C Recommendation 26-
January-2000. (www.w3.org/TR/xhtml1/)
XML Extensible Markup Language, specification of the W3C, a formal subset of SGML
(http://www.w3.org/TR/REC-xml)
XML Declaration Markup stating that the document is an XML document and stating to which version of
the XML specification the document is conformant
XML document An XML document consists of a prolog, root document element, and other objects. A
data object is an XML document if it is well-formed, as defined in the XML
specification.
XSL Extensible Style Language, a specification of the W3C (www.w3.org/Style/XSL/)
XSLT XSL transformation language, a specification of the W3C
(http://www.w3.org/TR/1999/REC-xslt-19991116)
1
2
2
1 5 Appendices (non-normative)
2 The appendices contain non-normative material supplied as aids to understanding and implementing the
3 technical specifications described above.
4
5 Appendix 5.1 "Samples" presents a sample document, both as it might appear in a typical word-processor,
6 and how it would appear when represented as a CDA Level One document instance. We present an XSLT
7 style sheet that transforms the CDA document instance into the included HTML instance.
8
9 Appendix 5.2 "CDA Level One Body UML model" provides a UML model that is a very literal expression
10 of the CDA Level One Body portion of the CDA Level One DTD. We note however that the
11 expressiveness of UML and DTD differs, so that certain constraints expressed within the DTD (such as the
12 ordering of elements within a content model) are not explicitly represented in the UML model.
13
14 Appendix 5.3 "CDA Implementation Notes" contains additional material of value to implementers. Section
15 5.3.1 "Tables" describe CDA's goals and objectives for the use of tabular material. Section 5.3.2
16 "Validation and conformance" describes CDA conformance determinants. Section 5.3.3 "Localization" and
17 section 5.3.4 "Transformation issues" describe considerations that arise when mapping from a local
18 implementation into CDA. Section 5.3.5 "Representing authenticated content" discusses the markup of
19 legally authenticated content within CDA documents.
20
21 Appendix 5.4 "References" enumerates those HL7 specifications, W3C specifications, and other Standards
22 and literature that have contributed to the development of the CDA.
23
24 Last, but certainly not least, appendix 5.5 "Acknowledgements" recognizes the many contributors to this
25 specification. The collaborative spirit and the enormous personal contributions made by these individuals
26 are greatly appreciated.
27 5.1 Samples
28 5.1.1 Sample document

29
30 Good Health Clinic Consultation note
31
32 Consultant: Robert Dolin, MD
33 Date: April 7, 2000
34 Patient: Henry Levin, the 7th MRN: 12345 Sex: Male
35 Birthdate: September 24, 1932
36
37 History of Present Illness
38 Henry Levin, the 7th is a 67 year old male referred for further asthma management. Onset of asthma in his
39 teens. He was hospitalized twice last year, and already twice this year. He has not been able to be weaned
40 off steroids for the past several months.
41
42 Past Medical History
43  Asthma
44  Hypertension
45  Osteoarthritis, right knee
46
47 Medications
48  Theodur 200mg BID
49  Proventil inhaler 2puffs QID PRN
2
1  Prednisone 20mg qd
2  HCTZ 25mg qd
3
4 Allergies
5  Penicillin - Hives
6  Aspirin - Wheezing
7
8 Social History
9  Smoking :: 1 PPD between the ages of 20 and 55, and then he quit.
10  Alcohol :: Rare
11
12 Physical Exam
13  Vital Signs :: BP 118/78; Wt 185lb; Resp 16 and unlabored; T 98.6F; HR 86 and regular.
14  Skin :: Erythematous rash, palmar surface, left index finger.
15
16  Lungs :: Clear with no wheeze. Good air flow.
17  Cardiac :: RRR with no murmur, no S3, no S4.
18
19 Labs
20  CXR 02/03/1999: Hyperinflated. Normal cardiac silhouette, clear lungs.
21  Peak Flow today: 260 l/m.
22
23 Assessment
24  Asthma, with prior smoking history. Difficulty weaning off steroids. Will try gradual taper.
25  Hypertension, well-controlled.
26  Contact dermatitis on finger.
27
28 Plan
29  Complete PFTs with lung volumes.
30  Chem-7
31  Provide educational material on inhaler usage and peak flow self-monitoring.
32  Decrease prednisone to 20qOD alternating with 18qOD.
33  Hydrocortisone cream to finger BID.
34  RTC 1 week.
35
36 Signed by: Robert Dolin, MD April 8, 2000
37
2
1 5.1.2 Sample CDA document 18
2 The following two sample CDA documents both encode the preceding sample. The first CDA document
3 uses rich markup in order to illustrate many of the features of CDA. The second CDA document uses
4 minimal markup to illustrate mainly just the required features of CDA.
5 5.1.2.1 Sample CDA document with rich markup

6 <?xml version="1.0"?>
7 <!DOCTYPE levelone PUBLIC "-//HL7//DTD CDA Level One 1.0//EN" "levelone_1.0.dtd">
8 <levelone>
9 <clinical_document_header>
10 <id EX="a123" RT="2.16.840.1.113883.3.933"/>
11 <set_id EX="B" RT="2.16.840.1.113883.3.933"/>
12 <version_nbr V="2"/>
13 <document_type_cd V="11488-4" S="2.16.840.1.113883.6.1"
14 DN="Consultation note"/>
15 <origination_dttm V="2000-04-07"/>
16 <confidentiality_cd ID="CONF1" V="N" S="2.16.840.1.113883.5.10228"/>
17 <confidentiality_cd ID="CONF2" V="R" S="2.16.840.1.113883.5.10228"/>
18 <document_relationship>
19 <document_relationship.type_cd V="RPLC"/>
20 <related_document>
21 <id EX="a234" RT="2.16.840.1.113883.3.933"/>
22 <set_id EX="B" RT="2.16.840.1.113883.3.933"/>
23 <version_nbr V="1"/>
24 </related_document>
25 </document_relationship>
26 <fulfills_order>
27 <fulfills_order.type_cd V="FLFS"/>
28 <order><id EX="x23ABC" RT="2.16.840.1.113883.3.933"/></order>
29 <order><id EX="x42CDE" RT="2.16.840.1.113883.3.933"/></order>
30 </fulfills_order>
31 <patient_encounter>
32 <id EX="KPENC1332" RT="2.16.840.1.113883.3.933"/>
33 <practice_setting_cd V="GIM"
34 S="2.16.840.1.113883.5.10588" DN="General internal medicine clinic"/>
35 <encounter_tmr V="2000-04-07"/>
36 <service_location>
37 <id EX="KXLPa123" RT="2.16.840.1.113883.3.933"/>
38 <addr>
39 <HNR V="970"/>
40 <STR V="Post St"/>
41 <DIR V="NE"/>
42 <CTY V="Alameda"/>
43 <STA V="CA"/>
44 <ZIP V="94501"/>
45 </addr>
46 </service_location>
47 </patient_encounter>
48 <legal_authenticator>
49 <legal_authenticator.type_cd V="SPV"/>
50 <participation_tmr V="2000-04-08"/>
51 <signature_cd V="S"/>
52 <person>
53 <id EX="KP00017" RT="2.16.840.1.113883.3.933"/>
54 <person_name>
55 <nm>
56 <GIV V="Robert"/>
57 <FAM V="Dolin"/>
58 <SFX V="MD" QUAL="PT"/>
59 </nm>
60 <person_name.type_cd V="L" S="2.16.840.1.113883.5.200"/>
61 </person_name>
62 <addr>
63 <HNR V="970"/>
1 Note that the exact representation is contingent on the outcome of the HL7 Version 3 Data Types,
18
2 Release 1 DTD ballot.

4
1 <STR V="Post St"/>
2 <DIR V="NE"/>
3 <CTY V="Alameda"/>
4 <STA V="CA"/>
5 <ZIP V="94501"/>
6 </addr>
7 <telecom V="tel:(358)555-1234" USE="WPN"/>
8 </person>
9 </legal_authenticator>
10 <originator>
11 <originator.type_cd V="AUT"/>
13 <person>
14 <id EX="KP00017" RT="2.16.840.1.113883.3.933"/>
15 <person_name>
16 <nm>
18 <FAM V="Dolin"/>
19 <SFX V="MD"/>
20 </nm>
22 </person_name>
23 </person>
24 </originator>
25 <originating_organization>
26 <originating_organization.type_cd V="CST"/>
27 <organization>
28 <id EX="M345" RT="2.16.840.1.113883.3.933"/>
29 <organization.nm V="Good Health Clinic"/>
30 </organization>
31 </originating_organization>
32 <provider>
33 <provider.type_cd V="CON"/>
35 <person>
36 <id EX="KP00017" RT="2.16.840.1.113883.3.933"/>
37 </person>
38 </provider>
39 <patient>
40 <patient.type_cd V="PATSBJ"/>
41 <person>
42 <id EX="12345" RT="2.16.840.1.113883.3.933"/>
43 <person_name>
44 <nm>
45 <GIV V="Henry"/>
46 <FAM V="Levin"/>
47 <SFX V="the 7th"/>
48 </nm>
50 </person_name>
51 <person_name>
52 <nm>
53 <GIV V="Hank"/>
54 <FAM V="Levin"/>
55 </nm>
56 <person_name.type_cd V="A" S="2.16.840.1.113883.5.200"/>
57 </person_name>
58 </person>
59 <birth_dttm V="1932-09-24"/>
60 <administrative_gender_cd V="M" S="2.16.840.1.113883.5.1"/>
61 </patient>
62 <originating_device ID="DEV1">
63 <originating_device.type_cd V="ODV"/>
64 <device>
65 <id EX="devX3498" RT="2.16.840.1.113883.3.933"/>
66 <responsibility>
67 <responsibility.type_cd V="MNT" S="2.16.840.1.113883.5.10416"/>
68 <person>
69 <id EX="KP03257" RT="2.16.840.1.113883.3.933"/>
70 </person>
71 </responsibility>
2
1 </device>
2 </originating_device>
3 <local_header ignore="all" descriptor="MyLocalTag">
4 ... extra stuff that is only used locally ...
5 </local_header>
6 </clinical_document_header>
7 <body confidentiality="CONF1">
8 <section>
9 <caption>
10 <caption_cd V="10164-2" S="2.16.840.1.113883.6.1"/>
12 </caption>
13 <paragraph>
14 <content>
15 Henry Levin, the 7th is a 67 year old male referred for further
16 asthma management. Onset of asthma in his teens. He was hospitalized
17 twice last year, and already twice this year. He has not been able to
18 be weaned off steroids for the past several months.
19 </content>
20 </paragraph>
21 </section>
22 <section>
23 <caption>Past Medical History</caption>
24 <list>
25 <item><content>Asthma</content></item>
26 <item><content>Hypertension</content></item>
27 <item><content>Osteoarthritis, right knee</content></item>
28 </list>
29 </section>
30 <section>
31 <caption>
32 <caption_cd V="10160-0" S="2.16.840.1.113883.6.1"/>Medications
33 </caption>
34 <list>
35 <item><content>Theodur 200mg BID</content></item>
36 <item><content>Proventil inhaler 2puffs QID PRN</content></item>
37 <item><content>Prednisone 20mg qd</content></item>
38 <item><content>HCTZ 25mg qd</content></item>
39 </list>
40 </section>
41 <section>
42 <caption>Allergies</caption>
43 <list>
44 <item><content>Penicillin - Hives</content></item>
45 <item><content>Aspirin - Wheezing</content></item>
46 </list>
47 </section>
48 <section>
49 <caption>Social History</caption>
50 <list>
51 <item>
52 <content>
53 Smoking :: 1 PPD between the ages of 20 and 55, and then he quit.
54 </content>
55 </item>
56 <item><content>Alcohol :: rare</content></item>
57 </list>
58 </section>
59 <section>
60 <caption>
61 <caption_cd V="11384-5" S="2.16.840.1.113883.6.1"/>Physical Examination
62 </caption>
63 <section>
64 <caption>
65 <caption_cd V="8716-3" S="2.16.840.1.113883.6.1"/>Vital Signs
66 </caption>
67 <list>
68 <item><content>BP 118/78</content></item>
69 <item><content>Resp 16 and unlabored</content></item>
70 <item><content>T 98.6F</content></item>
71 <item><content>HR 86 and regular</content></item>
2
1 </list>
2 </section>
3 <section>
4 <caption>
5 <caption_cd V="8709-8" S="2.16.840.1.113883.6.1"/>Skin
6 </caption>
7 <paragraph>
8 <content>Erythematous rash, palmar surface, left index finger.
9 <observation_media>
10 <observation_media.value MT="image/jpeg">
11 <REF V="rash.jpeg"/>
12 </observation_media.value>
13 </observation_media>
14 </content>
15 </paragraph>
16 </section>
17 <section>
18 <caption>
19 <caption_cd V="11391-0" S="2.16.840.1.113883.6.1"/>Lungs
20 </caption>
21 <paragraph>
22 <content>Clear with no wheeze. Good air flow.</content>
23 </paragraph>
24 </section>
25 <section>
26 <caption>Cardiac</caption>
27 <paragraph>
28 <content>RRR with no murmur, no S3, no S4.</content>
29 </paragraph>
30 </section>
31 </section>
32 <section confidentiality="CONF2">
33 <caption>
34 <caption_cd V="11502-2" S="2.16.840.1.113883.6.1"/>Labs
35 </caption>
36 <list>
37 <item>
38 <content>
39 CXR 02/03/1999: Hyperinflated. Normal cardiac silhouette, clear lungs.
40 </content>
41 </item>
42 <item originator="DEV1"><content>Peak Flow today: 260 l/m</content></item>
43 </list>
44 </section>
45 <section>
46 <caption>
47 <caption_cd V="11496-7" S="2.16.840.1.113883.6.1"/>Assessment
48 </caption>
49 <list>
50 <item>
51 <content>
52 <content ID="String001">Asthma</content>, with prior smoking
53 history. Difficulty weaning off steroids. Will try gradual taper.
54 <coded_entry>
55 <coded_entry.value ORIGTXT="String001"
56 V="D2-51000" S="2.16.840.1.113883.6.5"/>
57 </coded_entry>
58 </content>
59 </item>
60 <item><content>Hypertension, well-controlled.</content></item>
61 <item><content>Contact dermatitis on finger.</content></item>
62 </list>
63 </section>
64 <section>
65 <caption>
66 <caption_cd V="1234-X" S="2.16.840.1.113883.6.1"/>Plan
67 </caption>
68 <list>
69 <item><content>Complete PFTs with lung volumes.</content></item>
70 <item><content>Chem-7</content></item>
71 <item>
2
1 <content>
2 Provide educational material on inhaler usage and peak flow self-monitoring.
3 </content>
4 </item>
5 <item>
6 <content>Decrease prednisone to 20qOD alternating with 18qOD.</content>
7 </item>
8 <item><content>Hydrocortisone cream to finger BID.</content></item>
9 <item><content>RTC 1 week.</content></item>
10 </list>
11 </section>
12 </body>
13 </levelone>
14 5.1.2.2 Sample CDA document with minimal markup

15 <?xml version="1.0"?>
16 <!DOCTYPE levelone PUBLIC "-//HL7//DTD CDA Level One 1.0//EN" "levelone_1.0.dtd">
17 <levelone>
18 <clinical_document_header>
19 <id EX="a123" RT="2.16.840.1.113883.3.933"/>
20 <document_type_cd V="11488-4" S="2.16.840.1.113883.6.1"
21 DN="Consultation note"/>
22 <origination_dttm V="2000-04-07"/>
23 <patient_encounter>
24 <id EX="KPENC1332" RT="2.16.840.1.113883.3.933"/>
25 <practice_setting_cd V="GIM"
26 S="2.16.840.1.113883.5.10588" DN="General internal medicine clinic"/>
27 <encounter_tmr V="2000-04-07"/>
28 </patient_encounter>
29 <legal_authenticator>
30 <legal_authenticator.type_cd V="SPV"/>
32 <signature_cd V="S"/>
33 <person>
34 <id EX="KP00017" RT="2.16.840.1.113883.3.933"/>
35 <person_name>
36 <nm>
38 <FAM V="Dolin"/>
39 <SFX V="MD" QUAL="PT"/>
40 </nm>
42 </person_name>
43 </person>
44 </legal_authenticator>
45 <originator>
46 <originator.type_cd V="AUT"/>
48 <person>
49 <id EX="KP00017" RT="2.16.840.1.113883.3.933"/>
50 </person>
51 </originator>
52 <originating_organization>
53 <originating_organization.type_cd V="CST"/>
54 <organization>
55 <id EX="M345" RT="2.16.840.1.113883.3.933"/>
56 <organization.nm V="Good Health Clinic"/>
57 </organization>
58 </originating_organization>
59 <provider>
60 <provider.type_cd V="CON"/>
62 <person>
63 <id EX="KP00017" RT="2.16.840.1.113883.3.933"/>
64 </person>
65 </provider>
66 <patient>
67 <patient.type_cd V="PATSBJ"/>
68 <person>
69 <id EX="12345" RT="2.16.840.1.113883.3.933"/>
2
1 <person_name>
2 <nm>
3 <GIV V="Henry"/>
4 <FAM V="Levin"/>
5 <SFX V="the 7th"/>
6 </nm>
8 </person_name>
9 </person>
10 <birth_dttm V="1932-09-24"/>
11 <administrative_gender_cd V="M" S="2.16.840.1.113883.5.1"/>
12 </patient>
13 </clinical_document_header>
14 <body>
15 <section>
16 <caption>History of Present Illness</caption>
17 <paragraph>
18 <content>
23 </content>
24 </paragraph>
25 </section>
26 <section>
27 <caption>Past Medical History</caption>
28 <list>
29 <item><content>Asthma</content></item>
30 <item><content>Hypertension</content></item>
31 <item><content>Osteoarthritis, right knee</content></item>
32 </list>
33 </section>
34 <section>
35 <caption>Medications</caption>
36 <list>
37 <item><content>Theodur 200mg BID</content></item>
38 <item><content>Proventil inhaler 2puffs QID PRN</content></item>
39 <item><content>Prednisone 20mg qd</content></item>
40 <item><content>HCTZ 25mg qd</content></item>
41 </list>
42 </section>
43 <section>
44 <caption>Allergies</caption>
45 <list>
46 <item><content>Penicillin - Hives</content></item>
47 <item><content>Aspirin - Wheezing</content></item>
48 </list>
49 </section>
50 <section>
51 <caption>Social History</caption>
52 <list>
53 <item>
54 <content>
56 </content>
57 </item>
58 <item><content>Alcohol :: rare</content></item>
59 </list>
60 </section>
61 <section>
62 <caption>Physical Examination</caption>
63 <section>
64 <caption>Vital Signs</caption>
65 <list>
66 <item><content>BP 118/78</content></item>
67 <item><content>Resp 16 and unlabored</content></item>
68 <item><content>T 98.6F</content></item>
69 <item><content>HR 86 and regular</content></item>
70 </list>
71 </section>
2
1 <section>
2 <caption>Skin</caption>
3 <paragraph>
4 <content>Erythematous rash, palmar surface, left index finger.
5 <observation_media>
6 <observation_media.value MT="image/jpeg">
7 <REF V="rash.jpeg"/>
8 </observation_media.value>
9 </observation_media>
10 </content>
11 </paragraph>
12 </section>
13 <section>
14 <caption>Lungs</caption>
15 <paragraph>
16 <content>Clear with no wheeze. Good air flow.</content>
17 </paragraph>
18 </section>
19 <section>
20 <caption>Cardiac</caption>
21 <paragraph>
22 <content>RRR with no murmur, no S3, no S4.</content>
23 </paragraph>
24 </section>
25 </section>
26 <section>
27 <caption>Labs</caption>
28 <list>
29 <item>
30 <content>
32 </content>
33 </item>
34 <item><content>Peak Flow today: 260 l/m</content></item>
35 </list>
36 </section>
37 <section>
38 <caption>Assessment</caption>
39 <list>
40 <item>
41 <content>
42 Asthma, with prior smoking
44 <coded_entry>
45 <coded_entry.value V="D2-51000" S="2.16.840.1.113883.6.5"/>
46 </coded_entry>
47 </content>
48 </item>
49 <item><content>Hypertension, well-controlled.</content></item>
50 <item><content>Contact dermatitis on finger.</content></item>
51 </list>
52 </section>
53 <section>
54 <caption>Plan</caption>
55 <list>
56 <item><content>Complete PFTs with lung volumes.</content></item>
57 <item><content>Chem-7</content></item>
58 <item>
59 <content>
61 </content>
62 </item>
63 <item>
64 <content>Decrease prednisone to 20qOD alternating with 18qOD.</content>
65 </item>
66 <item><content>Hydrocortisone cream to finger BID.</content></item>
67 <item><content>RTC 1 week.</content></item>
68 </list>
69 </section>
70 </body>
71 </levelone>
2
1 5.1.3 Sample XSLT stylesheet
2 Created according to W3C XSL Transformations Version 1.0, http://www.w3.org/TR/1999/REC-xslt-
3 19991116.
4
5 <?xml version='1.0'?>
6
7 <!DOCTYPE xsl:stylesheet [
8 <!ENTITY CDA-Stylesheet
9 '-//HL7//XSL HL7 V1.1 CDA Stylesheet: 2000-08-03//EN'>
10 ]>
11 <xsl:stylesheet version='1.0'
12 xmlns:xsl='http://www.w3.org/1999/XSL/Transform'>
13
14 <xsl:output method='html' indent='yes' version='4.01'
15 doctype-public='-//W3C//DTD HTML 4.01//EN'/>
16
17 <xsl:variable name='docType'
18 select='/levelone/clinical_document_header/document_type_cd/@DN'/>
19 <xsl:variable name='orgName'
20 select='/levelone/clinical_document_header/originating_organization/organization/
21 organization.nm/@V'/>
22 <xsl:variable name='title'>
23 <xsl:value-of select='$orgName'/>
24 <xsl:text> </xsl:text>
25 <xsl:value-of select='$docType'/>
26 </xsl:variable>
27
28 <xsl:template match='/levelone'>
29 <html>
30 <head>
31 <meta name='Generator' content='&CDA-Stylesheet;'/>
32 <xsl:comment>
33 do NOT edit this HTML directly, it was generated
34 via an XSLT transformation from the original Level 1
35 document.
36 </xsl:comment>
37 <style>
38 <xsl:comment>
39 body {background-color: white; color: black; }
40 
42 
43 p { margin: 10px 0 10px 0.25in; }
44 div.caption { font-weight: bold; text-decoration:
45 underline; }
46 span.caption { font-weight: bold; }
47 div.title { font-size: 18pt; font-weight: bold }
48 div.demographics { text-align: center ; }
49 </xsl:comment>
50 </style>
51
52 <title>
53 <xsl:value-of select='$title'/>
54 </title>
55 </head>
56 <body>
57 <div class='title'>
58 <xsl:value-of select='$title'/>
59 </div>
60 <br/>
61 <xsl:apply-templates select='clinical_document_header'/>
62 <br/>
63 <xsl:apply-templates select='body'/>
64 <xsl:call-template name='signature'/>
65 </body>
66 </html>
67 </xsl:template>
68
2
1 
19 <xsl:template match='clinical_document_header'>
20 <div class='demographics'>
21 <table border='0'>
22 <tbody>
23 <xsl:call-template name='encounter'/>
24 <xsl:call-template name='patient'/>
25 </tbody>
26 </table>
27 </div>
28 </xsl:template>
29
30 <xsl:template name='encounter'>
31 <tr>
32 <xsl:apply-templates select='provider'/>
33 </tr>
34 <tr>
35 <xsl:apply-templates select='patient_encounter/encounter_tmr'/>
36 </tr>
37 </xsl:template>
38
39 <xsl:template match='encounter_tmr'>
40 <th align='left' width='16.67%'>Date:</th>
41 <td align='left' width='16.67%'>
42 <xsl:call-template name='date'>
43 <xsl:with-param name='date' select='@V'/>
44 </xsl:call-template>
45 </td>
46 </xsl:template>
47
48 <xsl:template match='provider'>
49 <th align='left' width='16.67%'>
50 <xsl:call-template name='provider_type_cd'>
51 <xsl:with-param name='type_cd' select='provider.type_cd/@V'/>
53 <xsl:text>:</xsl:text>
54 </th>
56 <xsl:variable name='ptr' select='person/id/@EX'/>
57
58 <xsl:for-each
59 select='/levelone/clinical_document_header/originator/person[id/@EX=$ptr]'>
60 <xsl:call-template name='getName'/>
61 </xsl:for-each>
62 </td>
63 </xsl:template>
64
65 <xsl:template name='patient'>
66 <tr>
67 <xsl:apply-templates select='patient'/>
68 </tr>
69
70 <tr>
71 <xsl:apply-templates select='patient/birth_dttm'/>
2
1 </tr>
2 </xsl:template>
3
4 <xsl:template match='birth_dttm'>
5 <th align='left' width='16.67%'>Birthdate:</th>
8 <xsl:with-param name='date' select='@V'/>
10 </td>
11 </xsl:template>
12
13 <xsl:template match='patient'>
14 <th align='left' width='16.67%'>Patient:</th>
16 <xsl:for-each select='person'>
17 <xsl:call-template name='getName'/>
18 </xsl:for-each>
19 </td>
20 <th align='right' width='16.67%'>
21 <xsl:text>MRN:</xsl:text>
22 </th>
24 <xsl:value-of select='person/id/@EX'/>
25 </td>
26 <th align='right' width='16.66%'>Sex:</th>
28 <xsl:call-template name='administrative_gender_cd'>
29 <xsl:with-param name='gender_cd'
30 select='administrative_gender_cd/@V'/>
32 </td>
33 </xsl:template>
34
35 
38 <xsl:template match='body|caption|content'>
39 <xsl:apply-templates/>
40 </xsl:template>
41
42 
47 <xsl:template match='section'>
48 <div>
49 <div class='caption'>
50 <xsl:apply-templates select='caption'/>
51 </div>
52 <xsl:apply-templates select='paragraph|list|table|section'/>
53 </div>
54 </xsl:template>
55
56 <xsl:template match='section/section'>
57 <ul>
58 <li>
59 <span class='caption'>
61 <xsl:text> :: </xsl:text>
62 </span>
63 <xsl:apply-templates select='paragraph|list|table|section'/>
64 </li>
65 </ul>
66 </xsl:template>
67
68 
3 <xsl:template match='paragraph'>
4 <p>
5 <xsl:apply-templates select='content'/>
6 </p>
7 </xsl:template>
8
9 
13 <xsl:template match='list'>
14 <ul>
15 <xsl:for-each select='item'>
16 <li>
17 <xsl:if test='caption'>
19 <xsl:text> :: </xsl:text>
20 </xsl:if>
22 </li>
23 </xsl:for-each>
24 </ul>
25 </xsl:template>
26
27 
31 <xsl:template match='section/section/list'>
32 <xsl:for-each select='item'>
34 <xsl:if test='position()!=last()'>
35 <xsl:text>; </xsl:text>
36 </xsl:if>
37 </xsl:for-each>
38 </xsl:template>
39
40 <xsl:template match='section/section/paragraph'>
41 <span>
43 </span>
44 </xsl:template>
45
46 
53 <xsl:template match='table|table/caption|thead|tfoot|tbody|colgroup|col|tr|th|td'>
54 <xsl:copy>
55 <xsl:apply-templates select='*|@*|text()'/>
56 </xsl:copy>
57 </xsl:template>
58 <xsl:template match='table/@*|thead/@*|tfoot/@*|tbody/@*|colgroup/@*|col/@*|tr/@*|th/@*|
59 td/@*'>
60 <xsl:copy>
62 </xsl:copy>
63 </xsl:template>
64
65 
71 <xsl:template match='observation_media'>
2
1 <xsl:if test='observation_media.value[
2 @MT="image/gif" or @MT="image/jpeg"
3 ]'>
4 <br clear='all'/>
5 <xsl:element name='img'>
6 <xsl:attribute name='src'>
7 <xsl:value-of select='observation_media.value/REF/@V'/>
8 </xsl:attribute>
9 </xsl:element>
10 </xsl:if>
11 </xsl:template>
12
13 
18 <xsl:template match='link'>
19 <xsl:element name='a'>
20 <xsl:for-each select='link_html/@*'>
21 <xsl:if test='not(name()="originator" or
22 name()="confidentiality")'>
23 <xsl:attribute name='{name()}'>
24 <xsl:value-of select='.'/>
25 </xsl:attribute>
26 </xsl:if>
27 </xsl:for-each>
28 <xsl:value-of select='link_html'/>
29 </xsl:element>
30 </xsl:template>
31
32 
41 
50 <xsl:template match='@ignore'>
51 <xsl:choose>
52 <xsl:when test='.="markup"'>
53 <xsl:apply-templates select='../text()'/>
54 </xsl:when>
55 </xsl:choose>
56 </xsl:template>
57
58 
61 <xsl:template match='coded_entry'>
62 </xsl:template>
63
64 <xsl:template match='caption_cd'>
65 </xsl:template>
66
67
68 
2 <xsl:template name='signature'>
3 <xsl:variable name='signers'
4 select='/levelone/clinical_document_header/legal_authenticator/person'/>
5 <xsl:if test='$signers'>
6 <div>
7 <span class='caption'>Signed by:</span>
8 <xsl:for-each select='$signers'>
9 <xsl:call-template name='getName'>
10 <xsl:with-param name='person' select='.'/>
12 <xsl:text> on </xsl:text>
14 <xsl:with-param name='date'
15 select='../participation_tmr/@V'/>
17 </xsl:for-each>
18 </div>
19 </xsl:if>
20 </xsl:template>
21
22 
25 
31 <xsl:template name='getName'>
32 <xsl:apply-templates select='person_name[person_name.type_cd/@V="L"]'/>
33 </xsl:template>
34 <xsl:template match='person_name'>
35 <xsl:choose>
36 <xsl:when test='nm/GIV[@QUAL="RE"]/@V'>
37 <xsl:value-of select='nm/GIV[@QUAL="RE"]/@V'/>
38 </xsl:when>
39 <xsl:when test='nm/GIV[@CLAS="N"]/@V'>
40 <xsl:value-of select='nm/GIV[@CLAS="N"]/@V'/>
41 </xsl:when>
42 <xsl:otherwise>
43 <xsl:value-of select='nm/GIV/@V'/>
44 </xsl:otherwise>
45 </xsl:choose>
46 <xsl:text> </xsl:text>
47 <xsl:choose>
48 <xsl:when test='nm/FAM[@QUAL="RE"]/@V'>
49 <xsl:value-of select='nm/FAM[@QUAL="RE"]/@V'/>
50 </xsl:when>
51 <xsl:otherwise>
52 <xsl:value-of select='nm/FAM/@V'/>
53 </xsl:otherwise>
54 </xsl:choose>
55 <xsl:choose>
56 <xsl:when test='nm/SFX[@QUAL="RE"]/@V'>
57 <xsl:text>, </xsl:text>
58 <xsl:value-of select='nm/SFX[@QUAL="RE"]/@V'/>
59 </xsl:when>
60 <xsl:when test='nm/SFX/@V'>
61 <xsl:text>, </xsl:text>
62 <xsl:value-of select='nm/SFX/@V'/>
63 </xsl:when>
64 </xsl:choose>
65 </xsl:template>
66
67 
2
1 <xsl:template name='date'>
2 <xsl:param name='date'/>
3 <xsl:variable name='month' select='substring ($date, 6, 2)'/>
4 <xsl:choose>
5 <xsl:when test='$month=01'>
6 <xsl:text>January </xsl:text>
7 </xsl:when>
9 <xsl:text>February </xsl:text>
10 </xsl:when>
12 <xsl:text>March </xsl:text>
13 </xsl:when>
15 <xsl:text>April </xsl:text>
16 </xsl:when>
18 <xsl:text>May </xsl:text>
19 </xsl:when>
21 <xsl:text>June </xsl:text>
22 </xsl:when>
24 <xsl:text>July </xsl:text>
25 </xsl:when>
27 <xsl:text>August </xsl:text>
28 </xsl:when>
30 <xsl:text>September </xsl:text>
31 </xsl:when>
33 <xsl:text>October </xsl:text>
34 </xsl:when>
36 <xsl:text>November </xsl:text>
37 </xsl:when>
39 <xsl:text>December </xsl:text>
40 </xsl:when>
41 </xsl:choose>
42 <xsl:choose>
43 <xsl:when test='substring ($date, 9, 1)="0"'>
44 <xsl:value-of select='substring ($date, 10, 1)'/><xsl:text>,
45 </xsl:text>
46 </xsl:when>
47 <xsl:otherwise>
48 <xsl:value-of select='substring ($date, 9, 2)'/><xsl:text>,
49 </xsl:text>
50 </xsl:otherwise>
51 </xsl:choose>
52 <xsl:value-of select='substring ($date, 1, 4)'/>
53 </xsl:template>
54
55 
58 <xsl:template name='provider_type_cd'>
59 <xsl:param name='type_cd'/>
60 <xsl:choose>
61 <xsl:when test='$type_cd="CON"'>
62 <xsl:text>Consultant</xsl:text>
63 </xsl:when>
64 <xsl:when test='$type_cd="PRISURG"'>
65 <xsl:text>Primary surgeon</xsl:text>
66 </xsl:when>
67 <xsl:when test='$type_cd="FASST"'>
68 <xsl:text>First assistant</xsl:text>
69 </xsl:when>
70 <xsl:when test='$type_cd="SASST"'>
71 <xsl:text>Second assistant</xsl:text>
2
1 </xsl:when>
2 <xsl:when test='$type_cd="SNRS"'>
3 <xsl:text>Scrub nurse</xsl:text>
4 </xsl:when>
5 <xsl:when test='$type_cd="TASST"'>
6 <xsl:text>Third assistant</xsl:text>
7 </xsl:when>
8 <xsl:when test='$type_cd="NASST"'>
9 <xsl:text>Nurse assistant</xsl:text>
10 </xsl:when>
11 <xsl:when test='$type_cd="ANEST"'>
12 <xsl:text>Anesthetist</xsl:text>
13 </xsl:when>
14 <xsl:when test='$type_cd="ANRS"'>
15 <xsl:text>Anesthesia nurse</xsl:text>
16 </xsl:when>
17 <xsl:when test='$type_cd="MDWF"'>
18 <xsl:text>Midwife</xsl:text>
19 </xsl:when>
20 <xsl:when test='$type_cd="ATTPHYS"'>
21 <xsl:text>Attending physician</xsl:text>
22 </xsl:when>
23 <xsl:when test='$type_cd="ADMPHYS"'>
24 <xsl:text>Admitting physician</xsl:text>
25 </xsl:when>
26 <xsl:when test='$type_cd="DISPHYS"'>
27 <xsl:text>Discharging physician</xsl:text>
28 </xsl:when>
29 <xsl:when test='$type_cd="RNDPHYS"'>
30 <xsl:text>Rounding physician</xsl:text>
31 </xsl:when>
32 <xsl:when test='$type_cd="PCP"'>
33 <xsl:text>Primary care provider</xsl:text>
34 </xsl:when>
35 <xsl:otherwise>
36 <xsl:value-of select='$type_cd'/>
37 </xsl:otherwise>
38 </xsl:choose>
39 </xsl:template>
40
41 <xsl:template name='administrative_gender_cd'>
42 <xsl:param name='gender_cd'/>
43 <xsl:choose>
44 <xsl:when test='$gender_cd="M"'>
45 <xsl:text>Male</xsl:text>
46 </xsl:when>
47 <xsl:when test='$gender_cd="F"'>
48 <xsl:text>Female</xsl:text>
49 </xsl:when>
50 <xsl:otherwise>
51 <xsl:value-of select='$gender_cd'/>
52 </xsl:otherwise>
53 </xsl:choose>
54 </xsl:template>
55
56 </xsl:stylesheet>
2
1 5.1.4 HTML rendition of sample CDA document
2 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
3 <html>
4 <head>
5 <meta name="Generator" content="-//HL7//XSL HL7 V1.1 CDA Stylesheet: 2000-08-03//EN">
10 <style>
21 </style>
22 <title>Good Health Clinic Consultation note</title>
23 </head>
24 <body>
25 <div class="title">Good Health Clinic Consultation note</div>
26 <br>
27 <div class="demographics">
28 <table border="0">
29 <tbody>
30 <tr>
31 <th align="left" width="16.67%">Consultant:</th><td align="left" width="16.67%">Robert
32 Dolin, MD</td>
33 </tr>
34 <tr>
35 <th align="left" width="16.67%">Date:</th><td align="left" width="16.67%">April 7,
36 2000</td>
37 </tr>
38 <tr>
39 <th align="left" width="16.67%">Patient:</th><td align="left" width="16.67%">Henry Levin,
40 the 7th</td><th align="right" width="16.67%">MRN:</th><td align="left"
41 width="16.67%">12345</td><th align="right" width="16.66%">Sex:</th><td align="left"
42 width="16.66%">Male</td>
43 </tr>
44 <tr>
45 <th align="left" width="16.67%">Birthdate:</th><td align="left" width="16.67%">September
46 24, 1932</td>
47 </tr>
48 </tbody>
49 </table>
50 </div>
51 <br>
52 <div>
53 <div class="caption">
54
56 </div>
57 <p>
62 </p>
63 </div>
64 <div>
65 <div class="caption">Past Medical History</div>
66 <ul>
67 <li>Asthma</li>
68 <li>Hypertension</li>
69 <li>Osteoarthritis, right knee</li>
2
1 </ul>
2 </div>
3 <div>
5 Medications
6 </div>
7 <ul>
8 <li>Theodur 200mg BID</li>
9 <li>Proventil inhaler 2puffs QID PRN</li>
10 <li>Prednisone 20mg qd</li>
11 <li>HCTZ 25mg qd</li>
12 </ul>
13 </div>
14 <div>
15 <div class="caption">Allergies</div>
16 <ul>
17 <li>Penicillin - Hives</li>
18 <li>Aspirin - Wheezing</li>
19 </ul>
20 </div>
21 <div>
22 <div class="caption">Social History</div>
23 <ul>
24 <li>
26 </li>
27 <li>Alcohol :: rare</li>
28 </ul>
29 </div>
30 <div>
32 Physical Examination
33 </div>
34 <ul>
35 <li>
36 <span class="caption">
37 Vital Signs
38 :: </span>BP 118/78; Resp 16 and unlabored; T 98.6F; HR 86 and regular</li>
39 </ul>
40 <ul>
41 <li>
43 Skin
44 :: </span><span>
45 Erythematous rash, palmar surface, left index finger.
46 <br clear="all">
47 <img src="rash.jpeg">
48
49 </span>
50 </li>
51 </ul>
52 <ul>
53 <li>
55 Lungs
56 :: </span><span>
57 Clear with no wheeze. Good air flow.
58 </span>
59 </li>
60 </ul>
61 <ul>
62 <li>
63 <span class="caption">Cardiac :: </span><span>
64 RRR with no murmur, no S3, no S4.
65 </span>
66 </li>
67 </ul>
68 </div>
69 <div>
71 Labs
2
1 </div>
2 <ul>
3 <li>
5 </li>
6 <li>Peak Flow today: 260 l/m</li>
7 </ul>
8 </div>
9 <div>
11 Assessment
12 </div>
13 <ul>
14 <li>
15 Asthma, with prior smoking
17
18 </li>
19 <li>Hypertension, well-controlled.</li>
20 <li>Contact dermatitis on finger.</li>
21 </ul>
22 </div>
23 <div>
25 Plan
26 </div>
27 <ul>
28 <li>Complete PFTs with lung volumes.</li>
29 <li>Chem-7</li>
30 <li>
32 </li>
33 <li>Decrease prednisone to 20qOD alternating with 18qOD.</li>
34 <li>Hydrocortisone cream to finger BID.</li>
35 <li>RTC 1 week.</li>
36 </ul>
37 </div>
38 <div>
39 <span class="caption">Signed by:</span>Robert Dolin, MD on April 8, 2000</div>
40 </body>
41 </html>
2
1 5.2 CDA Level One Body UML model
2 This section provides a UML model that is a very literal expression of the CDA Level One Body portion of
3 the CDA Level One DTD. We note however that the expressiveness of UML and DTD differs, so that
4 certain constraints expressed within the DTD (such as the ordering of elements within a content model) are
5 not explicitly represented in the UML model.
6
7 Document analysis was used to articulate requirements for the CDA Level One Body. These are expressed
8 in XML using industry-standard constructs. The structural components themselves are not part of RIM
9 0.98. The UML model of the CDA Level One Body included here is presented as a non-normative tool to
10 aid in understanding the XML DTD.
2
non_xml
contains
contains lev elone contains body 1..1 %body_atts;
1..1 1..1
clinical_document_header %body_atts; %body_atts; 0..1
1..1 1..1
contains
0..1
body_atts
1 originator : XML_IDREFS common_atts section 0..*
confidentiality : XML_IDREFS 0..*
xml : lang %body_atts; contains
ID : XML_ID
%common_atts; 0..1
0..1 0..1
contains
0..*
contains
caption
0..1
%body_atts; 0..1
caption_cd : CE structures 0..*
contains
0..1 %body_atts;
0..1
col colgroup
0..* 0..1 0..1
%body_atts; %body_atts;
0..1 0..*
contains
0..* 0..*
contains
0..1
contains contains
item
0..1
1..1 %body_atts;
thead 0..1 tbody
0..1 contains table paragraph
%body_atts; contains %body_atts; contains contains
1..1 0..* 1..*
1..1 0..1
0..1 1..1 contains 0..*
0..1 0..1 0..1
contains contains contains
contains contains
contains
1..1
contains
0..*
0..1 1..* 1..* 0..1 contains
tf oot tr td list
%body_atts; contains %body_atts; contains %body_atts; list_type : (ordered | unordered) = unordered
0..1 1..* 1..1 0..* 0..*
0..1 contains
1..1 0..1
contains
contains link_html
0..* name
0..* th href
link 1 contains
rel
%body_atts; contains 0..*
%body_atts; rev
caption_cd : CE
0..1 1 title
%body_atts;
0..* 0..*
0..1 0..1
0..1 contains
contains content
0..1
coded_entry
0..* contains %body_atts;
0..* %body_atts;
PCDATA 1 id : II
value : CD
0..*
observation_media
0..*
%body _atts; contains 0..1 local_markup
id : II local_attr
entries contains
0..* ignore name : XML_NMTOKEN
v alue : CD
descriptor value : XML_CDATA
render 0..*
0..1 %common_atts;
1 Health Level Seven, © 2000. All rights reserved 96 %body_atts;
2
1 5.3 CDA Implementation Notes
2 The following sections contain background information and explanatory material that can help those
3 implementing the CDA.
4 5.3.1 Tables
5 The following goals apply to information presented in tabular form in CDA Level One:
6
7 1. Meet CDA guidelines for human readability: use common browsers and standard style sheets.
8 2. Ensure that the widest possible group of participants can create documents and then transform them
9 into CDA Level One.
10 3. Allow use of common word processing tools (including RTF, HTML and XML editors) to create
11 tables which can be easily inserted into CDA-compliant documents.
12 4. Allow conversion of tables created in non-CDA XML into CDA Level One.
13
14 Subsequent releases and higher levels of the architecture will observe the same goals and may include a
15 standard for markup of tabular material that meets some or all of the following additional criteria:
16
17 5. Information in tables in higher levels of the architecture should be down-translatable into lower levels
18 with a minimum of semantic loss.
19 6. Import tables from relational and object oriented databases using automated processes with minimal
20 loss of processing semantics.
21 7. Easily encode and insert into a document material received within an HL7 message that is conceptually
22 tabular with minimal loss of processing semantics.
23 8. Automated table manipulation is not guaranteed safe where there are no agreed-upon semantics to
24 guide the processing (for example, tables meeting goals 1-5 only). Revisions may need to be checked
25 for consistent use of the table format.
26 9. Render documents for dynamic display.
27 10. CDA tables can be queried with a relatively simple SQL-like statement. In the future, this requirement
28 will extend to cover the nascent XQL specification.
29 11. Data in CDA tables can be extracted with sufficient granularity to be translated into a database schema.
30 The design of the table model should minimize the complexity of translating into and out of the table
31 model.
32 12. Non-architectural tables: A single table model or set of table models should be used across all CDA
33 documents, irrespective of Level. This requires that the table model(s) have a uniform method of
34 carrying semantic encoding which might be optional at Level One, but required and specified at higher
35 levels.
36 5.3.2 Validation and conformance

37 A CDA Level One document is "valid" if it complies with the constraints expressed in the CDA Level One
38 DTD. (This definition of validity is taken from the W3C XML Recommendation). However validity of a
39 CDA Level One document against the CDA Level One DTD does not mean that all HL7 rules and
40 constraints have been met. It is not possible to represent all the constraints of a Hierarchical Description
41 explicitly in an XML DTD such that a validating XML processor can determine whether or not they were
42 adhered to. A CDA document is in "conformance" if it is valid and if it complies with all HL7 rules and
43 constraints. It is expected that additional application logic, above and beyond that found in a validating
44 XML processor, will be required to determine whether or not a CDA document is in complete conformance
45 with the CDA Level One specification.
46
47 The W3C is actively developing an XML constraint language (known as XML Schemas) that will be more
48 expressive (such that an XML Schema-aware processor can validate a greater set of constraints) than XML
49 DTDs (see 5.4 References). When such a recommendation is issued by the W3C, it will be reviewed with
50 the intent to create an XML Schema for the CDA Level One specification. However it is anticipated that
51 even Schema-valid CDA documents will need additional conformance checking.
2
1 5.3.3 Localization
2 Those implementing structured document systems for healthcare may choose to adopt CDA DTDs directly
3 into their application or environment. Yet applications and implementations commonly have features and
4 requirements that exceed the CDA definitions. The two primary modes of localization are use of locally-
5 defined markup within the CDA (see the discussion of localization in the CDA Header, 3.2.2.6
6 Localization, and in the CDA Level One Body, 3.3.2.4.6 Localization), and use of a local DTD that is
7 transformed to the CDA for the purpose of exchange.
8
9 The implementation of localization within CDA parallels the "version compatibility definition" in HL7
10 V2.3.1 (Chapter 2 Control/Query, section 2.10.2) that enables new fields, segments, and components to be
11 introduced at the tail end of the normative specification. In the process of converting from the Hierarchical
12 Description to the XML DTD, the CDA specification adds a <local_header> element to the end of every
13 XML content model. Likewise, a <local_markup> element is added to the end of every XML content
14 model within the CDA Level One Body.
15 5.3.4 Transformation issues

16 A CDA document may be original markup (meaning that the immediate output of a document authoring
17 application is a CDA document), or may be the result of a mapping or transformation from original markup
18 (where the immediate output of a document authoring application is not a CDA document). It is likely that
19 developers will implement XML DTDs tailored to their own requirements that incorporate the shared CDA
20 markup and extend it with local information.
21
22 Because many institutions have or are actively developing their own internal document markup or
23 metadata, there will be a need to transform documents built against local specifications into documents that
24 conform to CDA specifications for purposes of exchange. SGML and XML transformation languages
25 include Hytime Architectural Forms (ISO/IEC 10744), Document Style Semantics and Specification
26 Language (DSSSL, ISO/IEC 10179:1996), and Extensible Stylesheet Language (XSL)
27 (www.w3.org/Style/XSL/). General programming languages also enable the transformation of markup from
28 one DTD to another.
29
30 Note that transformation of markup does not affect the legally authenticated (or pre-authenticated) content
31 of a document.
32
33 Each transformation language has potential syntactic limitations in the type of mappings that can be
34 formally expressed. Additionally, there are semantic mappings that cannot be resolved regardless of the
35 transformation language employed. While the discussion here focuses on mapping from one DTD to
36 another, the issues are no different than those that arise in the more general sense of mapping from one
37 information model to another. Elements in the source DTD may be in different order then in a CDA DTD
38 (e.g. <dob> <name> vs. <person_name> <person.birth_dttm>). The source DTD may be missing a required
39 element (e.g. CDA DTD requires <clinical_document_header.id>). The source and CDA DTDs may have
40 different enumerated list values (e.g. <sex> male </sex> vs. <person.administrative_gender_cd value=
41 "M"/>). Elements may have different data types (e.g. <dob> January 13, 1923 </dob> vs.
42 <person.birth_dttm value="19230113"/>). The source DTD may be have coarser granularity than the CDA
43 DTD (e.g. <name> Henry Levin, the 7th </name> vs. <person_name> <family_name value="Levin/>
44 <given.name value="Henry"/> <suffix value="the 7th/> </person_name>). The most challenging
45 transformation issues arise when the source's information model of the real world differs from the RIM.
46
47 It is likely to be the case that transformation issues will be minimized to the extent that the CDA
48 specifications and the underlying RIM are unambiguous. The CDA specification for use of local markup in
49 the header (see 3.2.2.6 Localization) and in the body (see 3.3.2.4.6 Localization) can be used when local
50 semantics have no corresponding representation in the CDA specification.
2
1 5.3.5 Representing authenticated content
2 The following describes the responsibility of the CDA for representing authenticated content. This position
3 may be extended with the availability of further standards for digital signature, XML formatting and
4 specific formatting standards for clinical documents.
5
6 Observations:
7  Representation of authenticated content should not be the sole, overriding constraint on the style of
8 XML markup.
9  Different criteria may apply to markup of authenticated content in the CDA Header and in the CDA
10 Level One body. At Level One, the content and markup of the body is relatively unconstrained, while
11 markup of the Header is precise. In addition, at Level One, the semantics of the Header are prescribed
12 and are conveyed by markup, while the semantics of the body are not prescribed and are, by definition,
13 not conveyed by markup.
14  Provider requirements for verifying and reproducing what was signed vary widely.
15  Vendor solutions to provider requirements employ a wide range of technical strategies, all more or less
16 bound to specific applications and platforms.
17  Requirements for reproducing what was authenticated for the courts can and must be de-coupled from
18 requirements for exchanging information within healthcare.
19
20 Presentation for legal purposes:
21  CDA documents are exchange artifacts and as such are not original, authenticated entities. They are
22 transformed copies of original documents bearing markup specific to exchange, not to origination and
23 not to authentication.
24  Representation of authenticated content for the purpose of legal verification of original content is and
25 will remain outside the scope of the CDA.
26  It is expected that originating institutions will establish and maintain their own policies, procedures,
27 and technology for recording and reproducing the signed content of the original.
28
29 Presentation for clinical care, administration, and analysis within healthcare:
30  Representation of original content between providers and analysts for healthcare delivery and
31 processing of medical records is within the scope of the CDA.
32  At present, no standards-compliant, application-independent method of representing the content of
33 XML documents has sufficient market acceptance to be balloted as the canonical stylesheet for basic
34 presentation of CDA documents. 19 Thus, while it is possible to express in simple language the
35 requirements for representing the content of a CDA document for the purpose of communication
36 between clinicians in a manner that does not compromise the format independence of the markup, no
37 equivalent stylesheet mechanism can be specified.
38  CDA Level One is accompanied by a sample XSL style sheet that transforms the CDA to HTML.
39  For more general presentation, a human language (English) guide to the representation of the content
40 of a CDA document can be created as an implementation guide. This would allow recipients to build a
41 stylesheet or sets of stylesheets according to their own requirements.
42  CDA conformance will apply solely to transmitted document instances. It is understood that
43 implementers can build stylesheets for specialized purposes that will suppress or reveal portions of the
44 document and markup according to diverse use cases and business rules. Implementer stylesheets will
45 be non-normative and no compliance or conformance mechanism will be provided.
46
1 19
An argument could be made that CSS does meet these criteria, but only on screen, not in print. XSLT has
2 large market acceptance and is an open standard (W3C Recommendation) but an XSLT “stylesheet” as
3 implemented today always has an application and time-bound target syntax, such as a version/flavor of
4 HTML or rtf, that does not meet our requirements. Full blown XSL, that is, XSLT plus XSL formatting
5 objects, would meet our criteria, but this is not yet a standard and has not yet been implemented. DSSSL
6 does meet all our criteria save market acceptance.
8
1 5.4 References
2
3 Health Level 7 References [www.hl7.org]
4  HL7 Reference Information Model, Version 0.98
5 www.hl7.org/library/data-model/RIM/modelpage_non.htm
6  HL7 Messaging Standard, Version 2.3.1
7  HL7 Version 3 Message Development Framework, 1999.
8  HL7 Version 3 Standard; Data Type Specification, Release 1 (DTD, abstract specification)
9
10 World Wide Web Consortium References [www.w3.org]
11  XML Schema Part 1: Structures. W3C Working Draft 6-May-1999
12 www.w3.org/1999/05/06-xmlschema-1/
13  XML Schema Part 2: Datatypes. World Wide Web Consortium Working Draft 06-May-1999.
14 www.w3.org/1999/05/06-xmlschema-2/
15  XML Linking Language (XLink). World Wide Web Consortium Working Draft 3-March-1998.
16 www.w3.org/TR/1998/WD-xlink-19980303
17  Extensible Markup Language (XML) 1.0. W3C Recommendation 10-February-1998.
18 www.w3.org/TR/1998/REC-xml-19980210.html
19  Extensible Stylesheet Language (XSL)
20 www.w3.org/Style/XSL/
21  XHTML 1.0. A Reformulation of HTML 4 in XML 1.0. W3C Recommendation 26-January-2000.
22 www.w3.org/TR/xhtml1/
23
24 Other Standards that have contributed to the development of the CDA
25  CEN/TC251 ENV 13606, 4 part EHCR message standard.
26  Health Informatics: Interoperability of Healthcare Multimedia Report Systems, CEN TC251 WG IV,
27 Version 1, 1999-05-28.
28  Digital Imaging and Communications in Medicine (DICOM) Supplement 23: Structured Reporting
29 (SR). 29-October-1999.
30  Information processing – Text and office systems – Standard Generalized Markup Language (SGML).
31 ISO 8879:1986. October, 1986.
32  Information processing – Text and office systems – Standard Generalized Markup Language (SGML),
33 Amendment 1. ISO 8879:1986/AMENDMENT 1. July, 1988.
34  Architectural Forms Definition Requirements (AFDR, ISO/IEC 10744).
35  Document Style Semantics and Specification Language (DSSSL, ISO/IEC 10179:1996)
36
37 Other References that have contributed to the development of the CDA
38  Alschuler L. First do no harm. A standard for electronic communication in healthcare. Dudeck J et al
39 (ed.) New Technologies in Hospital Information Systems. Vol. 45 in Studies in Health Technology
40 and Informatics. Amsterdam: IOS Press; 1997.
41  Alschuler L, Beeler G, Boyer S, Lincoln T, Owens F, Rishel W, Spinosa J, Sutor R. XML in
42 healthcare: the HL7 experience. XML '99. Graphic Communications Association.
43  Alschuler L, Brennan S, Rossi Mori A, Sokolowski R, Dudeck J. SGML/XML in healthcare
44 information exchange standards. Proc SGML Europe ‘98. Graphic Communications Association,
45 1998: 425-33.
46  Behlen F, Alschuler L, Bidgood D. The document-oriented approach for PACS and medical records.
47 Proc. SPIE 1999; 3662: 29-36.
48  Behlen F. A DICOM document-oriented approach to PACS infrastructure. J. Digital Imaging 1998;
49 11:3 Suppl. 1, 35-8.
50  Bidgood WD. Documenting the information content of images. AMIA Fall Symposium Supplement
51 1997: 424-8.
2
1  Dolin R, Alschuler L, Behlen F, Biron P, Boyer S, Essin D, Harding L, Lincoln T, Mattison J, Rishel
2 W, Sokolowski R, Spinosa J, Williams J. HL7 Document Patient Record Architecture: an XML
3 document architecture based on a shared information model. Fall AMIA, November 1999.
4  Dolin RH, Rishel W, Biron PV, Spinosa J, Mattison JE. SGML and XML as interchange formats for
5 HL7 messages. JAMIA Fall Symposium Supplement 1998: 720-4.
6  European Committee for Standardization / Technical Committee 251 - Medical Informatics.
7 Investigation of Syntaxes for Existing Interchange Formats to be used in Healthcare. CEN/TC 251.
8 January 1993.
9  Friedman C, Hripcsak G, Shagina L, Liu H. Representing information in patient reports using natural
10 language processing and the Extensible Markup Language. JAMIA 1999;6(1):76-87.
11  Rector AL, Glowinski AJ, Nowlan WA, Rossi-Mori A. Medical-concept models and medical records:
12 An approach based on GALEN and PEN&PAD. JAMIA 1995;2(1):19-35.
13
14
15 5.5 Acknowledgements
16
17 In addition to those listed at the top of this document, the following people and committees have
18 contributed to the development of this architecture:
19
20 Carl Adler, Fred Behlen, Dean Bidgood, Carol Broverman, Hans Buitendijk, Ron Capwell, John Carter,
21 Michal Coleman, Don Connelly, Gary Dickinson, Steve Doubleday, Joachim Dudeck, Dan Essin, Jasen
22 Fici, Al Figler, Leo Fogarty, Gerard Freriks, Lloyd Harding, Richard Harding, Michael Henderson, Juggy
23 Jagannathan, Ed Jones, Eliot Kimber, Tom Lincoln, John Majerus, David Markwell, John Mattison, Bob
24 Moe, Wes Rishel, Angelo Rossi-Mori, Gunther Schadow, Anil Sethi, Anne Shanney, John Spinosa,
25 Michael Toback, Wayne Tracy, Jason Williams.
26
27 We'd also like to point out the need for a close working relationship between various committees in
28 ensuring the harmony of the various work products generated by HL7. In particular, we gratefully
29 acknowledge the contributions and domain expertise of the Medical Records / Information Management
30 Technical Committee and the Orders & Observation Technical Committee.
31
32

CDA Framework - Final

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CDA Framework - Final

Uploaded by

Copyright:

Available Formats

1 Version 3 Standard:

1 Health Level Seven, © 2000. All rights reserved 1

1 Health Level Seven, © 2000. All rights reserved 3

1 Health Level Seven, © 2000. All rights reserved 4

1 Health Level Seven, © 2000. All rights reserved 5

2 1.1 What is the CDA?

22 1.1.1 Key aspects of the CDA

33 1.1.2 Scope of the CDA

8 1.2 Goals and Design Principles

22 1.2.2 Design Principles

39 1.3 Scope of the technical specifications in this document

1 Health Level Seven, © 2000. All rights reserved 7

2 2.1 CDA Document

13 2.2 Document schemas and document type definitions

31 2.3 Document architecture

1 Health Level Seven, © 2000. All rights reserved 8

15 CDA Level One

35 2.4 Security, Confidentiality, and Data Integrity

45 2.5 Relationship of the CDA to HL7 Messaging Standards

17 2.5.2 Sending a CDA document in a V2.x message

1 Health Level Seven, © 2000. All rights reserved 10

7 OBX|1|ED|11492-6^History and Physical^LN||

10 Content-Type: multipart/mixed; boundary="HL7-CDA-boundary"

24 2.5.3 Sending a CDA document in a V3 message

8 Content-Type: multipart/mixed; boundary="HL7-CDA-boundary"

8 3.2 CDA Header

26 3.2.2 Technical details

27 3.2.2.1 Common XML attributes

28 3.2.2.1.1 XML element identification

6 3.2.2.2 Document information

7 3.2.2.2.1 Document identification

19 3.2.2.2.2 Document time stamps

22 3.2.2.2.3 Document confidentiality

31 3.2.2.2.4 Document relationships

32 3.2.2.2.4.1 Relationships between documents

20 3.2.2.2.4.2 Relationship to orders

27 3.2.2.3 Encounter data

8 3.2.2.4 Service actors

14 3.2.2.4.1 People responsible for a clinical document

2 Health Level Seven, © 2000. All rights reserved 18

35 3.2.2.4.3 Intended recipients

4 3.2.2.4.4.1 Originating person

13 3.2.2.4.4.2 Originating organization

26 3.2.2.4.6 Healthcare providers

11 3.2.2.4.7 Other service actors

1 Health Level Seven, © 2000. All rights reserved 21

1 3.2.2.5 Service targets

29 3.2.2.5.2 Originating device

14 3.2.2.5.3 Other service targets

1 Health Level Seven, © 2000. All rights reserved 23

2 <!ELEMENT local_header (#PCDATA | local_header | local_attr)* >

4 ignore (all | markup) "markup"

5 descriptor CDATA #IMPLIED

6 render CDATA #IMPLIED

8 xml:lang NMTOKEN #IMPLIED >

9 <!ELEMENT local_attr EMPTY>

11 name NMTOKEN #REQUIRED

12 value CDATA #REQUIRED

14 xml:lang NMTOKEN #IMPLIED>

1 Health Level Seven, © 2000. All rights reserved 24

1 Health Level Seven, © 2000. All rights reserved 25

1 Health Level Seven, © 2000. All rights reserved 26

1 Health Level Seven, © 2000. All rights reserved 27