Clinical Document Architecture Framework
Total Page：16
File Type：pdf, Size：1020Kb
1 Clinical Document
2 Architecture Framework 3 1 4 Version 1.0 DRAFT 5 August 4, 2000
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 111 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 192 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 283 CDA TECHNICAL SPECIFICATIONS...... 13
29 3.1 INTRODUCTION...... 13 30 3.2 CDA HEADER...... 14 31 3.2.1 Overview...... 14 32 3.2.2 Technical details...... 14 33 3.2.2.1 Common XML attributes...... 14
11 This specification was balloted at Committee level under the name “Patient Record Architecture”. The 2designation “DRAFT” will be removed with addition of any technical corrections after membership ballot. 3Health Level Seven, © 2000. All rights reserved 1 4Membership Ballot August 2000 1 3.2.2.1.1 XML element identification...... 14 2 3.2.2.2 Document information...... 15 3 3.2.2.2.1 Document identification...... 15 4 3.2.2.2.2 Document time stamps...... 15 5 3.2.2.2.3 Document confidentiality...... 16 6 3.2.2.2.4 Document relationships...... 16 7 3.2.2.3 Encounter data...... 17 8 3.2.2.4 Service actors...... 18 9 3.2.2.4.1 People responsible for a clinical document...... 18 10 3.2.2.4.2 Authenticators...... 19 11 3.2.2.4.3 Intended recipients...... 19 12 3.2.2.4.4 Originators...... 20 13 3.2.2.4.5 Transcriptionist...... 20 14 3.2.2.4.6 Healthcare providers...... 20 15 3.2.2.4.7 Other service actors...... 21 16 3.2.2.5 Service targets...... 22 17 3.2.2.5.1 Patient...... 22 18 3.2.2.5.2 Originating device...... 22 19 3.2.2.5.3 Other service targets...... 23 20 3.2.2.6 Localization...... 23 21 3.2.3 Hierarchical Description...... 25 22 3.2.4 XML Document Type Definition...... 32 23 3.3 CDA LEVEL ONE BODY...... 47 24 3.3.1 Overview...... 47 25 3.3.2 Technical details...... 47 26 3.3.2.1 Document body and sections...... 47 27 3.3.2.1.1 Document body...... 47 28 3.3.2.1.2 Document sections...... 48 29 3.3.2.1.3 Non_xml body...... 49 30 3.3.2.2 Shared XML attributes...... 50 31 3.3.2.2.1 XML element identification...... 50 32 3.3.2.2.2 Confidentiality...... 50 33 3.3.2.2.3 Originators...... 50 34 3.3.2.2.4 Language...... 51 35 3.3.2.3 Document Structures...... 51 36 3.3.2.3.1 Paragraphs...... 51 37 3.3.2.3.2 Lists and list items...... 52 38 3.3.2.3.3 Tabular material...... 53 39 3.3.2.4 Document Entries...... 54 40 3.3.2.4.1 Character data...... 54 41 3.3.2.4.2 Content...... 54 42 3.3.2.4.3 Links...... 55 43 3.3.2.4.4 Coded entries...... 56 44 3.3.2.4.5 Observation media...... 59 45 3.3.2.4.6 Localization...... 61 46 3.3.3 XML Document Type Definition...... 62 474 GLOSSARY...... 74
485 APPENDICES (NON-NORMATIVE)...... 76
49 5.1 SAMPLES...... 76 50 5.1.1 Sample document...... 76 51 5.1.2 Sample CDA document ...... 78 52 5.1.3 Sample XSLT stylesheet...... 83 53 5.1.4 HTML rendition of sample CDA document...... 91 54 5.2 CDA LEVEL ONE BODY UML MODEL...... 94 55 5.3 CDA IMPLEMENTATION NOTES...... 96 56 5.3.1 Tables...... 96 57 5.3.2 Validation and conformance...... 96 58 5.3.3 Localization...... 97 1Health Level Seven, © 2000. All rights reserved 2 2Membership Ballot August 2000 1 5.3.4 Transformation issues...... 97 2 5.3.5 Representing authenticated content...... 98 3 5.4 REFERENCES...... 99 4 5.5 ACKNOWLEDGEMENTS...... 100 5 6 7 8
1Health Level Seven, © 2000. All rights reserved 3 2Membership Ballot August 2000 1 Table of Figures 2 3FIGURE 1. ILLUSTRATION OF CDA DOCUMENT HIERARCHY...... 9 4FIGURE 2. EXAMPLE OF A CDA DOCUMENT IN AN MDM (EVENT T02) MESSAGE...... 11 5FIGURE 3. EXAMPLE OF A CDA DOCUMENT IN A VERSION 3 MESSAGE...... 12 6FIGURE 4. XML ID ATTRIBUTE...... 15 7FIGURE 5. XML CONTENT MODEL OF AND
1Health Level Seven, © 2000. All rights reserved 4 2Membership Ballot August 2000 1 Table of Tables 2 3TABLE 1. VOCABULARY DOMAIN FOR
1Health Level Seven, © 2000. All rights reserved 5 2Membership Ballot August 2000 11 Introduction
21.1 What is the CDA? 3The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the 4structure and semantics of "clinical documents"2 for the purpose of exchange. A clinical document contains 5observations 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. 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 20A CDA document is a defined and complete information object that can include text, images, sounds, and 21other multimedia content.
221.1.1 Key aspects of the CDA 23Key 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 (RIM3) and use 27 RIM data types. 28 The complete CDA will include a hierarchical set of document specifications. This hierarchy is 29 referred to as an "architecture". 30 31Many of the standards that have contributed to the development of the CDA are listed in 5.4 References 32and general acknowledgments are given in 5.5 Acknowledgements.
331.1.2 Scope of the CDA 34The scope of the CDA is the standardization of clinical documents for exchange. 35 36The clinical content of CDA documents is defined in the RIM. The CDA does not model clinical content, 37but does standardize the markup of the structure and semantics needed for exchange of clinical documents. 38 39CDA documents can be transmitted in HL7 messages designed to transfer clinical documents. The 40specification for such messages is outside the scope of the CDA, although this standard does specify how to 41package CDA documents within HL7 messages (see 2.5.2 Sending a CDA document in a V2.x message 42and 2.5.3 Sending a CDA document in a V3 message). 43
12 Terms defined in the glossary are cited in double quotes on first mention within this document. Acronyms 2are not quoted but are expanded in the glossary. 33 The Clinical Document Architecture is based on the HL7 Reference Information Model, Version 0.98, 4which reflects agreements made through and including the July 2000 RIM Harmonization meeting. 5Health Level Seven, © 2000. All rights reserved 6 6Membership Ballot August 2000 1The CDA does not specify the creation or management of documents, only their exchange markup. 2Document management is critically interdependent with the CDA specifications, but the specification of 3document management messages is outside the scope of the CDA. (For more on this, see 2.5.1 CDA 4Documents and document management).
51.2 Goals and Design Principles
61.2.1 Goals 7The goals of the CDA are: 81. Give priority to delivery of patient care. 92. Use open standards. 103. Support exchange of human-readable documents between users, including those with different levels 11 of technical sophistication. 124. Promote longevity of all information encoded according to this architecture. 135. Enable a wide range of post-exchange processing applications. 146. Be compatible with a wide range of document creation applications. 157. Promote exchange independent of the underlying transfer or storage mechanism. 168. Prepare the design reasonably quickly. 179. Enable policy-makers to control their own information requirements without extension to this 18 specification.
191.2.2 Design Principles 20A number of design principles follow from consideration of the above goals. 211. This architecture must be compatible with XML and the HL7 RIM. 222. Technical barriers to use of the architecture should be minimized. 233. The architecture specifies the schemas required for exchange. 244. The architecture should impose minimal constraints or requirements on document structure and content 25 required for exchange. 265. The architecture must be scalable to accommodate fine-grained markup such as highly structured text 27 and coded data. 286. Document specifications based on this architecture should accommodate such constraints and 29 requirements as supplied by appropriate professional, commercial, and regulatory agencies. 307. Document specifications for document creation and processing, if intended for exchange, should map 31 to this exchange architecture. 328. CDA documents must be human readable using widely-available and commonly-deployed XML- 33 aware browsers and print drivers and a generic CDA style sheet written in a standard style sheet 34 language
351.3 Scope of the technical specifications in this document 36This document presents the CDA concepts and architecture that comprise the complete CDA framework, 37and presents the technical specifications for the root of the architecture known as "CDA Level One". CDA 38Level One specifies a complete document structure, and as such can stand alone, prior to the completion of 39the specification of the complete architecture.
402 CDA Concepts
412.1 CDA Document 42A CDA document is comprised of a header, referred to as the "CDA Header", and a body, which at CDA 43Level One is referred to as the "CDA Level One Body". The CDA Header identifies and classifies the 44document and provides information on authentication, the encounter, the patient, and the provider. The 45body contains the clinical report. 46
1Health Level Seven, © 2000. All rights reserved 7 2Membership Ballot August 2000 1The CDA Level One Body is comprised of nested containers. There are four types of containers: sections, 2paragraphs, lists, and tables. Containers have contents and optional captions. Contents include plain text, 3links, and multimedia. 4 5Both the header and the body use the data types defined in the HL7 RIM.
62.2 Document schemas and document type definitions 7A "schema" is a specification or set of constraints for a class of documents. A "document type definition" 8(DTD) is one type of schema used for both SGML and XML documents. At this writing, the DTD is the 9only standardized schema for markup languages. The World Wide Web Consortium (W3C) is moving 10toward standardization of "XML Schemas", which represent a more expressive way of specifying the 11constraints for a class of documents. As soon as these are adopted and implemented, the CDA will adopt 12XML Schemas. This specification is expressed using DTDs. 13 14CDA Level One is specified by the CDA Level One DTD. This DTD incorporates the CDA Header DTD, 15which is defined as an XML entity. The CDA Header DTD incorporates the HL7 RIM data type DTD, also 16defined as an XML entity. A CDA Level One document references the CDA Level One DTD. 17 18Terminology note: The term "document type" is ambiguous. In XML, "document type" is typically equated 19with "DTD". In the RIM, "document type" is equated with the type code of a document (such as the code 20for a "Consultation Note" or a "Discharge Summary"). This document uses "DTDs" when referring to 21XML document types and uses "document type codes" when referring to the type code of a document, and 22avoids the phrase "document type".
232.3 Document architecture 24The CDA is envisioned as an extensible and hierarchical set of document specifications that, in aggregate, 25define the semantics and structural constraints necessary for the representation of clinical documents. This 26set of specifications is called an architecture to distinguish it from a specification based on a single 27document schema or a set of document schemas with ambiguous or undefined relationships. 28 29In this architecture, relationships between document specifications are defined by specialization and 30inheritance. Use of an architecture avoids imposition of unacceptably rigid constraints on local document 31implementation and facilitates interoperability. 32 33"Levels" within the architecture represent a quantum set of specializations, to which further constraints can 34be applied: 35 CDA Level One is the root of the hierarchy and is the most general document specification. RIM 36 classes are used in the specification of the document header, while the document body is largely 37 structural, although terms from controlled vocabulary can be applied. 38 "CDA Level Two" will be a specialization of CDA Level One, and will constrain the set of allowable 39 structures and semantics based on document type code. 40 "CDA Level Three" will be a specialization of CDA Level Two that will specify the markup of clinical 41 content to the extent that it can be expressed in the HL7 RIM. 42 43These CDA levels will establish baselines for conformance claims. These baselines standardize document 44encoding at stepwise levels of greater shared meaning. Each level makes possible the computer-processible 45expression of richer shared semantics. Levels are extensible laterally – that is, the markup granularity of all 46schemas within a given level is roughly the same but each schema expresses a different set of constraints. 47 48The CDA Level One DTD permits use of any valid document type code and section code, but there is only 49one CDA Level One DTD for all types of clinical documents, regardless of content. Above Level One, 50there will be distinct XML DTDs for different types of clinical documents. Thus, at Level One, it is 51possible to differentiate a "Consultation Note" from a "Discharge Summary" because the two will have 52distinct document type code values in the document instance. Above Level One, it will be possible to
1Health Level Seven, © 2000. All rights reserved 8 2Membership Ballot August 2000 1specify additional constraints on a document based on whether it is a "Consultation Note" or a "Discharge 2Summary" by creating distinct XML DTDs for each document type code. 3 4An illustration of one possible hierarchy of CDA DTDs is shown here4: 5 6 Figure 1. Illustration of CDA Document Hierarchy 7CDA Level One 8 CDA Level Two 9 Level Two :: Progress Note 10 Level Two :: Cardiology Progress Note 11 Level Two :: Endocrinology Progress Note 12 Level Two :: Diabetes Mellitus Progress Note 13 CDA Level Three 14 Level Three :: Progress Note 15 Level Three :: Cardiology Progress Note 16 Level Three :: Endocrinology Progress Note 17 Level Three :: Diabetes Mellitus Progress Note 18 19Note that the clinical content of CDA documents is invariant across all levels of the architecture. Thus a 20single report can be marked up as a Level One, a Level Two, or a Level Three document and its clinical 21content will not vary. What will vary between the levels are: 22 23 The degree to which clinical content can be machine processible in an exchange context. 24 The degree to which clinical document specifications can impose constraints on content. 25
262.4 Security, Confidentiality, and Data Integrity 27Application systems sending and receiving CDA documents are responsible for meeting all legal 28requirements for document authentication, confidentiality, and retention (see 2.5.1 CDA Documents and 29document management). For communications over public media, cryptographic techniques for 30source/recipient authentication and secure transport of encapsulated documents may be required, and 31should be addressed with commercially available tools outside the scope of this standard. 32 33The CDA does provide confidentiality status information to aid application systems in managing access to 34sensitive data. Confidentiality status may apply to the entire document (see 3.2.2.2.3 Document 35confidentiality) or to specified segments of the document (see 3.3.2.2.2 Confidentiality).
362.5 Relationship of the CDA to HL7 Messaging Standards 37A CDA document is a defined and complete information object that can exist outside of a messaging 38context and/or can be a payload within an HL7 message. Thus, the CDA complements HL7 messaging 39specifications.
402.5.1 CDA Documents and document management 41Clinical documents can be revised, and they can be appended to existing documents. Ideally, an updated 42document would declare itself as obsolete, and would contain an explicit pointer to a more recent version. 43This would lessen the chances of a healthcare provider basing treatment decisions on erroneous or 44incomplete data. 45 46In practice, however, it is impossible to guarantee an explicit forward pointer from an outdated version to 47the newer version. Providers print clinical documents and place copies in their own personal charts.
14 An ontology of clinical document types is under development by a consortium of standards and 2vocabulary organizations. See the draft paper, “Proposal for an Ontology for Exchange of Clinical 3Documents” published July 19, 2000 at http://www.hl7.org/special/dotf/dotf.htm. 4Health Level Seven, © 2000. All rights reserved 9 5Membership Ballot August 2000 1Lawyers and patients request copies of clinical documents. Without a process that tracks the chain of 2custody of clinical documents and all of their copies, there can be no way to guarantee that a clinical 3document being viewed has not been subsequently revised. 4 5To minimize the risk of viewing superseded information, there is a critical interdependence between 6clinical documents and document management systems. If CDA documents are viewed outside the context 7of a document management system, it cannot be known with certainty whether or not the viewed document 8has been revised. HL7 messages that carry CDA documents (such as the MDM messages in HL7 V2.x) 9convey critical contextual information that ensures accurate viewing of clinical data.
102.5.2 Sending a CDA document in a V2.x message 11From the perspective of a V2.x message, a CDA document is a multimedia object, to be exchanged as a 12Multipurpose Internet Mail Extensions (MIME, RFC 2046) package, encoded as an encapsulated data type 13(ED). We name our MIME types per the recommendations in the Internet Draft (draft RFC) XML Media 14Types, (http://www.imc.org/draft-murata-xml). 15 16CDA documents are to be exchanged in the OBX segment, in any message that can exchange documents 17(such as MDM and ORU). Within the OBX segment, the MIME package is encoded as a V2.x 18encapsulated data type. The value of OBX.2 (Field 00570 Value Type) should be set to "ED". 19 20OBX 5 (Field 00573 Observation Value) contains the MIME package, encoded as an encapsulated data 21type. The components of the data type in OBX.5 should be valued as follows: 22 23 Set the value of the 2nd component (type of data) to equal "multipart". 24 25 Set the value of the 3rd component (data subtype) to equal "x-hl7-cda-level-one". 26 27 Set the value of the 4th component (encoding) to equal "A". (Note that a MIME package is not itself 28 Base64-encoded. Rather, entities within the MIME package are Base64-encoded. A MIME package is 29 sent as ASCII text. Therefore, the correct value for the 4th component of the encapsulated data type is 30 "A", not "Base64".) 31 32 Set the value of the 5th component (data) to equal the MIME package itself. Every entity within the 33 MIME package must be Base64-encoded. HL7 delimiters that occur within MIME boundary 34 identifiers must be escaped, using the escaping rules defined in the HL7 V2.3.1 Standard, Chapter 2 35 Control/Query, section 2.9, "Use of escape sequences in text fields". The content type of the first 36 MIME entity is set to "application/x-hl7-cda-level-one+xml", and should contain the CDA document 37 itself. Multimedia objects referenced by the CDA document that need to be transmitted with the CDA 38 document are to be placed in successive entities of the MIME package. 39
1Health Level Seven, © 2000. All rights reserved 10 2Membership Ballot August 2000 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 17 --HL7-CDA-boundary
18 Content-Type: image/JPEG
19 20 ... Base64 image ...
21 22 --HL7-CDA-boundary--
23 |...
242.5.3 Sending a CDA document in a V3 message 25From the perspective of a V3 message, a CDA document is a multimedia object, to be exchanged as a 26MIME package, encoded as an encoded data type (ED). We name our MIME types per the 27recommendations in the Internet Draft (draft RFC) for XML Media Types, (http://www.imc.org/draft- 28murata-xml). 29 30CDAdocuments can be exchanged in any message that can exchange documents. The Service.txt RIM 31attribute contains the MIME package, encoded as an encoded data type. The components of the data type 32should 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. 1Health Level Seven, © 2000. All rights reserved 11 2Membership Ballot August 2000 1 2 Figure 3. Example of a CDA document in a Version 3 message.5
3
4
6
7 MIME-Version: 1.0
8 Content-Type: multipart/mixed; boundary="HL7-CDA-boundary"
9 Content-Transfer-Encoding: Base64
10 --HL7-CDA-boundary
11 Content-Type: application/x-hl7-cda-level-one+xml
12 13 ... Base64-encoded CDA document ...
14 15 --HL7-CDA-boundary
16 Content-Type: image/JPEG
17 18 ... Base64 image ...
19 20 --HL7-CDA-boundary--
21
22
15 Note that the exact representation is contingent on the outcome of the HL7 RIM data type DTD ballot. 2Health Level Seven, © 2000. All rights reserved 12 3Membership Ballot August 2000 13 CDA Technical Specifications
23.1 Introduction 3As noted above, CDA Level One is specified by the CDA Level One DTD. This DTD incorporates the 4CDA Header DTD, which is defined as an XML entity. The CDA Header DTD incorporates the HL7 RIM 5data type DTD, also defined as an XML entity. A CDA Level One document references the CDA Level 6One DTD. 7 8Technically, 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 RIM data type DTD is an XML implementation of the abstract data type specification used by 16 both the CDA and the HL7 Version 3 message specifications.6 17 18The CDA element
16 The RIM abstract data type specification and the XML implementation of those data types are being 2separately balloted by the Control Query Technical Committee, in parallel with this document. The data 3type specification is the work product of an open task force that was charged in Summer 1998 by the 4Control Query Technical Committee to redesign data types for HL7 Version 3. A working document that 5contained the specification has been presented to the Technical Steering Committee in 1999. The data type 6specification has been approved through the RIM harmonization process, and the data types are part of the 7RIM. 87 In the descriptive text of this document, XML element names are surrounded by angle brackets (<>). 98 CNE vocabulary domains are enumerated in the XML DTD such that a CDA document containing a value 10outside the enumerated set is invalid. 11Health Level Seven, © 2000. All rights reserved 13 12Membership Ballot August 2000 1Where a coded CDA component is associated with an externally-defined vocabulary domain, the standard 2specifies the coding strength (CWE vs. CNE), and an example of allowable concepts of that domain (with a 3code, display name, and code system identifier for each concept), as shown in the following example: 4 5 Table 2. Example concepts for
83.2 CDA Header
93.2.1 Overview 10The purpose of the CDA Header is to enable clinical document exchange across and within institutions; 11facilitate clinical document management; and facilitate compilation of an individual patient's clinical 12documents into a lifetime electronic patient record. 13 14There 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 20Document information identifies the document, defines confidentiality status, and describes relationships to 21other documents and orders. Encounter data describes the setting in which the documented encounter 22occurred. Service actors include those who authenticate the document, those intended to receive a copy of 23the document, document originators and transcriptionists, and health care providers who participated in the 24service(s) being documented. Service targets include the patient, other significant participants (such as 25family members), and those devices that may have originated portions of the document.
263.2.2 Technical details
273.2.2.1 Common XML attributes
283.2.2.1.1 XML element identification 29Every XML element within a CDA document has an optional identifier, which must be unique within the 30document. 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
19 This document discusses both XML data types and RIM data types. Unless otherwise qualified, the term 2"data type” refers to RIM data types. 3Health Level Seven, © 2000. All rights reserved 14 4Membership Ballot August 2000 1 Figure 4. XML ID attribute
2
3 ...
4 ID ID #IMPLIED
5 ...>
63.2.2.2 Document information
73.2.2.2.1 Document identification 8Every document has a required, globally-unique instance identifier,
15Every document has a required document type code,
193.2.2.2.2 Document time stamps 20There are many temporal events that come into play when creating and validating a CDA document. Some 21of the relevant times are part of the document information, while other times relate to the encounter, and 22the time during which various service actors and targets played a role. Some temporal events can be 23represented 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
110 We anticipate that document type codes in LOINC will be supplemented by codes conforming to the 2proposed document ontology. See the draft paper, "Proposal for an Ontology for Exchange of Clinical 3Documents" published July 19, 2000 at http://www.hl7.org/special/dotf/dotf.htm. 4Health Level Seven, © 2000. All rights reserved 15 5Membership Ballot August 2000 1XML element name ending in "_tmr" and using the "interval of time" or the "general time specification" 2data type). 3 4The
223.2.2.2.3 Document confidentiality 23The CDA Header indicates document confidentiality status. Implementers may include a single document 24confidentiality status indicator in the header that will apply to the entire document. To assign different 25levels of confidentiality to different portions of the document, implementers can include more than one 26confidentiality status indicator in the header. Portions of the body are associated with one of the codes 27through reference (see 3.3.2.2.2 Confidentiality). Values for confidentiality status should be drawn from the 28ServiceConfidentiality vocabulary domain. 29 30 Table 4. Vocabulary domain for
313.2.2.2.4 Document relationships
323.2.2.2.4.1 Relationships between documents 33The CDA Header enables the explicit representation of the relationships between documents. These 34relationships rely on document identifiers described above (see 3.2.2.2.1 Document identification). An
111 Note that the XML DTD does not express this constraint in such a way that a validating XML processor 2can enforce conformance. 3Health Level Seven, © 2000. All rights reserved 16 4Membership Ballot August 2000 1original report is the first version of a report, and gets a new globally unique
213.2.2.2.4.2 Relationship to orders 22Documents may be generated in response to one or more orders. The
283.2.2.3 Encounter data 29Encounter data include an optional, globally-unique encounter identifier; a required encounter time stamp; 30and an optional encounter location, which includes a globally unique location identifier and an address. 31 32The
112 Note that the XML DTD does not express this constraint in such a way that a validating XML processor 2can enforce conformance. 3Health Level Seven, © 2000. All rights reserved 17 4Membership Ballot August 2000 1location for cardiology clinic one day, and for primary care clinic another day; and cardiology clinic today 2might be held in one physical location, but in another physical location tomorrow.) 3 4Values for
83.2.2.4 Service actors 9All people and materials involved with a CDA document can potentially be associated with the document 10as either service actors (described here) or service targets (described next, see 3.2.2.5 Service targets). 11Service actors include those who authenticate the document, those intended to receive a copy of the 12document, document originators and transcriptionists, and health care providers who participated in the 13service(s) being documented. Service actors are capable of and accountable for their independent decisions.
143.2.2.4.1 People responsible for a clinical document 15Several CDA Header components represent people and organizations that play a role in the document or 16the services documented. While these components can represent different people, it is often the case that 17the same person will be represented as the value for more than one of these components (e.g. the person 18originating a document also authenticates it). In such cases, the person should be included as the value for 19each appropriate component. 20 21The role that a person is playing is specified by the type_cd components (e.g.
113 Where there is only one allowable value for type_cd, it is modeled as a fixed attribute in the XML DTD. 2Health Level Seven, © 2000. All rights reserved 18 3Membership Ballot August 2000 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.
13.2.2.4.2 Authenticators 2The CDA is a standard that specifies the structure of exchanged clinical documents. In the case where a 3local document is transformed into a CDA document for exchange, authentication occurs on the local 4document, and that fact is reflected in the exchanged CDA document. A CDA document can reflect the 5unauthenticated, authenticated, or legally authenticated state. The unauthenticated state exists when no 6authentication information has been recorded (i.e., it is the absence of being either authenticated or legally 7authenticated). 8 9An authenticated document exists when a provider has attested to the accuracy of the document. A 10document can be authenticated by zero or more people. The following table, drawn from the ServiceActor 11vocabulary domain, summarizes allowable values for
353.2.2.4.3 Intended recipients 36Intended recipients are those people to whom a copy of the document is to be sent. The CDA Header can 37specify one or more intended recipients. The following table, drawn from the ServiceActor vocabulary 38domain, summarizes allowable values for
33.2.2.4.4 Originators
43.2.2.4.4.1 Originating person 5CDA documents can be originated (authored) by humans and/or by machines. The
133.2.2.4.4.2 Originating organization 14The CDA Header can specify the organization from which the document originates and that is in charge of 15maintaining the document. The following table, drawn from the ServiceActor vocabulary domain, 16summarizes allowable values for
203.2.2.4.5 Transcriptionist 21The CDA Header can specify a transcriptionist. The
263.2.2.4.6 Healthcare providers 27The CDA Header requires the specification of one or more healthcare providers who participated in the 28service(s) being documented. The
114 Note that the XML DTD does not express this constraint in such a way that a validating XML processor 2can enforce conformance, since both
113.2.2.4.7 Other service actors 12In addition to the specific service actors described above, other people occasionally play a role in certain 13circumstances or with certain types of documents. The CDA Header can specify one or more of these 14people via the
1Health Level Seven, © 2000. All rights reserved 21 2Membership Ballot August 2000 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.
13.2.2.5 Service targets 2Service targets are physical entities, including living subjects and inanimate material, that are typically the 3object of services being documented. Service targets include the patient, other significant participants (such 4as family members), and those devices that may have originated portions of the document.
53.2.2.5.1 Patient 6The CDA Header requires one and only one value for
293.2.2.5.2 Originating device 30CDA documents can be originated (authored) by humans and/or by machines. The
143.2.2.5.3 Other service targets 15In addition to the specific service targets described above, other people occasionally may play a role in 16certain circumstances or with certain types of documents. The CDA Header can specify one or more of 17these people via the
223.2.2.6 Localization 23Locally-defined markup must be used when local semantics have no corresponding representation in the 24CDA specification. CDA seeks to standardize the highest level of shared meaning while providing a clean 25and standard mechanism for tagging meaning that is not shared. This is achieved with the CDA 26
1Health Level Seven, © 2000. All rights reserved 23 2Membership Ballot August 2000 1 Figure 5. XML content model of
2
3
4 ignore (all | markup) "markup"
5 descriptor CDATA #IMPLIED
6 render CDATA #IMPLIED
7 ID ID #IMPLIED
8 xml:lang NMTOKEN #IMPLIED >
9
10 11 name NMTOKEN #REQUIRED 12 value CDATA #REQUIRED 13 ID ID #IMPLIED 14 xml:lang NMTOKEN #IMPLIED> 15 1Health Level Seven, © 2000. All rights reserved 24 2Membership Ballot August 2000 13.2.3 Hierarchical Description 2See 1999 HL7 Message Development Framework for detailed description of this table structure. 3 4 Figure 6. 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 6. attr activity_ document_ activity_ service_tmr clinical_document D GTS 0..1 M 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 1Health Level Seven, © 2000. All rights reserved 25 2Membership Ballot August 2000 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) 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 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. attrib id patient_ id id patient_encounter D II 0..1 M encounter 22. attrib practice_ patient_ practice_ practice_ patient_encounter D CE 0..1 PracticeSetting CWE setting_ encounter setting_ setting_ cd cd cd 23. attrib 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 actor 28. attr type_cd service_ type_cd authenticator. authenticator D CS 1..1 ServiceActor CNE M VRF C4 actor type_cd 29. attr tmr service_ tmr participation_ authenticator D IVL_TS 1..1 M actor tmr 1Health Level Seven, © 2000. All rights reserved 26 2Membership Ballot August 2000 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) 30. attr signature_cd service_ signature_cd signature_cd authenticator D CS 1..1 ServiceActorSig CNE M S actor nature 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 1Health Level Seven, © 2000. All rights reserved 27 2Membership Ballot August 2000 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) actor type_cd 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 type_cd 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 1Health Level Seven, © 2000. All rights reserved 28 2Membership Ballot August 2000 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) actor 67. attr type_cd service_ type_cd service_actor. service_actor D CE 1..1 ServiceActor CWE actor type_cd 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 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 service service_ _header actor target 72. attr type_cd service_ type_cd patient.type_cd patient D CS 1..1 ServiceTargetTy CNE M PATS C12 target pe BJ 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 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 1Health Level Seven, © 2000. All rights reserved 29 2Membership Ballot August 2000 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) 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 1Health Level Seven, © 2000. All rights reserved 30 2Membership Ballot August 2000 1C14 :: The ServiceTargetType vocabulary domain is constrained to only include: "ODV". (See also 3.2.2.5.2 Originating device.) 2 3 4Abbreviations used in Hierarchical Description 5 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. 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. 1Health Level Seven, © 2000. All rights reserved 31 2Membership Ballot August 2000 13.2.4 XML Document Type Definition 2 17 18 19 29 30 33%HL7V3.0-datatypes; 34 35 43 44 47 48 1Health Level Seven, © 2000. All rights reserved 32 2Membership Ballot August 2000 1 2 26 31 32 49 50 3 4 12 13 14 18 19 20 24 25 26 30 31 32 36 37 45 46 47 51 52 53 57 1Health Level Seven, © 2000. All rights reserved 34 2Membership Ballot August 2000 1 2 6 7 15 16 17 21 22 31 32 36 40 41 42 52 53 1Health Level Seven, © 2000. All rights reserved 35 2Membership Ballot August 2000 1 5 6 10 14 15 16 26 27 30 34 35 49 50 56 3 4 5 9 10 11 15 16 20 24 25 26 30 31 43 44 53 54 3 7 8 13 17 18 19 23 24 25 29 30 31 35 36 37 41 42 51 52 1Health Level Seven, © 2000. All rights reserved 38 2Membership Ballot August 2000 1 5 6 7 17 18 19 23 24 25 35 36 42 46 47 48 1Health Level Seven, © 2000. All rights reserved 39 2Membership Ballot August 2000 1 2 10 11 15 19 20 21 31 32 41 42 47 51 52 53 6 7 11 15 16 17 27 28 33 37 38 39 43 44 52 53 1Health Level Seven, © 2000. All rights reserved 41 2Membership Ballot August 2000 1 5 6 7 17 18 26 27 33 37 38 39 49 50 51 55 56 7 8 14 18 19 20 24 25 36 37 46 47 55 2 3 4 14 15 19 23 24 27 31 32 33 37 38 39 43 44 53 54 2 6 7 8 18 19 23 27 28 33 37 38 39 43 44 45 49 50 1Health Level Seven, © 2000. All rights reserved 45 2Membership Ballot August 2000 1 2 7 11 12 13 17 18 43 44 45 51 52 53 1Health Level Seven, © 2000. All rights reserved 46 2Membership Ballot August 2000 13.3 CDA Level One Body 23.3.1 Overview 3The CDA element 213.3.2 Technical details 223.3.2.1 Document body and sections 233.3.2.1.1 Document body 24The CDA 34 35 36 ID ID #IMPLIED 37 confidentiality IDREFS #IMPLIED 38 originator IDREFS #IMPLIED 39 xml:lang NMTOKEN #IMPLIED > 403.3.2.1.2 Document sections 41The CDA 1Health Level Seven, © 2000. All rights reserved 47 2Membership Ballot August 2000 1followed by nested 10 12 13 ID ID #IMPLIED 14 confidentiality IDREFS #IMPLIED 15 originator IDREFS #IMPLIED 16 xml:lang NMTOKEN #IMPLIED> 173.3.2.1.2.1 Captions 18The CDA 116 Note that the XML DTD does not express this constraint in such a way that a validating XML processor 2can enforce conformance. 3Health Level Seven, © 2000. All rights reserved 48 4Membership Ballot August 2000 1 Figure 9. XML content model of 2 3 4 ID ID #IMPLIED 5 confidentiality IDREFS #IMPLIED 6 originator IDREFS #IMPLIED 7 xml:lang NMTOKEN #IMPLIED> 8 9 10 %CE-attrib.list; 11 ID ID #IMPLIED 12 confidentiality IDREFS #IMPLIED 13 originator IDREFS #IMPLIED 14 xml:lang NMTOKEN #IMPLIED> 153.3.2.1.3 Non_xml body 16The CDA 27 28 29 %ED-attrib.list; 30 ID ID #IMPLIED 31 confidentiality IDREFS #IMPLIED 32 originator IDREFS #IMPLIED 33 xml:lang NMTOKEN #IMPLIED> 343.3.2.2 Shared XML attributes 35Elements in the CDA Level One Body share a set of XML attributes. Some of these attributes are declared 36in the CDA Header DTD and used in the document body, while other attributes are declared in the CDA 37Level One DTD for use specifically in the document body. 383.3.2.2.1 XML element identification 1Health Level Seven, © 2000. All rights reserved 49 2Membership Ballot August 2000 1Every XML element within a CDA document has an optional identifier, which must be unique within the 2document. (See 3.2.2.1.1 XML element identification). 33.3.2.2.2 Confidentiality 4The confidentiality attribute can occur on any element within the CDA body. The CDA Header contains an 5optionally repeating element 12 13 ... 14 confidentiality IDREFS #IMPLIED 15 ...> 163.3.2.2.3 Originators 17The originator attribute can occur on any element within the CDA body. The CDA Header contains 18optionally repeating elements 25 26 ... 27 originator IDREFS #IMPLIED 28 ...> 293.3.2.2.4 Language 30The human language of character data can be specified using the xml:lang attribute as defined in the XML 311.0 Recommendation: 32 33 "A special attribute named xml:lang may be inserted in documents to specify the language used in 34 the contents and attribute values of any element in an XML document. In valid documents, this 35 attribute, like any other, must be declared if it is used. The values of the attribute are language 36 identifiers as defined by the IETF (Internet Engineering Task Force) RFC 1766: Tags for the 37 Identification of Languages, ed. H. Alvestrand. 1995." 38 39The value of the xml:lang attribute is inherited by nested content, unless overridden. 40 1Health Level Seven, © 2000. All rights reserved 50 2Membership Ballot August 2000 1 Figure 13. XML xml:lang attribute 2 3 ... 4 xml:lang NMTOKEN #IMPLIED 5 ...> 6 73.3.2.3 Document Structures 83.3.2.3.1 Paragraphs 9The CDA 19 20 21 ID ID #IMPLIED 22 confidentiality IDREFS #IMPLIED 23 originator IDREFS #IMPLIED 24 xml:lang NMTOKEN #IMPLIED > 253.3.2.3.2 Lists and list items 26The CDA 2 3 4 list_type (ordered | unordered) "unordered" 5 ID ID #IMPLIED 6 confidentiality IDREFS #IMPLIED 7 originator IDREFS #IMPLIED 8 xml:lang NMTOKEN #IMPLIED > 9 10 11 ID ID #IMPLIED 12 confidentiality IDREFS #IMPLIED 13 originator IDREFS #IMPLIED 14 xml:lang NMTOKEN #IMPLIED > 153.3.2.3.3 Tabular material 16In CDA Level One, any information can be presented as a table. The table markup is for presentation 17purposes only and, unlike a database table, does not possess meaningful field names. The CDA 1Health Level Seven, © 2000. All rights reserved 52 2Membership Ballot August 2000 1 Figure 16. Changes to the strict XHTML table model in CDA 2 Change this: 3 4 To this: 5 6 7 Change these XML attributes: 8 %attrs; 9 To these: 10 ID ID #IMPLIED 11 confidentiality IDREFS #IMPLIED 12 originator IDREFS #IMPLIED 13 xml:lang NMTOKEN #IMPLIED 14 15 Change this: 16 17 to this: 18 20 21 change this: 22 23 to this: 24 253.3.2.4 Document Entries 263.3.2.4.1 Character data 27CDA character data (i.e., XML #PCDATA) occurs in 293.3.2.4.2 Content 30CDA 1Health Level Seven, © 2000. All rights reserved 53 2Membership Ballot August 2000 1Each 7 9 10 ID ID #IMPLIED 11 confidentiality IDREFS #IMPLIED 12 originator IDREFS #IMPLIED 13 xml:lang NMTOKEN #IMPLIED > 143.3.2.4.3 Links 15The CDA is a generic referencing mechanism and occurs within 1Health Level Seven, © 2000. All rights reserved 54 2Membership Ballot August 2000 1 Figure 18. XML content model of and 2 3 4 ID ID #IMPLIED 5 confidentiality IDREFS #IMPLIED 6 originator IDREFS #IMPLIED 7 xml:lang NMTOKEN #IMPLIED > 8 9 10 name CDATA #IMPLIED 11 href CDATA #IMPLIED 12 rel CDATA #IMPLIED 13 rev CDATA #IMPLIED 14 title CDATA #IMPLIED 15 ID ID #IMPLIED 16 confidentiality IDREFS #IMPLIED 17 originator IDREFS #IMPLIED 18 xml:lang NMTOKEN #IMPLIED> 193.3.2.4.4 Coded entries 20The CDA element 3 5 6 ID ID #IMPLIED 7 confidentiality IDREFS #IMPLIED 8 originator IDREFS #IMPLIED 9 xml:lang NMTOKEN #IMPLIED > 10 11 12 %II-attrib.list; 13 ID ID #IMPLIED > 14 15 16 %CD-attrib.list; 17 ID ID #IMPLIED > 18 19The 1Health Level Seven, © 2000. All rights reserved 56 2Membership Ballot August 2000 1 Figure 20. Referencing original text with 2 In the first case, 4 5 Asthma, with prior smoking history. Difficulty weaning off 6 steroids. Will try gradual taper. 7 8 10 11 12 13 In the second case, 15 16 19 20 22 23 24 25 117 Note that the exact mechanism and representation of intra-document referencing is contingent on the 2outcome of the HL7 RIM data type DTD ballot. 3Health Level Seven, © 2000. All rights reserved 57 4Membership Ballot August 2000 13.3.2.4.5 Observation media 2The 1Health Level Seven, © 2000. All rights reserved 58 2Membership Ballot August 2000 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 22. XML content model of 4 5 6 ID ID #IMPLIED 7 confidentiality IDREFS #IMPLIED 8 originator IDREFS #IMPLIED 9 xml:lang NMTOKEN #IMPLIED > 10 11 12 %II-attrib.list; 13 ID ID #IMPLIED > 14 15 16 %ED-attrib.list; 17 ID ID #IMPLIED > 18 1Health Level Seven, © 2000. All rights reserved 59 2Membership Ballot August 2000 13.3.2.4.6 Localization 2The implementation of localization in the CDA Level One Body using the 21 23 24 ignore (all | markup) "markup" 25 descriptor CDATA #IMPLIED 26 render CDATA #IMPLIED 27 ID ID #IMPLIED 28 confidentiality IDREFS #IMPLIED 29 originator IDREFS #IMPLIED 30 xml:lang NMTOKEN #IMPLIED > 31 32 33 name NMTOKEN #REQUIRED 34 value CDATA #REQUIRED 35 ID ID #IMPLIED 36 xml:lang NMTOKEN #IMPLIED> 37 1Health Level Seven, © 2000. All rights reserved 60 2Membership Ballot August 2000 13.3.3 XML Document Type Definition 2 15 16 17 25 26 29%CDA-Header-1.0; 30 31 32 9 10 15 16 18 19 20 21 22 41 42 43 47 48 49 16 17 18 22 23 24 28 29 30 36 37 38 47 48 7 8 9 13 14 15 42 43 44 48 49 50 2 3 4 20 21 23 26 27 28 31 32 33 36 37 2 3 5 10 11 12 16 17 18 22 23 24 42 43 44 51 52 53 5 6 16 17 18 22 23 24 41 42 43 48 49 50 54 55 56 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 1Health Level Seven, © 2000. All rights reserved 68 2Membership Ballot August 2000 1 2 3 4 5 6 8 9 10 11 19 20 21 27 28 29 30 35 40 41 42 45 46 48 49 50 51 52 53 54 55 56 57 1Health Level Seven, © 2000. All rights reserved 69 2Membership Ballot August 2000 1 2 13 14 18 19 24 25 29 37 38 50 1Health Level Seven, © 2000. All rights reserved 70 2Membership Ballot August 2000 1 2 14 20 21 27 28 34 35 41 42 43 44 45 46 47 2 3 15 1Health Level Seven, © 2000. All rights reserved 72 2Membership Ballot August 2000 14 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 Extentions 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 1Health Level Seven, © 2000. All rights reserved 74 2Membership Ballot August 2000 15 Appendices (non-normative) 2The appendices contain non-normative material supplied as aids to understanding and implementing the 3technical specifications described above. 4 5Appendix 5.1 "Samples" presents a sample document, both as it might appear in a typical word-processor, 6and how it would appear when represented as a CDA Level One document instance. We present an XSLT 7style sheet that transforms the CDA document instance into the included HTML instance. 8 9Appendix 5.2 "CDA Level One Body UML model" provides a UML model that is a very literal expression 10of the CDA Level One Body portion of the CDA Level One DTD. We note however that the 11expressiveness of UML and DTD differs, so that certain constraints expressed within the DTD (such as the 12ordering of elements within a content model) are not explicitly represented in the UML model. 13 14Appendix 5.3 "CDA Implementation Notes" contains additional material of value to implementers. Section 155.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 17section 5.3.4 "Transformation issues" describe considerations that arise when mapping from a local 18implementation into CDA. Section 5.3.5 "Representing authenticated content" discusses the markup of 19legally authenticated content within CDA documents. 20 21Appendix 5.4 "References" enumerates those HL7 specifications, W3C specifications, and other Standards 22and literature that have contributed to the development of the CDA. 23 24Last, but certainly not least, appendix 5.5 "Acknowledgements" recognizes the many contributors to this 25specification. The collaborative spirit and the enormous personal contributions made by these individuals 26are greatly appreciated. 275.1 Samples 285.1.1 Sample document 29 30Good Health Clinic Consultation note 31 32Consultant: Robert Dolin, MD 33Date: April 7, 2000 34Patient: Henry Levin, the 7th MRN: 12345 Sex: Male 35Birthdate: September 24, 1932 36 37History of Present Illness 38Henry Levin, the 7th is a 67 year old male referred for further asthma management. Onset of asthma in his 39teens. He was hospitalized twice last year, and already twice this year. He has not been able to be weaned 40off steroids for the past several months. 41 42Past Medical History 43 Asthma 44 Hypertension 45 Osteoarthritis, right knee 46 47Medications 48 Theodur 200mg BID 49 Proventil inhaler 2puffs QID PRN 50 Prednisone 20mg qd 1Health Level Seven, © 2000. All rights reserved 75 2Membership Ballot August 2000 1 HCTZ 25mg qd 2 3Allergies 4 Penicillin - Hives 5 Aspirin - Wheezing 6 7Social History 8 Smoking :: 1 PPD between the ages of 20 and 55, and then he quit. 9 Alcohol :: Rare 10 11Physical Exam 12 Vital Signs :: BP 118/78; Wt 185lb; Resp 16 and unlabored; T 98.6F; HR 86 and regular. 13 Skin :: Erythematous rash, palmar surface, left index finger. 14 15 Lungs :: Clear with no wheeze. Good air flow. 16 Cardiac :: RRR with no murmur, no S3, no S4. 17 18Labs 19 CXR 02/03/1999: Hyperinflated. Normal cardiac silhouette, clear lungs. 20 Peak Flow today: 260 l/m. 21 22Assessment 23 Asthma, with prior smoking history. Difficulty weaning off steroids. Will try gradual taper. 24 Hypertension, well-controlled. 25 Contact dermatitis on finger. 26 27Plan 28 Complete PFTs with lung volumes. 29 Chem-7 30 Provide educational material on inhaler usage and peak flow self-monitoring. 31 Decrease prednisone to 20qOD alternating with 18qOD. 32 Hydrocortisone cream to finger BID. 33 RTC 1 week. 34 35Signed by: Robert Dolin, MD April 8, 2000 36 1Health Level Seven, © 2000. All rights reserved 76 2Membership Ballot August 2000 15.1.2 Sample CDA document 18 2 3 4 118 Note that the exact representation is contingent on the outcome of the HL7 RIM data type DTD ballot. 219 The official HL7 OID for this vocabulary domain has not yet been assigned. This value will be updated 3as a technical correction when available. 420 The official HL7 OID for this vocabulary domain has not yet been assigned. This value will be updated 5as a technical correction when available. 621 The official HL7 OID for this vocabulary domain has not yet been assigned. This value will be updated 7as a technical correction when available. 822 The official HL7 OID for this vocabulary domain has not yet been assigned. This value will be updated 9as a technical correction when available. 10Health Level Seven, © 2000. All rights reserved 77 11Membership Ballot August 2000 1 123 The official HL7 OID for this vocabulary domain has not yet been assigned. This value will be updated 2as a technical correction when available. 324 The official HL7 OID for this vocabulary domain has not yet been assigned. This value will be updated 4as a technical correction when available. 525 The official HL7 OID for this vocabulary domain has not yet been assigned. This value will be updated 6as a technical correction when available. 7Health Level Seven, © 2000. All rights reserved 78 8Membership Ballot August 2000 1 126 The official HL7 OID for this vocabulary domain has not yet been assigned. This value will be updated 2as a technical correction when available. 327 The official HL7 OID for this vocabulary domain has not yet been assigned. This value will be updated 4as a technical correction when available. 5Health Level Seven, © 2000. All rights reserved 79 6Membership Ballot August 2000 1 1Health Level Seven, © 2000. All rights reserved 81 2Membership Ballot August 2000 15.1.3 Sample XSLT stylesheet 2Created according to W3C XSL Transformations Version 1.0, http://www.w3.org/TR/1999/REC-xslt- 319991116. 4 5 6 7 10 ]> 11 20select='/levelone/clinical_document_header/originating_organization/organization/organiza 21tion.nm/@V'/> 23 6 1Health Level Seven, © 2000. All rights reserved 89 2Membership Ballot August 2000 15.1.4 HTML rendition of sample CDA document 2 3 4 58 Henry Levin, the 7th is a 67 year old male referred for further 59 asthma management. Onset of asthma in his teens. He was hospitalized 60 twice last year, and already twice this year. He has not been able to 61 be weaned off steroids for the past several months. 62 1Health Level Seven, © 2000. All rights reserved 92 2Membership Ballot August 2000 15.2 CDA Level One Body UML model 2This section provides a UML model that is a very literal expression of the CDA Level One Body portion of 3the CDA Level One DTD. We note however that the expressiveness of UML and DTD differs, so that 4certain constraints expressed within the DTD (such as the ordering of elements within a content model) are 5not explicitly represented in the UML model. 6 7Document analysis was used to articulate requirements for the CDA Level One Body. These are expressed 8in XML using industry-standard constructs. The structural components themselves are not part of RIM 90.98. The UML model of the CDA Level One Body included here is presented as a non-normative tool to 10aid in understanding the XML DTD. 1Health Level Seven, © 2000. All rights reserved 93 2Membership Ballot August 2000 non_xml contains levelone contains body 1..1 %common_atts; clinical_document_header 1..1 contains 1..1 %common_atts; %common_atts; %body_atts; %body_atts; %body_atts; 0..1 1..1 1..1 contains 0..1 body_atts 1 section 0..* originator : XML_IDREFS common_atts 0..* %common_atts; confidentiality : XML_IDREFS ID : XML_ID %body_atts; contains xml:lang : XML_NMTOKEN 0..1 0..1 0..1 contains 0..* contains caption 0..1 %common_atts; %body_atts; 0..1 structures 0..* caption_cd : CE contains 0..1 %common_atts; 0..1 %body_atts; col colgroup 0..1 %common_atts; 0..* %common_atts; 0..1 %body_atts; %body_atts; 0..1 0..* contains 0..* 0..* contains 0..1 contains item contains 0..1 1..1 %common_atts; %body_atts; thead 0..1 table tbody paragraph %common_atts; 0..1 %common_atts; contains contains contains %body_atts; 1..1 %body_atts; 1..* contains 1..1 0..* contains 0..1 0..1 1..1 0..* 0..1 0..1 0..1 contains contains contains contains contains contains 1..1 0..* contains 0..1 1..* 1..* 0..1 contains tfoot tr td list %common_atts; %common_atts; %common_atts; contains contains list_type : (ordered | unordered) = unordered %body_atts; 0..1 1..* %body_atts; %body_atts; 1..1 0..* 0..1 contains 0..* 0..1 1..1 contains contains link_html 0..* name 0..* th link contains href %common_atts 1 rel 0..* %common_atts; %body_atts; contains rev %body_atts; caption_cd : CE 0..1 1 title %common_atts; %body_atts; 0..* 0..1 0..1 0..* 0..1 contains contains content 0..1 0..* %common_atts; coded_entry 0..* contains %body_atts; PCDATA %common_atts; 1 %body_atts; id : II value : CD 0..* observation_media 0..* %common_atts; 0..1 contains %body_atts; entries local_markup id : II local_attr 0..* ignore contains value : CD name : XML_NMTOKEN descriptor value : XML_CDATA render %common_atts; %common_atts; 0..1 0..* 1Health Level Seven, © 2000. All rights reserved 94 %body_atts; 2Membership Ballot August 2000 15.3 CDA Implementation Notes 2The following sections contain background information and explanatory material that can help those 3implementing the CDA. 45.3.1 Tables 5The following goals apply to information presented in tabular form in CDA Level One: 6 71. Meet CDA guidelines for human readability: use common browsers and standard style sheets. 82. Ensure that the widest possible group of participants can create documents and then transform them 9 into CDA Level One. 103. 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. 124. Allow conversion of tables created in non-CDA XML into CDA Level One. 13 14Subsequent releases and higher levels of the architecture will observe the same goals and may include a 15standard for markup of tabular material that meets some or all of the following additional criteria: 16 175. Information in tables in higher levels of the architecture should be down-translatable into lower levels 18 with a minimum of semantic loss. 196. Import tables from relational and object oriented databases using automated processes with minimal 20 loss of processing semantics. 217. Easily encode and insert into a document material received within an HL7 message that is conceptually 22 tabular with minimal loss of processing semantics. 238. 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. 269. Render documents for dynamic display. 2710. 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. 2911. 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. 3212. 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. 365.3.2 Validation and conformance 37A CDA Level One document is "valid" if it complies with the constraints expressed in the CDA Level One 38DTD. (This definition of validity is taken from the W3C XML Recommendation). However validity of a 39CDA Level One document against the CDA Level One DTD does not mean that all HL7 rules and 40constraints have been met. It is not possible to represent all the constraints of a Hierarchical Description 41explicitly in an XML DTD such that a validating XML processor can determine whether or not they were 42adhered to. A CDA document is in "conformance" if it is valid and if it complies with all HL7 rules and 43constraints. It is expected that additional application logic, above and beyond that found in a validating 44XML processor, will be required to determine whether or not a CDA document is in complete conformance 45with the CDA Level One specification. 46 47The W3C is actively developing an XML constraint language (known as XML Schemas) that will be more 48expressive (such that an XML Schema-aware processor can validate a greater set of constraints) than XML 49DTDs (see 5.4 References). When such a recommendation is issued by the W3C, it will be reviewed with 50the intent to create an XML Schema for the CDA Level One specification. However it is anticipated that 51even Schema-valid CDA documents will need additional conformance checking. 1Health Level Seven, © 2000. All rights reserved 95 2Membership Ballot August 2000 15.3.3 Localization 2Those implementing structured document systems for healthcare may choose to adopt CDA DTDs directly 3into their application or environment. Yet applications and implementations commonly have features and 4requirements that exceed the CDA definitions. The two primary modes of localization are use of locally- 5defined markup within the CDA (see the discussion of localization in the CDA Header, 3.2.2.6 6Localization, and in the CDA Level One Body, 3.3.2.4.6 Localization), and use of a local DTD that is 7transformed to the CDA for the purpose of exchange. 8 9The implementation of localization within CDA parallels the "version compatibility definition" in HL7 10V2.3.1 (Chapter 2 Control/Query, section 2.10.2) that enables new fields, segments, and components to be 11introduced at the tail end of the normative specification. In the process of converting from the Hierarchical 12Description to the XML DTD, the CDA specification adds a 155.3.4 Transformation issues 16A CDA document may be original markup (meaning that the immediate output of a document authoring 17application 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 19developers will implement XML DTDs tailored to their own requirements that incorporate the shared CDA 20markup and extend it with local information. 21 22Because many institutions have or are actively developing their own internal document markup or 23metadata, there will be a need to transform documents built against local specifications into documents that 24conform to CDA specifications for purposes of exchange. SGML and XML transformation languages 25include Hytime Architectural Forms (ISO/IEC 10744), Document Style Semantics and Specification 26Language (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 28one DTD to another. 29 30Note that transformation of markup does not affect the legally authenticated (or pre-authenticated) content 31of a document. 32 33Each transformation language has potential syntactic limitations in the type of mappings that can be 34formally expressed. Additionally, there are semantic mappings that cannot be resolved regardless of the 35transformation language employed. While the discussion here focuses on mapping from one DTD to 36another, the issues are no different than those that arise in the more general sense of mapping from one 37information model to another. Elements in the source DTD may be in different order then in a CDA DTD 38(e.g.
, and
elements. These structures contain CDA 9"entries", which include the
,
element. A
). A can occur in a
). A has an optional
is ordered or unordered (with unordered being the default). Use an ordered list when the 29ordering of list items is meaningful. 30 31Each
has an optional local identifier (see 3.3.2.2.1 XML element identification), an optional set of 32confidentiality status flags (see 3.3.2.2.2 Confidentiality), and an optional set of originators (see 3.3.2.2.3 33Originators). The human language of contained character data can be specified using the xml:lang attribute 34(see 3.3.2.2.4 Language). 35 36The CDA
. An
and
can 18occur in a
has an optional
element is modeled analogously to the and ). ), ), or ). A 27 ), or ), and can be nested in 35
39 45
50 54
57 61
13
18 53
60 66
8 14
27
62
64 23 24
28 33 35 36 38Date: 42 43 47 51 56 57 64 68 70 71 1Health Level Seven, © 2000. All rights reserved 83 2Membership Ballot August 2000 1 3Birthdate: 7 8 12Patient: 16 17 21 22 24 25 27 Sex: 28 29 34 59
67 16
26
6
27 29 30
50 31 34Consultant: Robert 32Dolin, MD 33 35 38Date: April 7, 362000 37 39 44Patient: Henry Levin, 40the 7th MRN: 12345 Sex: Male 43 45 48 49Birthdate: September 4624, 1932 47
52 67
2 8
13 17
20 24
29 35
40 41
52
47 48 49 50 53
61 62
68 3
8 14
22 28
37