Clinical Document Architecture Framework

1 Clinical Document2 Architecture Framework 3 1 4 Version 1.0 DRAFT 5 August 4, 20006 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...... 612 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...... 720 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...... 1329 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...... 1411 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...... 74485 APPENDICES (NON-NORMATIVE)...... 7649 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 81Health 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 <LOCAL_HEADER>...... 24 8FIGURE 6. HIERARCHICAL DESCRIPTION OF CDA HEADER...... 25 9FIGURE 7. XML CONTENT MODEL OF <BODY>...... 48 10FIGURE 8. XML CONTENT MODEL OF <SECTION>...... 48 11FIGURE 9. XML CONTENT MODEL OF <CAPTION>...... 49 12FIGURE 10. XML CONTENT MODEL OF <NON_XML>...... 50 13FIGURE 11. XML CONFIDENTIALITY ATTRIBUTE...... 50 14FIGURE 12. XML ORIGINATOR ATTRIBUTE...... 51 15FIGURE 13. XML XML:LANG ATTRIBUTE...... 51 16FIGURE 14. XML CONTENT MODEL OF <PARAGRAPH>...... 52 17FIGURE 15. XML CONTENT MODEL OF <LIST> AND <ITEM>...... 53 18FIGURE 16. CHANGES TO THE STRICT XHTML TABLE MODEL IN CDA...... 54 19FIGURE 17. XML CONTENT MODEL OF <CONTENT>...... 55 20FIGURE 18. XML CONTENT MODEL OF <LINK> AND <LINK_HTML>...... 56 21FIGURE 19. XML CONTENT MODEL OF <CODED_ENTRY>...... 57 22FIGURE 20. REFERENCING ORIGINAL TEXT WITH <CODED_ENTRY>...... 58 23FIGURE 21. HIERARCHICAL DESCRIPTION OF <OBSERVATION_MEDIA>...... 59 24FIGURE 22. XML CONTENT MODEL OF <OBSERVATION_MEDIA>...... 60 25FIGURE 23. XML CONTENT MODEL OF <LOCAL_MARKUP>...... 61 26 271Health Level Seven, © 2000. All rights reserved 4 2Membership Ballot August 2000 1 Table of Tables 2 3TABLE 1. VOCABULARY DOMAIN FOR <EXAMPLE_CODED_CDA_COMPONENT> (CWE)...... 13 4TABLE 2. EXAMPLE CONCEPTS FOR <EXAMPLE_CODED_CDA_COMPONENT> (CWE)...... 14 5TABLE 3. EXAMPLE CONCEPTS FOR <DOCUMENT_TYPE_CD> (CWE)...... 15 6TABLE 4. VOCABULARY DOMAIN FOR <CONFIDENTIALITY_CD> (CWE)...... 16 7TABLE 5. VOCABULARY DOMAIN FOR <DOCUMENT_RELATIONSHIP.TYPE_CD> (CNE)...... 17 8TABLE 6. VOCABULARY DOMAIN FOR <FULFILLS_ORDER.TYPE_CD> (CNE)...... 17 9TABLE 7. VOCABULARY DOMAIN FOR <PRACTICE_SETTING_CD> (CWE)...... 18 10TABLE 8. VOCABULARY DOMAIN FOR <PERSON_NAME.TYPE_CD> (CWE)...... 18 11TABLE 9. VOCABULARY DOMAIN FOR <AUTHENTICATOR.TYPE_CD> (CNE)...... 19 12TABLE 10. VOCABULARY DOMAIN FOR <LEGAL_AUTHENTICATOR.TYPE_CD> (CNE)...... 19 13TABLE 11. VOCABULARY DOMAIN FOR <SIGNATURE_CD> (CNE)...... 19 14TABLE 12. VOCABULARY DOMAIN FOR <INTENDED_RECIPIENT.TYPE_CD> (CNE)...... 20 15TABLE 13. VOCABULARY DOMAIN FOR <ORIGINATOR.TYPE_CD> (CNE)...... 20 16TABLE 14. VOCABULARY DOMAIN FOR <ORIGINATING_ORGANIZATION.TYPE_CD> (CNE)...... 20 17TABLE 15. VOCABULARY DOMAIN FOR <TRANSCRIPTIONIST.TYPE_CD> (CNE)...... 20 18TABLE 16. VOCABULARY DOMAIN FOR <PROVIDER.TYPE_CD> (CNE)...... 21 19TABLE 17. VOCABULARY DOMAIN FOR <FUNCTION_CD> (CWE)...... 21 20TABLE 18. VOCABULARY DOMAIN FOR <SERVICE_ACTOR.TYPE_CD> (CWE)...... 22 21TABLE 19. VOCABULARY DOMAIN FOR <PATIENT.TYPE_CD> (CNE)...... 22 22TABLE 20. VOCABULARY DOMAIN FOR <ADMINISTRATIVE_GENDER_CD> (CWE)...... 22 23TABLE 21. VOCABULARY DOMAIN FOR <ORIGINATING_DEVICE.TYPE_CD> (CNE)...... 23 24TABLE 22. VOCABULARY DOMAIN FOR <RESPONSIBILITY.TYPE_CD> (CWE)...... 23 25TABLE 23. VOCABULARY DOMAIN FOR <SERVICE_TARGET.TYPE_CD> (CWE)...... 23 26TABLE 24. EXAMPLE CONCEPTS FOR <CAPTION_CD> (CWE)...... 48 27TABLE 25. EXAMPLE CONCEPTS FOR <CODED_ENTRY.VALUE>...... 56 28 291Health Level Seven, © 2000. All rights reserved 5 2Membership Ballot August 2000 11 Introduction21.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). 4312 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 Principles61.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 language351.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 Concepts412.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. 461Health 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. 25262.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. 391Health 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.010 Content-Type: multipart/mixed; boundary="HL7-CDA-boundary"11 Content-Transfer-Encoding: Base6412 --HL7-CDA-boundary13 Content-Type: application/x-hl7-cda-level-one+xml14 15 ... Base64-encoded CDA document ...16 17 --HL7-CDA-boundary18 Content-Type: image/JPEG19 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.53 <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.08 Content-Type: multipart/mixed; boundary="HL7-CDA-boundary"9 Content-Transfer-Encoding: Base6410 --HL7-CDA-boundary11 Content-Type: application/x-hl7-cda-level-one+xml12 13 ... Base64-encoded CDA document ...14 15 --HL7-CDA-boundary16 Content-Type: image/JPEG17 18 ... Base64 image ...19 20 --HL7-CDA-boundary-- 21 </Service.txt>22 </someMessage>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 Specifications23.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 <levelone>7 is the root element of a CDA Level One document. The <levelone> 19element, declared in the CDA Level One DTD, contains a <clinical_document_header> and a <body>. The 20details of <clinical_document_header> are explained in the next section (see 3.2 CDA Header), followed 21by the details of the <body> (see 3.3 CDA Level One Body). 22 23Vocabulary domains represent value sets for coded CDA components. These domains can include HL7- 24defined concepts or can be drawn from HL7-recognized coding systems such as LOINC or SNOMED. 25Vocabulary domains have a coding strength that can be "Coded, No Extensions" (CNE), in which case the 26only allowable values for the CDA component are those in the vocabulary domain; or "Coded, With 27Extensions" (CWE), in which case values other than those in the vocabulary domain (such as local codes) 28can be used if necessary8. Every vocabulary domain has a unique HL7-assigned identifier, and every 29concept within a vocabulary domain has a unique code. A coded CDA component may constrain its use of 30an associated vocabulary domain to a stated subset. 31 32Where a coded CDA component is associated with an HL7-defined vocabulary domain, the standard 33specifies the coding strength (CWE vs. CNE) and enumerates the allowable concepts with a code, display 34name, 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 3816 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 <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 7of abbreviations.83.2 CDA Header93.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 details273.2.2.1 Common XML attributes283.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. 3219 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 attribute2 <!ATTLIST Every_CDA_ELEMENT3 ...4 ID ID #IMPLIED5 ...>63.2.2.2 Document information73.2.2.2.1 Document identification 8Every document has a required, globally-unique instance identifier, <id>, an identifier that remains 9constant across all document revisions that derive from a common root, <set_id>, and a version number, 10<version_nbr>. These identifiers are useful in the management of addenda and replacements (as described 11in 3.2.2.2.4 Document relationships). An original report is the first version of a report, and gets a new 12globally unique <id> value. An original report also gets a new value for <set_id>, and has the value of 13<version_nbr> set to equal "1".15Every document has a required document type code, <document_type_cd>. The externally-defined 16vocabulary 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 LOINC193.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 an110 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 <service_tmr> represents the time the service being documented took place. It is required unless there 5is an encounter associated with the service in which case <encounter_tmr>, which represents the time of 6the encounter, is required, and <service_tmr> need not be recorded11. Both <service_tmr> and 7<encounter_tmr> can be expressed as a point in time or a time interval. 8 9The <origination_dttm> represents the time an original document is initiated (e.g. dictated or input into a 10software interface). If a document is subsequently revised, the value of <origination_dttm> remains 11unchanged. 12 13The <copy_dttm> represents the time a document is released (i.e. copied or sent to a display device) from a 14document management system that maintains revision control over the document. Once valued, it cannot be 15changed. The intent of <copy_dttm> is to give the viewer of the document some notion as to how long the 16document has been out of the safe context of its document management system. 17 18Other time stamps in the document lifecycle are recorded through their association with the various service 19actors and service targets. Thus, there is a time associated with document authentication, origination, 20transcription, provider and other service actors’ participation, and patient and other service targets’ 21participation.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 <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 prapraCDActice) 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.313.2.2.2.4 Document relationships323.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 <id> value, a new value for 2<set_id>, and has the value of <version_nbr> set to equal "1". 3 4An addendum is an appendage to an existing report that contains supplemental information. The appendage 5is itself an original report, as described in the previous paragraph. The parent report being appended is 6referenced via <document_relationship>, with <document_relationship.type_cd> set to equal "APND" (for 7"appends"). The parent report being appended remains in place and its content and status are unaltered. 8 9A replacement report replaces an existing report. The replacement report gets a new globally unique <id> 10value, while the replacement report uses the same value for <set_id> as the parent report being replaced, 11and increments the value of <version_nbr> by 1. (Note that <version_nbr> must be incremented by one 12when a report is replaced, but can also be incremented more often to meet local requirements.) The parent 13report is considered superseded, but is still retained in the system for historical reference. The parent report 14being replaced is referenced via a <document_relationship>, with <document_relationship.type_cd> set to 15equal "RPLC" (for "replaces"). 16 17The following table summarizes allowable values for <document_relationship.type_cd>. 18 19 Table 5. Vocabulary domain for <document_relationship.type_cd> 20 (CNE) Code Display Name Definition 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.213.2.2.2.4.2 Relationship to orders 22Documents may be generated in response to one or more orders. The <fulfills_order> component of the 23CDA Header enables the explicit representation of the relationship to orders by expressing the globally 24unique identifier(s) of the orders that have been fulfilled. The following table summarizes allowable values 25for <fulfills_order.type_cd>. 26 27 Table 6. Vocabulary domain for <fulfills_order.type_cd> (CNE) Code Display Name Definition 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.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 <service_tmr> represents the time the service being documented took place. It is required unless there 33is an encounter associated with the service, in which case <encounter_tmr> (which represents the time of 34the encounter) is required, and <service_tmr> need not be recorded12. Both <service_tmr> and 35<encounter_tmr> can be expressed as a point in time or a time interval. 36 37An encounter also includes an optional practice setting code, <practice_setting_cd>, which is a 38categorization of the clinical setting (e.g. cardiology clinic, primary care clinic, rehabilitation hospital, 39skilled nursing facility) in which care is delivered. (Note that there is a many-to-many relationship between 40practice setting and the physical location where care is delivered. Thus, a particular room can provide the 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 <practice_setting_cd> should be drawn from the PracticeSetting vocabulary domain. 5 6 Table 7. Vocabulary domain for <practice_setting_cd> (CWE) Code Display Name* OF Outpatient facility CARD Cardiology clinic GIM General internal medicine clinic PC Primary care clinic RHEUM Rheumatology clinic SPMED Sports medicine clinic WND Wound clinic HU Hospital unit CCU Coronary care unit ER Emergency room ICU Intensive care unit PHU Psychiatric hospital unit RHU Rehabilitation hospital unit HOSP Hospital GACH General acute care hospital RH Rehabilitation hospital NCCF Nursing or Custodial Care Facility SNF Skilled nursing facility RTF Residential treatment facility SURF Substance use rehabilitation facility 7*Note that there are no definitions for these concepts included in RIM 0.98.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. <authenticator.type_cd>, 22<service_actor.type_cd>). While the role may be suggested by the XML element name, the type_cd values 23are the definitive indication13. 24 25Every person has a required globally unique identifier, an optional set of physical addresses and 26telecommunications addresses, and an optional set of names. A person's name has an effective date, 27<effective_tmr>, and a code, drawn from the PersonNameType vocabulary domain, that specifies the type 28of 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) Code Display Name Definition 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 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 <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 15A legally authenticated document exists when the individual who is legally responsible for the document 16has attested to its accuracy. The following table, drawn from the ServiceActor vocabulary domain, 17summarizes allowable values for <legal_authenticator.type_cd>. 18 19 Table 10. Vocabulary domain for <legal_authenticator.type_cd> 20 (CNE) Code Display Name Definition 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 22The <participation_tmr> element is used to indicate the time of authentication or legal authentication. 23 24Both authentication and legal authentication require that a document has been signed manually or 25electronically by the responsible individual. While electronic signatures are not part of the CDA Header, 26the CDA Header does require the acquisition of signature to be documented, via the <signature_cd> 27component. The following table, drawn from the ServiceActorSignature vocabulary domain, summarizes 28allowable values for <signature_cd>. 29 30 Table 11. Vocabulary domain for <signature_cd> (CNE) Code Display Name Definition 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 32The <signature_cd> can be used to distinguish between intended and actual authenticators. A value of "S" 33indicates that the signature has been obtained and is on file, whereas a value of "X" indicates that the actor 34is an intended authenticator or legal authenticator.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 <intended_recipient.type_cd>. 1Health Level Seven, © 2000. All rights reserved 19 2Membership Ballot August 2000 1 2 Table 12. Vocabulary domain for <intended_recipient.type_cd> (CNE) Code Display Name Definition TRC tracker A person who may receive copies of exchange about this service.33.2.2.4.4 Originators43.2.2.4.4.1 Originating person 5CDA documents can be originated (authored) by humans and/or by machines. The <originator> element is 6used to indicate human origination, and the <originating_device> element is used to indicate machine 7origination (see 3.2.2.5.2 Originating device). The CDA Header requires the specification of one or more 8document originators, but does not require that there be a human originator14. The <participation_tmr> 9element is used to indicate the time of origination. The following table, drawn from the ServiceActor 10vocabulary domain, summarizes allowable values for <originator.type_cd>. 11 12 Table 13. Vocabulary domain for <originator.type_cd> (CNE) Code Display Name Definition AUT author (originator) A person who originates (e.g., dictates) a document. 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 <originating_organization.type_cd>. 17 18 Table 14. Vocabulary domain for <originating_organization.type_cd> 19 (CNE) Code Display Name Definition CST custodian An organization who originates and is in charge of maintaining the document.203.2.2.4.5 Transcriptionist 21The CDA Header can specify a transcriptionist. The <participation_tmr> element is used to indicate the 22time of transcription. The following table, drawn from the ServiceActor vocabulary domain, summarizes 23allowable values for <transcriptionist.type_cd>. 24 25 Table 15. Vocabulary domain for <transcriptionist.type_cd> (CNE) Code Display Name Definition ENT data entry person A person entering the data into the originating system. 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 <participation_tmr> element is used to indicate the time of participation. 29The following table, drawn from the ServiceActor vocabulary domain, summarizes allowable values for the 30required <provider.type_cd>. 31 32 Table 16. Vocabulary domain for <provider.type_cd> (CNE) Code Display Name Definition 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 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 <originator> and <originating_device> are optional, but at least one or 3the other must be present. 4Health Level Seven, © 2000. All rights reserved 20 5Membership Ballot August 2000 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 2The optional <function_cd> describes the business function of the provider in more detail. The following 3table, drawn from the ServiceActorFunction vocabulary domain, summarizes allowable values for 4<function_cd>. 5 6 Table 17. Vocabulary domain for <function_cd> (CWE) Code Display Name Definition 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 8Note that the <function_cd> component designates the actual function performed in the service being 9documented. This is different from a role associated with a person or a profession- or specialty-code. For 10instance, the function "anesthetist" is not necessary served by an anesthesiologist.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 <service_actor> component. The <participation_tmr> element is used to indicate the time of 15participation. The <signature_cd> is used as described above (see 3.2.2.4.2 Authenticators) to differentiate 16actual vs. intended participation. The identity of the person or organization serving as actor must be 17specified. 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) Code Display Name Definition 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 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 <patient>. The value of the <patient> component 7indicates whose medical record this document belongs to. By default, the <patient> is also the principal 8subject of the service(s) being documented. If that is not the case, the CDA Header allows other service 9targets to be specified (see 3.2.2.5.3 Other service targets). The <participation_tmr> element is used to 10indicate the time of participation. The following table, drawn from the ServiceTargetType vocabulary 11domain, summarizes allowable values for <patient.type_cd>. 12 13 Table 19. Vocabulary domain for <patient.type_cd> (CNE) Code Display Name Definition 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 15The <patient> is defined as having the same components as any other person (see 3.2.2.4.1 People 16responsible 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 18domain, summarizes allowable values for <administrative_gender_cd>. 19 20 Table 20. Vocabulary domain for <administrative_gender_cd> (CWE) Code Display Name Definition 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 22A <patient> has two types of identifiers. The first type of identifier can be used for any individual and 23belongs to a person independent of affiliation with a healthcare service provider (see 3.2.2.4.1 People 24responsible for a clinical document). The second type of identifier is used by a healthcare service provider 25to identify a patient with whom they have a relationship. This second type of identifier is used only for 26people in their role as patient under the auspices of a single provider organization. This identifier is 27represented by the <is_known_by > element and the <is_known_to > element identifies the healthcare 28provider.293.2.2.5.2 Originating device 30CDA documents can be originated (authored) by humans and/or by machines. The <originator> element is 31used to state human origination (see 3.2.2.4.4.1 Originating person), and the <originating_device> element 32is used to indicate machine origination. The CDA Header requires the specification of one or more 33document originators, but does not require that there be a human originator15. 34 35The optionally repeating CDA component <originating_device> indicates those devices used to originate 36portions of a CDA document. The <participation_tmr> element is used to indicate the time of origination. 115 Note that the XML DTD does not express this constraint in such a way that a validating XML processor 2can enforce conformance, since both <originator> and <originating_device> are optional, but at least one or 3the other must be present. 4Health Level Seven, © 2000. All rights reserved 22 5Membership Ballot August 2000 1The following table, drawn from the ServiceTargetType vocabulary domain, summarizes allowable values 2for <originating_device.type_cd>. 3 4 Table 21. Vocabulary domain for <originating_device.type_cd> (CNE) Code Display Name Definition ODV originating device A device that originates all or part of a document. 5 6Each originating device has a unique identifier and falls under the responsibility of one or more 7stakeholders, 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 9stakeholder assumed the type of responsiblity indicated by the <responsibility.type_cd> element. The 10following 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) Code Display Name Definition MNT maintainer A person in charge of the maintenance of a material. Assumes responsibility for proper operation, quality, and safety.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 <service_target> component. The <participation_tmr> element is used to indicate the 18time of participation. The following table, drawn from the ServiceTargetType vocabulary domain, suggests 19values for <service_target.type_cd>. 20 21 Table 23. Vocabulary domain for <service_target.type_cd> (CWE) Code Display Name Definition 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). 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<local_header> element. 27 28The <local_header> element is optionally repeating, and recursive. The "descriptor" attribute describes the 29element, and the value can be drawn from a local vocabulary domain. The "ignore" attribute tells the 30receiver to ignore just the <local_header> tag (ignore="markup"), or to ignore the <local_header> tag and 31all contained content (ignore="all"). The "render" attribute indicates how the sender would render the 32contents. The value can be drawn from a local vocabulary domain. The human language of contained 33character data can be specified using the xml:lang attribute (see 3.3.2.2.4 Language). The nested 34<local_attr> element is provided to make it easier to map local XML attribute values into local markup. 351Health Level Seven, © 2000. All rights reserved 23 2Membership Ballot August 2000 1 Figure 5. XML content model of <local_header>2 <!ELEMENT local_header (#PCDATA | local_header | local_attr)* >3 <!ATTLIST local_header4 ignore (all | markup) "markup"5 descriptor CDATA #IMPLIED6 render CDATA #IMPLIED7 ID ID #IMPLIED8 xml:lang NMTOKEN #IMPLIED >9 <!ELEMENT local_attr EMPTY>10 <ATTLIST local_attr11 name NMTOKEN #REQUIRED12 value CDATA #REQUIRED13 ID ID #IMPLIED14 xml:lang NMTOKEN #IMPLIED> 151Health 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 <CE> 0..1 ServiceConfident CWE N C1 _cd service _cd header iality 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 12. assoc has_target service_ has_ target_ related_ document_ N service 1..1 M relationship service document relationship 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 service1Health 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 tmr1Health 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 <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 PersonNameTyp CWE name type_cd type_cd e 37. attr addr stakeholder addr addr person D SET <AD> 0..1 M 38. attr phon stakeholder phon phon 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 type_cd 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 43. assoc participation service_ participation_ person legal_ U person 1..1 M _of actor of_person authenticator 44. assoc has document_ has_ intended_recipient clinical_document N service_ 0..* M service service_ _header actor actor 45. attr type_cd service_ type_cd intended_ intended_recipient D CS 1..1 ServiceActor CNE M TRC C6 actor recipient. type_cd 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 service service_ _header actor actor 48. attr type_cd service_ type_cd originator. originator D CS 1..1 ServiceActor CNE M AUT C81Health 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 <II> 0..1 M 55. attrib nm organizatio nm organization. organization D SET <ON> 0..1 M n nm 56. attrib addr stakeholder addr addr organization D SET <AD> 0..1 M 57. assoc has document_ has_ transcriptionist clinical_document N service_ 0..1 M service service_ _header actor actor 58. attr type_cd service_ type_cd transcriptionist transcriptionist D CS 1..1 ServiceActor CNE M ENT C10 actor .type_cd 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 _of actor of_person 61. assoc has document_ has_ provider clinical_document N service_ 1..* M service service_ _header actor actor 62. attr type_cd service_ type_cd provider. provider D CS 1..1 ServiceActor CNE M PRF C11 actor type_cd 63. attr function_cd service_ function_cd function_cd provider D CE 0..1 ServiceActorFun CWE actor ction 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 service service_ _header actor1Health 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<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 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 83. attr tmr service_ tmr participation_ originating_device D IVL_TS 0..1 M target tmr1Health 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 <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 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 service service_ _header actor target 91. attr type_cd service_ type_cd service_target. service_target D CE 1..1 ServiceTargetTy CWE target type_cd pe 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 2C1 :: The ServiceConfidentiality vocabulary domain is constrained to only include: "C", "D", "I", "N", "R", "S", "T". (See also 3.2.2.2.3 Document 3 confidentiality.) 4C2 :: The ServiceRelationship vocabulary domain is constrained to only include: "APND", "RPLC". (See also 3.2.2.2.4.1 Relationships between documents.) 5C3 :: The ServiceRelationship vocabulary domain is constrained to only include: "FLFS". (See also 3.2.2.2.4.2 Relationship to orders.) 6C4 :: The ServiceActor vocabulary domain is constrained to only include: "VRF". (See also 3.2.2.4.2 Authenticators.) 7C5 :: The ServiceActor vocabulary domain is constrained to only include: "SPV". (See also 3.2.2.4.2 Authenticators.) 8C6 :: The ServiceActor vocabulary domain is constrained to only include: "TRC". (See also 3.2.2.4.3 Intended recipients.) 9C7 :: There must be at least one <originator> or <originating_device>. 10C8 :: The ServiceActor vocabulary domain is constrained to only include: "AUT". (See also 3.2.2.4.4.1 Originating person.) 11C9 :: The ServiceActor vocabulary domain is constrained to only include: "CST". (See also 3.2.2.4.4.2 Originating organization.) 12C10 :: The ServiceActor vocabulary domain is constrained to only include: "ENT". (See also 3.2.2.4.5 Transcriptionist.) 13C11 :: The ServiceActor vocabulary domain is constrained to only include: "ASS", "CON", "PRF". (See also 3.2.2.4.6 Healthcare providers.) 14C12 :: The ServiceTargetType vocabulary domain is constrained to only include: "PAT", "PATSBJ". (See also 3.2.2.5.1 Patient.) 15C13 :: There must be at least one <originator> or <originating_device>.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<!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 1Health Level Seven, © 2000. All rights reserved 32 2Membership Ballot August 2000 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 1Health Level Seven, © 2000. All rights reserved 34 2Membership Ballot August 2000 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*)> 1Health Level Seven, © 2000. All rights reserved 35 2Membership Ballot August 2000 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 17 T NMTOKEN #FIXED "CS" 18 V CDATA #FIXED "FLFS" 19 V-T NMTOKEN #FIXED "ST" 20 V-HL7_NAME CDATA #FIXED "code" 21 DN CDATA #IMPLIED 22 DN-T NMTOKEN #FIXED "ST" 23 DN-HL7_NAME CDATA #FIXED "displayName" 24 %common_atts; 25 HL7-NAME CDATA #FIXED 'type_cd'> 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; 1Health Level Seven, © 2000. All rights reserved 36 2Membership Ballot August 2000 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*, 1Health Level Seven, © 2000. All rights reserved 37 2Membership Ballot August 2000 1 phon*, 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 20 %IVL_TS-attrib.list; 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; 34 HL7-NAME CDATA #FIXED 'type_cd'> 35 36<!ELEMENT phon %TEL-cont.model;> 37<!ATTLIST phon 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*)> 1Health Level Seven, © 2000. All rights reserved 38 2Membership Ballot August 2000 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 8 T NMTOKEN #FIXED "CS" 9 V CDATA #FIXED "VRF" 10 V-T NMTOKEN #FIXED "ST" 11 V-HL7_NAME CDATA #FIXED "code" 12 DN CDATA #IMPLIED 13 DN-T NMTOKEN #FIXED "ST" 14 DN-HL7_NAME CDATA #FIXED "displayName" 15 %common_atts; 16 HL7-NAME CDATA #FIXED 'type_cd'> 17 18<!ELEMENT participation_tmr %IVL_TS-cont.model;> 19<!ATTLIST participation_tmr 20 %IVL_TS-attrib.list; 21 %common_atts; 22 HL7-NAME CDATA #FIXED 'tmr'> 23 24<!ELEMENT signature_cd %CS-cont.model;> 25<!ATTLIST signature_cd 26 T NMTOKEN #FIXED "CS" 27 V (S|X) "S" 28 V-T NMTOKEN #FIXED "ST" 29 V-HL7_NAME CDATA #FIXED "code" 30 DN CDATA #IMPLIED 31 DN-T NMTOKEN #FIXED "ST" 32 DN-HL7_NAME CDATA #FIXED "displayName" 33 %common_atts; 34 HL7-NAME CDATA #FIXED 'signature_cd'> 35 36<!ELEMENT legal_authenticator ( 37 legal_authenticator.type_cd, 38 participation_tmr, 39 signature_cd, 40 person, 41 local_header*)> 42<!ATTLIST legal_authenticator 43 %common_atts; 44 HL7-NAME CDATA #FIXED 'has_service_actor' 45 T CDATA #FIXED 'service_actor'> 46 47<!ELEMENT legal_authenticator.type_cd %CS-cont.model;> 48<!ATTLIST legal_authenticator.type_cd 49 T NMTOKEN #FIXED "CS" 50 V CDATA #FIXED "SPV" 51 V-T NMTOKEN #FIXED "ST" 52 V-HL7_NAME CDATA #FIXED "code" 53 DN CDATA #IMPLIED 54 DN-T NMTOKEN #FIXED "ST" 55 DN-HL7_NAME CDATA #FIXED "displayName" 56 %common_atts; 57 HL7-NAME CDATA #FIXED 'type_cd'> 1Health Level Seven, © 2000. All rights reserved 39 2Membership Ballot August 2000 1 2 10 11<!ELEMENT intended_recipient ( 12 intended_recipient.type_cd, 13 person, 14 local_header*)> 15<!ATTLIST intended_recipient 16 %common_atts; 17 HL7-NAME CDATA #FIXED 'has_service_actor' 18 T CDATA #FIXED 'service_actor'> 19 20<!ELEMENT intended_recipient.type_cd %CS-cont.model;> 21<!ATTLIST intended_recipient.type_cd 22 T NMTOKEN #FIXED "CS" 23 V CDATA #FIXED "TRC" 24 V-T NMTOKEN #FIXED "ST" 25 V-HL7_NAME CDATA #FIXED "code" 26 DN CDATA #IMPLIED 27 DN-T NMTOKEN #FIXED "ST" 28 DN-HL7_NAME CDATA #FIXED "displayName" 29 %common_atts; 30 HL7-NAME CDATA #FIXED 'type_cd'> 31 32 41 42<!ELEMENT originator ( 43 originator.type_cd, 44 participation_tmr, 45 person, 46 local_header*)> 47<!ATTLIST originator 48 %common_atts; 49 HL7-NAME CDATA #FIXED 'has_service_actor' 50 T CDATA #FIXED 'service_actor'> 51 52<!ELEMENT originator.type_cd %CS-cont.model;> 53<!ATTLIST originator.type_cd 54 T NMTOKEN #FIXED "CS" 55 V CDATA #FIXED "AUT" 56 V-T NMTOKEN #FIXED "ST" 57 V-HL7_NAME CDATA #FIXED "code" 1Health Level Seven, © 2000. All rights reserved 40 2Membership Ballot August 2000 1 DN CDATA #IMPLIED 2 DN-T NMTOKEN #FIXED "ST" 3 DN-HL7_NAME CDATA #FIXED "displayName" 4 %common_atts; 5 HL7-NAME CDATA #FIXED 'type_cd'> 6 7<!ELEMENT originating_organization ( 8 originating_organization.type_cd, 9 organization, 10 local_header*)> 11<!ATTLIST originating_organization 12 %common_atts; 13 HL7-NAME CDATA #FIXED 'has_service_actor' 14 T CDATA #FIXED 'service_actor'> 15 16<!ELEMENT originating_organization.type_cd %CS-cont.model;> 17<!ATTLIST originating_organization.type_cd 18 T NMTOKEN #FIXED "CS" 19 V CDATA #FIXED "CST" 20 V-T NMTOKEN #FIXED "ST" 21 V-HL7_NAME CDATA #FIXED "code" 22 DN CDATA #IMPLIED 23 DN-T NMTOKEN #FIXED "ST" 24 DN-HL7_NAME CDATA #FIXED "displayName" 25 %common_atts; 26 HL7-NAME CDATA #FIXED 'type_cd'> 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*)> 1Health Level Seven, © 2000. All rights reserved 41 2Membership Ballot August 2000 1<!ATTLIST transcriptionist 2 %common_atts; 3 HL7-NAME CDATA #FIXED 'has_service_actor' 4 T CDATA #FIXED 'service_actor'> 5 6<!ELEMENT transcriptionist.type_cd %CS-cont.model;> 7<!ATTLIST transcriptionist.type_cd 8 T NMTOKEN #FIXED "CS" 9 V CDATA #FIXED "ENT" 10 V-T NMTOKEN #FIXED "ST" 11 V-HL7_NAME CDATA #FIXED "code" 12 DN CDATA #IMPLIED 13 DN-T NMTOKEN #FIXED "ST" 14 DN-HL7_NAME CDATA #FIXED "displayName" 15 %common_atts; 16 HL7-NAME CDATA #FIXED 'type_cd'> 17 18 26 27<!ELEMENT provider ( 28 provider.type_cd, 29 function_cd?, 30 participation_tmr?, 31 person, 32 local_header*)> 33<!ATTLIST provider 34 %common_atts; 35 HL7-NAME CDATA #FIXED 'has_service_actor' 36 T CDATA #FIXED 'service_actor'> 37 38<!ELEMENT provider.type_cd %CS-cont.model;> 39<!ATTLIST provider.type_cd 40 T NMTOKEN #FIXED "CS" 41 V (ASS|CON|PRF) "PRF" 42 V-T NMTOKEN #FIXED "ST" 43 V-HL7_NAME CDATA #FIXED "code" 44 DN CDATA #IMPLIED 45 DN-T NMTOKEN #FIXED "ST" 46 DN-HL7_NAME CDATA #FIXED "displayName" 47 %common_atts; 48 HL7-NAME CDATA #FIXED 'type_cd'> 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, 10 participation_tmr?, 11 signature_cd?, 12 (person | organization), 13 local_header*)> 14<!ATTLIST service_actor 15 %common_atts; 16 HL7-NAME CDATA #FIXED 'has_service_actor' 17 T CDATA #FIXED 'service_actor'> 18 19<!ELEMENT service_actor.type_cd %CE-cont.model;> 20<!ATTLIST service_actor.type_cd 21 %CE-attrib.list; 22 %common_atts; 23 HL7-NAME CDATA #FIXED 'type_cd'> 24 25 36 37 46 47<!ELEMENT patient ( 48 patient.type_cd, 49 participation_tmr?, 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' 1Health Level Seven, © 2000. All rights reserved 43 2Membership Ballot August 2000 1 T CDATA #FIXED 'service_target'> 2 3<!ELEMENT patient.type_cd %CS-cont.model;> 4<!ATTLIST patient.type_cd 5 T NMTOKEN #FIXED "CS" 6 V (PAT|PATSBJ) "PATSBJ" 7 V-T NMTOKEN #FIXED "ST" 8 V-HL7_NAME CDATA #FIXED "code" 9 DN CDATA #IMPLIED 10 DN-T NMTOKEN #FIXED "ST" 11 DN-HL7_NAME CDATA #FIXED "displayName" 12 %common_atts; 13 HL7-NAME CDATA #FIXED 'type_cd'> 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, 56 participation_tmr?, 57 device, 1Health Level Seven, © 2000. All rights reserved 44 2Membership Ballot August 2000 1 local_header*)> 2<!ATTLIST originating_device 3 %common_atts; 4 HL7-NAME CDATA #FIXED 'has_service_target' 5 T CDATA #FIXED 'service_target'> 6 7<!ELEMENT originating_device.type_cd %CS-cont.model;> 8<!ATTLIST originating_device.type_cd 9 T NMTOKEN #FIXED "CS" 10 V CDATA #FIXED "ODV" 11 V-T NMTOKEN #FIXED "ST" 12 V-HL7_NAME CDATA #FIXED "code" 13 DN CDATA #IMPLIED 14 DN-T NMTOKEN #FIXED "ST" 15 DN-HL7_NAME CDATA #FIXED "displayName" 16 %common_atts; 17 HL7-NAME CDATA #FIXED 'type_cd'> 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; 42 HL7-NAME CDATA #FIXED 'type_cd'> 43 44<!ELEMENT responsibility_tmr %IVL_TS-cont.model;> 45<!ATTLIST responsibility_tmr 46 %IVL_TS-attrib.list; 47 %common_atts; 48 HL7-NAME CDATA #FIXED 'tmr'> 49 50 1Health Level Seven, © 2000. All rights reserved 45 2Membership Ballot August 2000 1 2<!ELEMENT service_target ( 3 service_target.type_cd, 4 participation_tmr?, 5 person, 6 local_header*)> 7<!ATTLIST service_target 8 %common_atts; 9 HL7-NAME CDATA #FIXED 'has_service_target' 10 T CDATA #FIXED 'service_target'> 11 12<!ELEMENT service_target.type_cd %CE-cont.model;> 13<!ATTLIST service_target.type_cd 14 %CE-attrib.list; 15 %common_atts; 16 HL7-NAME CDATA #FIXED 'type_cd'> 17 18 43 44<!ELEMENT local_header (#PCDATA | local_header | local_attr)* > 45<!ATTLIST local_header 46 ignore (all | markup) "markup" 47 descriptor CDATA #IMPLIED 48 render CDATA #IMPLIED 49 %common_atts; 50 xml:lang NMTOKEN #IMPLIED > 51 52<!ELEMENT local_attr EMPTY> 53<!ATTLIST local_attr 54 name NMTOKEN #REQUIRED 55 value CDATA #REQUIRED 56 %common_atts; 57 xml:lang NMTOKEN #IMPLIED> 1Health Level Seven, © 2000. All rights reserved 46 2Membership Ballot August 2000 13.3 CDA Level One Body23.3.1 Overview 3The CDA element <levelone> is the root element of a CDA Level One document. The <levelone> element 4contains a <clinical_document_header> and a <body>. The <clinical_document_header> is derived from 5the RIM, as described in detail above (see 3.2 CDA Header). The <body> is comprised of either <section> 6elements, or a <non_xml> element, which is used when the document body is in some format other then 7XML. A CDA <section> can contain "structures", nested <section> elements, and <coded_entry> elements. 8CDA 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 12Where CDA entries are derivable from the RIM, as is currently only the case for the <observation_media> 13element, they have an associated Hierarchical Description (HD) and an XML representation that follows 14the style used for the CDA Header. 15 16Document analysis was used to articulate requirements for the CDA Level One Body. These are expressed 17in XML using industry-standard constructs. The structural components themselves are not part of RIM 180.98. The Unified Modeling Language (UML) model of the CDA Level One Body included in the 19appendix (see 5.2 CDA Level One Body UML model) is presented as a non-normative tool to aid in 20understanding the XML DTD.213.3.2 Technical details223.3.2.1 Document body and sections233.3.2.1.1 Document body 24The CDA <body> occurs in the <levelone> element. All CDA documents have exactly one <body>. The 25<body> contains either one or more <section> elements (see 3.3.2.1.2 Document sections) or a single 26<non_xml> data segment (see ID ID #IMPLIED). 27 28The <body> has an optional local identifier (see 3.3.2.2.1 XML element identification), an optional set of 29confidentiality status flags (see 3.3.2.2.2 Confidentiality), and an optional set of originators (see 3.3.2.2.3 30Originators). The human language of contained character data can be specified using the xml:lang attribute 31(see 3.3.2.2.4 Language). 32 33 Figure 7. XML content model of <body>34 <!ELEMENT body (section+ | non_xml) >35 <!ATTLIST body 36 ID ID #IMPLIED37 confidentiality IDREFS #IMPLIED38 originator IDREFS #IMPLIED39 xml:lang NMTOKEN #IMPLIED >403.3.2.1.2 Document sections 41The CDA <section> is a container used to wrap other containers. A <section> can occur in the <body>, or 42can be nested within another <section>. A <section> has an optional <caption> (see 3.3.2.1.2.1 Captions), 1Health Level Seven, © 2000. All rights reserved 47 2Membership Ballot August 2000 1followed by nested <section> elements or structures (see 3.3.2.3 Document Structures), followed by 2optionally repeating <coded_entry> elements (see 3.3.2.4.4 Coded entries). 3 4Each <section> has an optional local identifier (see 3.3.2.2.1 XML element identification), an optional set 5of confidentiality status flags (see 3.3.2.2.2 Confidentiality), and an optional set of originators (see 3.3.2.2.3 6Originators). The human language of contained character data can be specified using the xml:lang attribute 7(see 3.3.2.2.4 Language). 8 9 Figure 8. XML content model of <section>10 <!ELEMENT section (caption?, (paragraph | list | table | 11 section)*, coded_entry*)>12 <!ATTLIST section13 ID ID #IMPLIED14 confidentiality IDREFS #IMPLIED15 originator IDREFS #IMPLIED16 xml:lang NMTOKEN #IMPLIED>173.3.2.1.2.1 Captions 18The CDA <caption> is a label for a container. The <caption> element can occur in a <section>, 19<paragraph>, <list>, <item>, or <table> element. A <caption> contains plain text and may contain links 20(see 3.3.2.4.3 Links), and can be coded using the <caption_cd> element. A <caption_cd> is optional and 21non-repeatable, and must occur first within a <caption>16. The vocabulary domain for <caption_cd>, 22DocumentSectionType, is externally-defined by LOINC. Example <caption_cd> values, drawn from the 23DocumentSectionType vocabulary domain, are shown in the following table. 24 25 Table 24. Example concepts for <caption_cd> (CWE) Code Display Name Code System Code System Name 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 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 26 27Each <caption> has an optional local identifier (see 3.3.2.2.1 XML element identification), an optional set 28of confidentiality status flags (see 3.3.2.2.2 Confidentiality), and an optional set of originators (see 3.3.2.2.3 29Originators). The human language of contained character data can be specified using the xml:lang attribute 30(see 3.3.2.2.4 Language). 31116 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 <caption>2 <!ELEMENT caption (#PCDATA | link | caption_cd)*>3 <!ATTLIST caption4 ID ID #IMPLIED5 confidentiality IDREFS #IMPLIED6 originator IDREFS #IMPLIED7 xml:lang NMTOKEN #IMPLIED>8 <!ELEMENT caption_cd %CE-cont.model;>9 <!ATTLIST caption_cd10 %CE-attrib.list;11 ID ID #IMPLIED12 confidentiality IDREFS #IMPLIED13 originator IDREFS #IMPLIED14 xml:lang NMTOKEN #IMPLIED>153.3.2.1.3 Non_xml body 16The CDA <non_xml> container represents a document body that is in some format other than XML. CDA's 17<non_xml> is an encoded data type (ED), which is used only to reference data that is stored externally to 18the CDA Level One document. To incorporate non-XML data within an XML document, see 3.3.2.4.5 19Observation media. 20 21The <non_xml> element has an optional local identifier (see 3.3.2.2.1 XML element identification), an 22optional set of confidentiality status flags (see 3.3.2.2.2 Confidentiality), and an optional set of originators 23(see 3.3.2.2.3 Originators). The human language of contained character data can be specified using the 24xml:lang attribute (see 3.3.2.2.4 Language). 25 26 Figure 10. XML content model of <non_xml>27 <!ELEMENT non_xml %ED-cont.model;>28 <!ATTLIST non_xml29 %ED-attrib.list;30 ID ID #IMPLIED31 confidentiality IDREFS #IMPLIED32 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 identification1Health 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 <confidentiality_cd> (see 3.2.2.2.3 Document confidentiality). The 6confidentiality attribute on CDA Body elements can reference one or more of the confidentiality values in 7the CDA Header using XML IDREFS. The value(s) referenced must be XML ID(s) in the 8<confidentiality_cd> element of the CDA Header. Confidentiality is inherited by nested content, unless 9overridden. 10 11 Figure 11. XML confidentiality attribute12 <!ATTLIST Every_CDA_ELEMENT13 ...14 confidentiality IDREFS #IMPLIED15 ...>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 <originator> (see 3.2.2.4.4.1 Originating person) and <originating_device> 19(see 3.2.2.5.2 Originating device). The originator attribute on an element within the CDA Body can 20reference one or more of these values using XML IDREFS. The value(s) referenced must be XML ID(s) in 21the <originator> or <originating_device> element of the CDA Header. Origination is inherited by nested 22content, unless overridden. 23 24 Figure 12. XML originator attribute25 <!ATTLIST Every_CDA_ELEMENT26 ...27 originator IDREFS #IMPLIED28 ...>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. 401Health Level Seven, © 2000. All rights reserved 50 2Membership Ballot August 2000 1 Figure 13. XML xml:lang attribute2 <!ATTLIST Every_CDA_ELEMENT3 ...4 xml:lang NMTOKEN #IMPLIED5 ...>673.3.2.3 Document Structures83.3.2.3.1 Paragraphs 9The CDA <paragraph> can occur in a <section>, <item>, or table cell (<td>). A <paragraph> has an 10optional <caption> (see 3.3.2.1.2.1 Captions), followed by zero or more <content> elements (see 3.3.2.4.2 11Content). 12 13Each <paragraph> has an optional local identifier (see 3.3.2.2.1 XML element identification), an optional 14set of confidentiality status flags (see 3.3.2.2.2 Confidentiality), and an optional set of originators (see 153.3.2.2.3 Originators). The human language of contained character data can be specified using the xml:lang 16attribute (see 3.3.2.2.4 Language). 17 18 Figure 14. XML content model of <paragraph>19 <!ELEMENT paragraph (caption?, content*) >20 <!ATTLIST paragraph21 ID ID #IMPLIED22 confidentiality IDREFS #IMPLIED23 originator IDREFS #IMPLIED24 xml:lang NMTOKEN #IMPLIED >253.3.2.3.2 Lists and list items 26The CDA <list> can occur in a <section>, <item>, or table cell (<td>). A <list> has an optional <caption> 27(see 3.3.2.1.2.1 Captions), and contains one or more <item> elements. The list_type attribute specifies 28whether the <list> is ordered or unordered (with unordered being the default). Use an ordered list when the 29ordering of list items is meaningful. 30 31Each <list> 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 <item> only occurs within a <list>. An <item> has an optional <caption> (see 3.3.2.1.2.1 37Captions), and may contain <content> (see 3.3.2.4.2 Content) and nested structures (see 3.3.2.3 Document 38Structures). 39 40Each <item> has an optional local identifier (see 3.3.2.2.1 XML element identification), an optional set of 41confidentiality status flags (see 3.3.2.2.2 Confidentiality), and an optional set of originators (see 3.3.2.2.3 42Originators). The human language of contained character data can be specified using the xml:lang attribute 43(see 3.3.2.2.4 Language). 44 1Health Level Seven, © 2000. All rights reserved 51 2Membership Ballot August 2000 1 Figure 15. XML content model of <list> and <item>2 <!ELEMENT list (caption?, item+)>3 <!ATTLIST list 4 list_type (ordered | unordered) "unordered" 5 ID ID #IMPLIED6 confidentiality IDREFS #IMPLIED7 originator IDREFS #IMPLIED8 xml:lang NMTOKEN #IMPLIED >9 <!ELEMENT item (caption?, (content | paragraph | list | table)*)>10 <!ATTLIST item11 ID ID #IMPLIED12 confidentiality IDREFS #IMPLIED13 originator IDREFS #IMPLIED14 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 <table> can 18occur in a <section> or <item>. A <table> has an optional <caption> (see 3.3.2.1.2.1 Captions). 19 20CDA modifies the strict XHTML table model (see 5.4 References and Appendix 5.3.1 Tables) by removing 21formatting tags and by setting the content model of cells to be similar to the contents of other CDA 22containers. The <th> element is modeled analogously to the <caption> element (see 3.3.2.1.2.1 Captions), 23and like the <caption> element, the <caption_cd> is optional and non-repeatable, and must occur first. 24 25Each element in the table model has an optional local identifier (see 3.3.2.2.1 XML element identification), 26an optional set of confidentiality status flags (see 3.3.2.2.2 Confidentiality), and an optional set of 27originators (see 3.3.2.2.3 Originators). The human language of contained character data can be specified 28using the xml:lang attribute (see 3.3.2.2.4 Language). 291Health Level Seven, © 2000. All rights reserved 52 2Membership Ballot August 2000 1 Figure 16. Changes to the strict XHTML table model in CDA2 Change this:3 <!ELEMENT caption %Inline;>4 To this:5 <!ELEMENT caption (#PCDATA | link | caption_cd)*>6 7 Change these XML attributes:8 %attrs;9 To these:10 ID ID #IMPLIED11 confidentiality IDREFS #IMPLIED12 originator IDREFS #IMPLIED13 xml:lang NMTOKEN #IMPLIED14 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)*>253.3.2.4 Document Entries263.3.2.4.1 Character data 27CDA character data (i.e., XML #PCDATA) occurs in <content>, <local_markup>, <caption>, 28<link_html>, or table cells (both <td> and <th>). 293.3.2.4.2 Content 30CDA <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 33The <content> element can nest recursively, which enables wrapping a string of plain text down to as small 34a chunk as desired. These <content> elements can serve as anchors, and <coded_entry.value> elements can 35reference these anchors to indicate the original text that supports the use of a coded entry. (See 3.3.2.4.4 36Coded entries for more detail.) 371Health Level Seven, © 2000. All rights reserved 53 2Membership Ballot August 2000 1Each <content> element has an optional local identifier (see 3.3.2.2.1 XML element identification), an 2optional set of confidentiality status flags (see 3.3.2.2.2 Confidentiality), and an optional set of originators 3(see 3.3.2.2.3 Originators). The human language of contained character data can be specified using the 4xml:lang attribute (see 3.3.2.2.4 Language). 5 6 Figure 17. XML content model of <content>7 <!ELEMENT content (#PCDATA | content | link | coded_entry | 8 observation_media | local_markup)*>9 <!ATTLIST content10 ID ID #IMPLIED11 confidentiality IDREFS #IMPLIED12 originator IDREFS #IMPLIED13 xml:lang NMTOKEN #IMPLIED >143.3.2.4.3 Links 15The CDA <link> is a generic referencing mechanism and occurs within <content>, <local_markup>, table 16cells (<td>), or <caption>. A <link> contains a single required <link_html> element. 17 18Each <link> has an optional local identifier (see 3.3.2.2.1 XML element identification), an optional set of 19confidentiality status flags (see 3.3.2.2.2 Confidentiality), and an optional set of originators (see 3.3.2.2.3 20Originators). The human language of contained character data can be specified using the xml:lang attribute 21(see 3.3.2.2.4 Language). 22 23The CDA <link_html> can only occur within a <link>. Each <link_html> has an optional local identifier 24(see 3.3.2.2.1 XML element identification), an optional set of confidentiality status flags (see 3.3.2.2.2 25Confidentiality), and an optional set of originators (see 3.3.2.2.3 Originators). The human language of 26contained character data can be specified using the xml:lang attribute (see 3.3.2.2.4 Language). 27 28The CDA link mechanism is based on the HTML anchor tag. Several groups (see 5.4 References) are 29actively developing formal link specifications. When a suitable open standard is available and 30implemented, it will be reviewed with the intent to incorporate it into the CDA Level One specification. 31 32Multimedia that is integral to a document, and part of the attestable content of the document requires the 33use of <observation_media> (see 3.3.2.4.5 Observation media). Multimedia that is simply referenced by the 34document and not an integral part of the document should use <link>. 351Health Level Seven, © 2000. All rights reserved 54 2Membership Ballot August 2000 1 Figure 18. XML content model of <link> and <link_html>2 <!ELEMENT link (link_html) >3 <!ATTLIST link4 ID ID #IMPLIED5 confidentiality IDREFS #IMPLIED6 originator IDREFS #IMPLIED7 xml:lang NMTOKEN #IMPLIED >8 <!ELEMENT link_html (#PCDATA) >9 <!ATTLIST link_html10 name CDATA #IMPLIED 11 href CDATA #IMPLIED 12 rel CDATA #IMPLIED 13 rev CDATA #IMPLIED 14 title CDATA #IMPLIED 15 ID ID #IMPLIED16 confidentiality IDREFS #IMPLIED17 originator IDREFS #IMPLIED18 xml:lang NMTOKEN #IMPLIED>193.3.2.4.4 Coded entries 20The CDA element <coded_entry> inserts codes from HL7-recognized coding schemes into CDA 21documents. Where there are no suitable HL7-recognized codes available, locally-defined codes can be 22used. 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 24convention for insertion of locally-meaningful codes. 25 26The <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 30Each <coded_entry> has an optional local identifier (see 3.3.2.2.1 XML element identification), an optional 31set of confidentiality status flags (see 3.3.2.2.2 Confidentiality), and an optional set of originators (see 323.3.2.2.3 Originators). The human language of contained character data can be specified using the xml:lang 33attribute (see 3.3.2.2.4 Language). 34 35Example <coded_entry.value> values are shown in the following table. 36 37 Table 25. Example concepts for <coded_entry.value> Code Display Name Code System Code System Name 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 1Health Level Seven, © 2000. All rights reserved 55 2Membership Ballot August 2000 Code Display Name Code System Code System Name 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 19. 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 #IMPLIED7 confidentiality IDREFS #IMPLIED8 originator IDREFS #IMPLIED9 xml:lang NMTOKEN #IMPLIED >10 <!ELEMENT coded_entry.id %II-cont.model;>11 <!ATTLIST coded_entry.id12 %II-attrib.list;13 ID ID #IMPLIED >14 <!ELEMENT coded_entry.value %CD-cont.model;>15 <!ATTLIST coded_entry.value16 %CD-attrib.list; 17 ID ID #IMPLIED > 18 19The <coded_entry.value> element can explicitly reference the original text within the document that 20supports 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. 281Health Level Seven, © 2000. All rights reserved 56 2Membership Ballot August 2000 1 Figure 20. Referencing original text with <coded_entry>172 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 25117 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 <observation_media> element represents media that is logically a part of a CDA document, but is stored outside the document and incorporated by 3reference. Multimedia that is integral to a document, and part of the attestable content of the document, requires the use of <observation_media>. Multimedia 4that 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 7The 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>, 9which is modeled as an HL7 encoded data (ED) data type. 10 11The 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. 12Several groups (see 5.4 References) are actively developing formal specifications for packaging binary data within XML documents. When a suitable open 13standard for direct incorporation of binary data is available and implemented, it will be incorporated into the CDA Level One specification. 14 15Each <observation_media> has an optional local identifier (see 3.3.2.2.1 XML element identification), an optional set of confidentiality status flags (see 3.3.2.2.2 16Confidentiality), and an optional set of originators (see 3.3.2.2.3 Originators). The human language of contained character data can be specified using the 17xml:lang attribute (see 3.3.2.2.4 Language). 18 19 Figure 21. Hierarchical description of <observation_media> 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 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 21Abbreviations 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 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 <observation_media>4 <!ELEMENT observation_media (observation_media.id?, observation_media.value, local_markup*)>5 <!ATTLIST observation_media 6 ID ID #IMPLIED7 confidentiality IDREFS #IMPLIED8 originator IDREFS #IMPLIED9 xml:lang NMTOKEN #IMPLIED >10 <!ELEMENT observation_media.id %II-cont.model;>11 <!ATTLIST observation_media.id12 %II-attrib.list;13 ID ID #IMPLIED >14 <!ELEMENT observation_media.value %ED-cont.model;>15 <!ATTLIST observation_media.value16 %ED-attrib.list;17 ID ID #IMPLIED > 181Health 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 <local_markup> element 3parallels the implementation described above for the CDA Header (see 3.2.2.6 Localization). 4 5The <local_markup> element can occur in <coded_entry>, <observation_media>, <content>, table cells 6(<td>), and can be nested in <local_markup>. The <local_markup> element contains zero or more entries 7(see 3.3.2.4 Document Entries). 8 9Each <local_markup> has an optional local identifier (see 3.3.2.2.1 XML element identification), an 10optional set of confidentiality status flags (see 3.3.2.2.2 Confidentiality), and an optional set of originators 11(see 3.3.2.2.3 Originators). The language of contained character data can be specified using the xml:lang 12attribute (see 3.3.2.2.4 Language). 13 14The descriptor attribute describes the element, and the value can be drawn from a local vocabulary domain. 15The ignore attribute tells the receiver to ignore just the <local_markup> tag (ignore="markup"), or to 16ignore the <local_markup> tag and all contained content (ignore="all"). The render attribute indicates how 17the sender would render the contents. The value can be drawn from a local vocabulary domain. The nested 18<local_attr> element makes it easier to map local XML attribute values into the CDA. 19 20 Figure 23. XML content model of <local_markup>21 <!ELEMENT local_markup (#PCDATA | content | link | coded_entry | 22 observation_media | local_markup | local_attr)* >23 <!ATTLIST local_markup24 ignore (all | markup) "markup"25 descriptor CDATA #IMPLIED26 render CDATA #IMPLIED27 ID ID #IMPLIED28 confidentiality IDREFS #IMPLIED29 originator IDREFS #IMPLIED30 xml:lang NMTOKEN #IMPLIED >31 <!ELEMENT local_attr EMPTY>32 <ATTLIST local_attr33 name NMTOKEN #REQUIRED34 value CDATA #REQUIRED35 ID ID #IMPLIED36 xml:lang NMTOKEN #IMPLIED>371Health Level Seven, © 2000. All rights reserved 60 2Membership Ballot August 2000 13.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 originator IDREFS #IMPLIED 12 confidentiality IDREFS #IMPLIED 13 xml:lang NMTOKEN #IMPLIED 14"> 15 16<!ENTITY % entries "#PCDATA | content | link | coded_entry | 17observation_media | local_markup"> 18 19<!ENTITY % structures "paragraph | list | table"> 20 21 22 41 42<!ELEMENT levelone (clinical_document_header, body) > 43<!ATTLIST levelone 44 %common_atts; 45 %body_atts; 46> 47 48 49 16 17<!ELEMENT body (section+ | non_xml) > 18<!ATTLIST body 19 %common_atts; 20 %body_atts; 21> 22 23<!ELEMENT section (caption?,(%structures; | section)*, coded_entry*)> 24<!ATTLIST section 25 %common_atts; 26 %body_atts; 27> 28 29<!ELEMENT non_xml %ED-cont.model;> 30<!ATTLIST non_xml 31 %common_atts; 32 originator IDREFS #IMPLIED 33 confidentiality IDREFS #IMPLIED 34 %ED-attrib.list; 35> 36 37 38 47 48 7 8<!ELEMENT content (%entries;)*> 9<!ATTLIST content 10 %common_atts; 11 %body_atts; 12> 13 14 15 42 43<!ELEMENT link (link_html) > 44<!ATTLIST link 45 %common_atts; 46 %body_atts; 47> 48 49<!ELEMENT link_html (#PCDATA) > 50<!ATTLIST link_html 51 name CDATA #IMPLIED 52 href CDATA #IMPLIED 53 rel CDATA #IMPLIED 54 rev CDATA #IMPLIED 55 title CDATA #IMPLIED 56 %common_atts; 57 %body_atts; 1Health Level Seven, © 2000. All rights reserved 64 2Membership Ballot August 2000 1> 2 3 4 20 21<!ELEMENT coded_entry (coded_entry.id?, coded_entry.value, 22local_markup*)> 23<!ATTLIST coded_entry 24 %common_atts; 25 %body_atts;> 26 27<!ELEMENT coded_entry.id %II-cont.model;> 28<!ATTLIST coded_entry.id 29 %common_atts; 30 %II-attrib.list; > 31 32<!ELEMENT coded_entry.value %CD-cont.model;> 33<!ATTLIST coded_entry.value 34 %CD-attrib.list; 35 %common_atts;> 36 37 2 3<!ELEMENT observation_media (observation_media.id?, 4observation_media.value, local_markup*)> 5<!ATTLIST observation_media 6 %common_atts; 7 %body_atts; 8 HL7-NAME CDATA #FIXED 'observation' 9 T CDATA #FIXED 'observation'> 10 11<!ELEMENT observation_media.id %II-cont.model;> 12<!ATTLIST observation_media.id 13 %common_atts; 14 %II-attrib.list; 15 HL7-NAME CDATA #FIXED 'id'> 16 17<!ELEMENT observation_media.value %ED-cont.model;> 18<!ATTLIST observation_media.value 19 %common_atts; 20 %ED-attrib.list; 21 HL7-NAME CDATA #FIXED 'value'> 22 23 24 42 43<!ELEMENT local_markup (%entries; | local_attr)* > 44<!ATTLIST local_markup 45 ignore (all | markup) "markup" 46 descriptor CDATA #IMPLIED 47 render CDATA #IMPLIED 48 %common_atts; 49 %body_atts; 50> 51 52 53 5 6 16 17<!ELEMENT paragraph (caption?, content*) > 18<!ATTLIST paragraph 19 %common_atts; 20 %body_atts; 21> 22 23 24 41 42<!ELEMENT list (caption?, item+)> 43<!ATTLIST list 44 %common_atts; 45 %body_atts; 46 list_type (ordered | unordered) "unordered" 47> 48 49<!ELEMENT item (caption?, (content | %structures;)*)> 50<!ATTLIST item 51 %common_atts; 52 %body_atts; 53> 54 55 56 43 44 45 46<!ENTITY % Character "CDATA"> 47  48 49<!ENTITY % Length "CDATA"> 50  51 52<!ENTITY % MultiLength "CDATA"> 53  54 55<!ENTITY % Number "CDATA"> 56  57 1Health Level Seven, © 2000. All rights reserved 68 2Membership Ballot August 2000 1<!ENTITY % Pixels "CDATA"> 2  3 4<!ENTITY % Text "CDATA"> 5 6 8 9 10 11 19<!ENTITY % TFrame "(void|above|below|hsides|lhs|rhs|vsides|box|border)"> 20 21 27 28<!ENTITY % TRules "(none | groups | rows | cols | all)"> 29 30 35<!ENTITY % cellhalign 36 "align (left|center|right|justify|char) #IMPLIED 37 char %Character; #IMPLIED 38 charoff %Length; #IMPLIED" 39 > 40 41 42<!ENTITY % cellvalign 43 "valign (top|middle|bottom|baseline) #IMPLIED" 44 > 45 46<!ELEMENT table 47 (caption?, (col*|colgroup*), thead?, tfoot?, (tbody+|tr+))> 48<!ELEMENT caption (#PCDATA | link | caption_cd)*> 49<!ELEMENT caption_cd %CE-cont.model;> 50<!ELEMENT thead (tr)+> 51<!ELEMENT tfoot (tr)+> 52<!ELEMENT tbody (tr)+> 53<!ELEMENT colgroup (col)*> 54<!ELEMENT col EMPTY> 55<!ELEMENT tr (th|td)+> 56<!ELEMENT th (#PCDATA | link | caption_cd)*> 57<!ELEMENT td (%entries; | paragraph | list)*> 1Health Level Seven, © 2000. All rights reserved 69 2Membership Ballot August 2000 1 2<!ATTLIST table 3 %common_atts; 4 %body_atts; 5 summary %Text; #IMPLIED 6 width %Length; #IMPLIED 7 border %Pixels; #IMPLIED 8 frame %TFrame; #IMPLIED 9 rules %TRules; #IMPLIED 10 cellspacing %Length; #IMPLIED 11 cellpadding %Length; #IMPLIED 12 > 13 14<!ATTLIST caption 15 %common_atts; 16 %body_atts; 17> 18 19<!ATTLIST caption_cd 20 %body_atts; 21 %common_atts; 22 %CE-attrib.list; 23> 24 25 29<!ATTLIST colgroup 30 %common_atts; 31 %body_atts; 32 span %Number; "1" 33 width %MultiLength; #IMPLIED 34 %cellhalign; 35 %cellvalign; 36 > 37 38 50<!ATTLIST col 51 %common_atts; 52 %body_atts; 53 span %Number; "1" 54 width %MultiLength; #IMPLIED 55 %cellhalign; 56 %cellvalign; 57 > 1Health Level Seven, © 2000. All rights reserved 70 2Membership Ballot August 2000 1 2 14<!ATTLIST thead 15 %common_atts; 16 %body_atts; 17 %cellhalign; 18 %cellvalign; 19 > 20 21<!ATTLIST tfoot 22 %common_atts; 23 %body_atts; 24 %cellhalign; 25 %cellvalign; 26 > 27 28<!ATTLIST tbody 29 %common_atts; 30 %body_atts; 31 %cellhalign; 32 %cellvalign; 33 > 34 35<!ATTLIST tr 36 %common_atts; 37 %body_atts; 38 %cellhalign; 39 %cellvalign; 40> 41 42 43<!ENTITY % Scope "(row|col|rowgroup|colgroup)"> 44 45 46 47<!ATTLIST th 48 %common_atts; 49 %body_atts; 50 abbr %Text; #IMPLIED 51 axis CDATA #IMPLIED 52 headers IDREFS #IMPLIED 53 scope %Scope; #IMPLIED 54 rowspan %Number; "1" 55 colspan %Number; "1" 56 %cellhalign; 57 %cellvalign; 1Health Level Seven, © 2000. All rights reserved 71 2Membership Ballot August 2000 1 > 2 3<!ATTLIST td 4 %common_atts; 5 %body_atts; 6 abbr %Text; #IMPLIED 7 axis CDATA #IMPLIED 8 headers IDREFS #IMPLIED 9 scope %Scope; #IMPLIED 10 rowspan %Number; "1" 11 colspan %Number; "1" 12 %cellhalign; 13 %cellvalign; 14 > 151Health 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 <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 7 1Health Level Seven, © 2000. All rights reserved 73 2Membership Ballot August 2000 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 21Health 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 Samples285.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 361Health Level Seven, © 2000. All rights reserved 76 2Membership Ballot August 2000 15.1.2 Sample CDA document 18 2<?xml version="1.0"?> 3<!DOCTYPE levelone PUBLIC "-//HL7//DTD CDA Level One 1.0//EN" "levelone_1.0.dtd"> 4<levelone> 5 <clinical_document_header> 6 <id EX="a123" RT="2.16.840.1.113883.3.933"/> 7 <set_id EX="B" RT="2.16.840.1.113883.3.933"/> 8 <version_nbr V="2"/> 9 <document_type_cd V="11488-4" S="2.16.840.1.113883.6.1" 10 DN="Consultation note"/> 11 <origination_dttm V="2000-04-07"/> 12 <confidentiality_cd ID="CONF1" V="N" S="2.16.840.1.113883.5.1xxx"/>19 13 <confidentiality_cd ID="CONF2" V="R" S="2.16.840.1.113883.5.1xxx"/>20 14 <document_relationship> 15 <document_relationship.type_cd V="RPLC"/> 16 <related_document> 17 <id EX="a234" RT="2.16.840.1.113883.3.933"/> 18 <set_id EX="B" RT="2.16.840.1.113883.3.933"/> 19 <version_nbr V="1"/> 20 </related_document> 21 </document_relationship> 22 <fulfills_order> 23 <fulfills_order.type_cd V="FLFS"/> 24 <order><id EX="x23ABC" RT="2.16.840.1.113883.3.933"/></order> 25 <order><id EX="x42CDE" RT="2.16.840.1.113883.3.933"/></order> 26 </fulfills_order> 27 <patient_encounter> 28 <id EX="KPENC1332" RT="2.16.840.1.113883.3.933"/> 29 <practice_setting_cd V="GIM" 30 S="2.16.840.1.113883.5.1xxx" DN="General internal medicine clinic"/>21 31 <encounter_tmr V="2000-04-07"/> 32 <service_location> 33 <id EX="KXLPa123" RT="2.16.840.1.113883.3.933"/> 34 <addr> 35 <HNR V="970"/> 36 <STR V="Post St"/> 37 <DIR V="NE"/> 38 <CTY V="Alameda"/> 39 <STA V="CA"/> 40 <ZIP V="94501"/> 41 </addr> 42 </service_location> 43 </patient_encounter> 44 <legal_authenticator> 45 <legal_authenticator.type_cd V="SPV"/> 46 <participation_tmr V="2000-04-08"/> 47 <signature_cd V="S"/> 48 <person> 49 <id EX="KP00017" RT="2.16.840.1.113883.3.933"/> 50 <person_name> 51 <nm> 52 <GIV V="Robert"/> 53 <FAM V="Dolin"/> 54 <SFX V="MD" QUAL="PT"/> 55 </nm> 56 <person_name.type_cd V="L" S="2.16.840.1.113883.5.1xxx"/>22 57 </person_name>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 <addr> 2 <HNR V="970"/> 3 <STR V="Post St"/> 4 <DIR V="NE"/> 5 <CTY V="Alameda"/> 6 <STA V="CA"/> 7 <ZIP V="94501"/> 8 </addr> 9 <phon V="tel:(358)555-1234" USE="WPN"/> 10 </person> 11 </legal_authenticator> 12 <originator> 13 <originator.type_cd V="AUT"/> 14 <participation_tmr V="2000-04-07"/> 15 <person> 16 <id EX="KP00017" RT="2.16.840.1.113883.3.933"/> 17 <person_name> 18 <nm> 19 <GIV V="Robert"/> 20 <FAM V="Dolin"/> 21 <SFX V="MD"/> 22 </nm> 23 <person_name.type_cd V="L" S="2.16.840.1.113883.5.1xxx"/>23 24 </person_name> 25 </person> 26 </originator> 27 <originating_organization> 28 <originating_organization.type_cd V="CST"/> 29 <organization> 30 <id EX="M345" RT="2.16.840.1.113883.3.933"/> 31 <organization.nm V="Good Health Clinic"/> 32 </organization> 33 </originating_organization> 34 <provider> 35 <provider.type_cd V="CON"/> 36 <participation_tmr V="2000-04-07"/> 37 <person> 38 <id EX="KP00017" RT="2.16.840.1.113883.3.933"/> 39 </person> 40 </provider> 41 <patient> 42 <patient.type_cd V="PATSBJ"/> 43 <person> 44 <id EX="12345" RT="2.16.840.1.113883.3.933"/> 45 <person_name> 46 <nm> 47 <GIV V="Henry"/> 48 <FAM V="Levin"/> 49 <SFX V="the 7th"/> 50 </nm> 51 <person_name.type_cd V="L" S="2.16.840.1.113883.5.1xxx"/>24 52 </person_name> 53 <person_name> 54 <nm> 55 <GIV V="Hank"/> 56 <FAM V="Levin"/> 57 </nm> 58 <person_name.type_cd V="A" S="2.16.840.1.113883.5.1xxx"/>25 59 </person_name> 60 </person> 61 <birth_dttm V="1932-09-24"/> 62 <administrative_gender_cd V="M" S="2.16.840.1.113883.5.1xxx"/>26 63 </patient>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 <originating_device ID="DEV1"> 2 <originating_device.type_cd V="ODV"/> 3 <device> 4 <id EX="devX3498" RT="2.16.840.1.113883.3.933"/> 5 <responsibility> 6 <responsibility.type_cd V="MNT" S="2.16.840.1.113883.5.1xxx"/>27 7 <person> 8 <id EX="KP03257" RT="2.16.840.1.113883.3.933"/> 9 </person> 10 </responsibility> 11 </device> 12 </originating_device> 13 <local_header ignore="all" descriptor="MyLocalTag"> 14 ... extra stuff that is only used locally ... 15 </local_header> 16 </clinical_document_header> 17 <body confidentiality="CONF1"> 18 <section> 19 <caption> 20 <caption_cd V="8684-3" S="2.16.840.1.113883.6.1"/> 21 History of Present Illness 22 </caption> 23 <paragraph> 24 <content> 25 Henry Levin, the 7th is a 67 year old male referred for further 26 asthma management. Onset of asthma in his teens. He was hospitalized 27 twice last year, and already twice this year. He has not been able to 28 be weaned off steroids for the past several months. 29 </content> 30 </paragraph> 31 </section> 32 <section> 33 <caption>Past Medical History</caption> 34 <list> 35 <item><content>Asthma</content></item> 36 <item><content>Hypertension</content></item> 37 <item><content>Osteoarthritis, right knee</content></item> 38 </list> 39 </section> 40 <section> 41 <caption> 42 <caption_cd V="10160-0" S="2.16.840.1.113883.6.1"/>Medications 43 </caption> 44 <list> 45 <item><content>Theodur 200mg BID</content></item> 46 <item><content>Proventil inhaler 2puffs QID PRN</content></item> 47 <item><content>Prednisone 20mg qd</content></item> 48 <item><content>HCTZ 25mg qd</content></item> 49 </list> 50 </section> 51 <section> 52 <caption>Allergies</caption> 53 <list> 54 <item><content>Penicillin - Hives</content></item> 55 <item><content>Aspirin - Wheezing</content></item> 56 </list> 57 </section> 58 <section> 59 <caption>Social History</caption> 60 <list> 61 <item> 62 <content> 63 Smoking :: 1 PPD between the ages of 20 and 55, and then he quit. 64 </content> 65 </item>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 <item><content>Alcohol :: rare</content></item> 2 </list> 3 </section> 4 <section> 5 <caption> 6 <caption_cd V="11384-5" S="2.16.840.1.113883.6.1"/>Physical Examination 7 </caption> 8 <section> 9 <caption> 10 <caption_cd V="8716-3" S="2.16.840.1.113883.6.1"/>Vital Signs 11 </caption> 12 <list> 13 <item><content>BP 118/78</content></item> 14 <item><content>Resp 16 and unlabored</content></item> 15 <item><content>T 98.6F</content></item> 16 <item><content>HR 86 and regular</content></item> 17 </list> 18 </section> 19 <section> 20 <caption> 21 <caption_cd V="8709-8" S="2.16.840.1.113883.6.1"/>Skin 22 </caption> 23 <paragraph> 24 <content>Erythematous rash, palmar surface, left index finger. 25 <observation_media> 26 <observation_media.value MT="image/jpeg"> 27 <REF V="rash.jpeg"/> 28 </observation_media.value> 29 </observation_media> 30 </content> 31 </paragraph> 32 </section> 33 <section> 34 <caption> 35 <caption_cd V="11391-0" S="2.16.840.1.113883.6.1"/>Lungs 36 </caption> 37 <paragraph> 38 <content>Clear with no wheeze. Good air flow.</content> 39 </paragraph> 40 </section> 41 <section> 42 <caption>Cardiac</caption> 43 <paragraph> 44 <content>RRR with no murmur, no S3, no S4.</content> 45 </paragraph> 46 </section> 47 </section> 48 <section confidentiality="CONF2"> 49 <caption> 50 <caption_cd V="11502-2" S="2.16.840.1.113883.6.1"/>Labs 51 </caption> 52 <list> 53 <item> 54 <content> 55 CXR 02/03/1999: Hyperinflated. Normal cardiac silhouette, clear lungs. 56 </content> 57 </item> 58 <item originator="DEV1"><content>Peak Flow today: 260 l/m</content></item> 59 </list> 60 </section> 61 <section> 62 <caption> 63 <caption_cd V="11496-7" S="2.16.840.1.113883.6.1"/>Assessment 64 </caption> 65 <list> 66 <item> 67 <content> 68 <content ID="String001">Asthma</content>, with prior smoking 69 history. Difficulty weaning off steroids. Will try gradual taper. 70 <coded_entry> 71 <coded_entry.value ORIGTXT="String001" 1Health Level Seven, © 2000. All rights reserved 80 2Membership Ballot August 2000 1 V="D2-51000" S="2.16.840.1.113883.6.5"/> 2 </coded_entry> 3 </content> 4 </item> 5 <item><content>Hypertension, well-controlled.</content></item> 6 <item><content>Contact dermatitis on finger.</content></item> 7 </list> 8 </section> 9 <section> 10 <caption> 11 <caption_cd V="1234-X" S="2.16.840.1.113883.6.1"/>Plan 12 </caption> 13 <list> 14 <item><content>Complete PFTs with lung volumes.</content></item> 15 <item><content>Chem-7</content></item> 16 <item> 17 <content> 18 Provide educational material on inhaler usage and peak flow self-monitoring. 19 </content> 20 </item> 21 <item> 22 <content>Decrease prednisone to 20qOD alternating with 18qOD.</content> 23 </item> 24 <item><content>Hydrocortisone cream to finger BID.</content></item> 25 <item><content>RTC 1 week.</content></item> 26 </list> 27 </section> 28 </body> 29</levelone> 301Health 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<?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'20select='/levelone/clinical_document_header/originating_organization/organization/organiza 21tion.nm/@V'/> 23<xsl:variable name='title'> 24 <xsl:value-of select='$orgName'/> 25 <xsl:text> </xsl:text> 26 <xsl:value-of select='$docType'/> 27</xsl:variable> 28 29<xsl:template match='/levelone'> 30 <html> 31 <head> 32 <meta name='Generator' content='&CDA-Stylesheet;'/> 33 <xsl:comment> 34 do NOT edit this HTML directly, it was generated 35 via an XSLT transformation from the original Level 1 36 document. 37 </xsl:comment> 38 <style> 39 <xsl:comment> 40 body {background-color: white; color: black; } 41  43  44 p { margin: 10px 0 10px 0.25in; } 45 div.caption { font-weight: bold; text-decoration: 46underline; } 47 span.caption { font-weight: bold; } 48 div.title { font-size: 18pt; font-weight: bold } 49 div.demographics { text-align: center ; } 50 </xsl:comment> 51 </style> 52 53 <title> 54 <xsl:value-of select='$title'/> 55 </title> 56 </head> 57 <body> 58 <div class='title'> 59 <xsl:value-of select='$title'/> 60 </div> 61 62 <xsl:apply-templates select='clinical_document_header'/> 63 64 <xsl:apply-templates select='body'/> 65 <xsl:call-template name='signature'/> 66 </body> 67 </html> 68</xsl:template> 1Health Level Seven, © 2000. All rights reserved 82 2Membership Ballot August 2000 1 2 20<xsl:template match='clinical_document_header'> 21 <div class='demographics'> 22 <table border='0'> 23 <tbody> 24 <xsl:call-template name='encounter'/> 25 <xsl:call-template name='patient'/> 26 </tbody> 27 </table> 28 </div> 29</xsl:template> 30 31<xsl:template name='encounter'> 32 <tr> 33 <xsl:apply-templates select='provider'/> 34 </tr> 35 <tr> 36 <xsl:apply-templates select='patient_encounter/encounter_tmr'/> 37 </tr> 38</xsl:template> 39 40<xsl:template match='encounter_tmr'> 41 <th align='left' width='16.67%'>Date:</th> 42 <td align='left' width='16.67%'> 43 <xsl:call-template name='date'> 44 <xsl:with-param name='date' select='@V'/> 45 </xsl:call-template> 46 </td> 47</xsl:template> 48 49<xsl:template match='provider'> 50 <th align='left' width='16.67%'> 51 <xsl:call-template name='provider_type_cd'> 52 <xsl:with-param name='type_cd' select='provider.type_cd/@V'/> 53 </xsl:call-template> 54 <xsl:text>:</xsl:text> 55 </th> 56 <td align='left' width='16.67%'> 57 <xsl:variable name='ptr' select='person/id/@EX'/> 58 59 <xsl:for-each 60select='/levelone/clinical_document_header/originator/person[id/@EX=$ptr]'> 61 <xsl:call-template name='getName'/> 62 </xsl:for-each> 63 </td> 64</xsl:template> 65 66<xsl:template name='patient'> 67 <tr> 68 <xsl:apply-templates select='patient'/> 69 </tr> 70 71 <tr> 1Health Level Seven, © 2000. All rights reserved 83 2Membership Ballot August 2000 1 <xsl:apply-templates select='patient/birth_dttm'/> 2 </tr> 3</xsl:template> 4 5<xsl:template match='birth_dttm'> 6 <th align='left' width='16.67%'>Birthdate:</th> 7 <td align='left' width='16.67%'> 8 <xsl:call-template name='date'> 9 <xsl:with-param name='date' select='@V'/> 10 </xsl:call-template> 11 </td> 12</xsl:template> 13 14<xsl:template match='patient'> 15 <th align='left' width='16.67%'>Patient:</th> 16 <td align='left' width='16.67%'> 17 <xsl:for-each select='person'> 18 <xsl:call-template name='getName'/> 19 </xsl:for-each> 20 </td> 21 <th align='right' width='16.67%'> 22 <xsl:text>MRN:</xsl:text> 23 </th> 24 <td align='left' width='16.67%'> 25 <xsl:value-of select='person/id/@EX'/> 26 </td> 27 <th align='right' width='16.66%'>Sex:</th> 28 <td align='left' width='16.66%'> 29 <xsl:call-template name='administrative_gender_cd'> 30 <xsl:with-param name='gender_cd' 31select='administrative_gender_cd/@V'/> 32 </xsl:call-template> 33 </td> 34</xsl:template> 35 36 39<xsl:template match='body|caption|content'> 40 <xsl:apply-templates/> 41</xsl:template> 42 43 48<xsl:template match='section'> 49 <div> 50 <div class='caption'> 51 <xsl:apply-templates select='caption'/> 52 </div> 53 <xsl:apply-templates select='paragraph|list|table|section'/> 54 </div> 55</xsl:template> 56 57<xsl:template match='section/section'> 58 <ul> 59 <li> 60 61 <xsl:apply-templates select='caption'/> 62 <xsl:text> :: </xsl:text> 63 64 <xsl:apply-templates select='paragraph|list|table|section'/> 65 </li> 66 </ul> 67</xsl:template> 68 69 4<xsl:template match='paragraph'> 5 6 <xsl:apply-templates select='content'/> 7 8</xsl:template> 9 10 14<xsl:template match='list'> 15 <ul> 16 <xsl:for-each select='item'> 17 <li> 18 <xsl:if test='caption'> 19 <xsl:apply-templates select='caption'/> 20 <xsl:text> :: </xsl:text> 21 </xsl:if> 22 <xsl:apply-templates select='content'/> 23 </li> 24 </xsl:for-each> 25 </ul> 26</xsl:template> 27 28 32<xsl:template match='section/section/list'> 33 <xsl:for-each select='item'> 34 <xsl:apply-templates select='content'/> 35 <xsl:if test='position()!=last()'> 36 <xsl:text>; </xsl:text> 37 </xsl:if> 38 </xsl:for-each> 39</xsl:template> 40 41<xsl:template match='section/section/paragraph'> 42 43 <xsl:apply-templates/> 44 45</xsl:template> 46 47 54<xsl:template match='table|table/caption|thead|tfoot|tbody|colgroup|col|tr|th|td'> 55 <xsl:copy> 56 <xsl:apply-templates select='*|@*|text()'/> 57 </xsl:copy> 58</xsl:template> 59<xsl:template match='table/@*|thead/@*|tfoot/@*|tbody/@*|colgroup/@*|col/@*|tr/@*|th/@*| 60td/@*'> 61 <xsl:copy> 62 <xsl:apply-templates/> 63 </xsl:copy> 64</xsl:template> 65 66 1Health Level Seven, © 2000. All rights reserved 85 2Membership Ballot August 2000 1<xsl:template match='observation_media'> 2 <xsl:if test='observation_media.value[ 3 @MT="image/gif" or @MT="image/jpeg" 4 ]'> 5 6 <xsl:element name='img'> 7 <xsl:attribute name='src'> 8 <xsl:value-of select='observation_media.value/REF/@V'/> 9 </xsl:attribute> 10 </xsl:element> 11 </xsl:if> 12</xsl:template> 13 14 19<xsl:template match='link'> 20 <xsl:element name='a'> 21 <xsl:for-each select='link_html/@*'> 22 <xsl:if test='not(name()="originator" or 23name()="confidentiality")'> 24 <xsl:attribute name='{name()}'> 25 <xsl:value-of select='.'/> 26 </xsl:attribute> 27 </xsl:if> 28 </xsl:for-each> 29 <xsl:value-of select='link_html'/> 30 </xsl:element> 31</xsl:template> 32 33 42 51<xsl:template match='@ignore'> 52 <xsl:choose> 53 <xsl:when test='.="markup"'> 54 <xsl:apply-templates select='../text()'/> 55 </xsl:when> 56 </xsl:choose> 57</xsl:template> 58 59 62<xsl:template match='coded_entry'> 63</xsl:template> 64 65<xsl:template match='caption_cd'> 66</xsl:template> 67 68 69 3<xsl:template name='signature'> 4 <xsl:variable name='signers' 5select='/levelone/clinical_document_header/legal_authenticator/person'/> 6 <xsl:if test='$signers'> 7 <div> 8 Signed by: 9 <xsl:for-each select='$signers'> 10 <xsl:call-template name='getName'> 11 <xsl:with-param name='person' select='.'/> 12 </xsl:call-template> 13 <xsl:text> on </xsl:text> 14 <xsl:call-template name='date'> 15 <xsl:with-param name='date' 16select='../participation_tmr/@V'/> 17 </xsl:call-template> 18 </xsl:for-each> 19 </div> 20 </xsl:if> 21</xsl:template> 22 23 26 32<xsl:template name='getName'> 33 <xsl:apply-templates select='person_name[person_name.type_cd/@V="L"]'/> 34</xsl:template> 35<xsl:template match='person_name'> 36 <xsl:choose> 37 <xsl:when test='nm/GIV[@QUAL="RE"]/@V'> 38 <xsl:value-of select='nm/GIV[@QUAL="RE"]/@V'/> 39 </xsl:when> 40 <xsl:when test='nm/GIV[@CLAS="N"]/@V'> 41 <xsl:value-of select='nm/GIV[@CLAS="N"]/@V'/> 42 </xsl:when> 43 <xsl:otherwise> 44 <xsl:value-of select='nm/GIV/@V'/> 45 </xsl:otherwise> 46 </xsl:choose> 47 <xsl:text> </xsl:text> 48 <xsl:choose> 49 <xsl:when test='nm/FAM[@QUAL="RE"]/@V'> 50 <xsl:value-of select='nm/FAM[@QUAL="RE"]/@V'/> 51 </xsl:when> 52 <xsl:otherwise> 53 <xsl:value-of select='nm/FAM/@V'/> 54 </xsl:otherwise> 55 </xsl:choose> 56 <xsl:choose> 57 <xsl:when test='nm/SFX[@QUAL="RE"]/@V'> 58 <xsl:text>, </xsl:text> 59 <xsl:value-of select='nm/SFX[@QUAL="RE"]/@V'/> 60 </xsl:when> 61 <xsl:when test='nm/SFX/@V'> 62 <xsl:text>, </xsl:text> 63 <xsl:value-of select='nm/SFX/@V'/> 64 </xsl:when> 65 </xsl:choose> 66</xsl:template> 67 68 2<xsl:template name='date'> 3 <xsl:param name='date'/> 4 <xsl:variable name='month' select='substring ($date, 6, 2)'/> 5 <xsl:choose> 6 <xsl:when test='$month=01'> 7 <xsl:text>January </xsl:text> 8 </xsl:when> 9 <xsl:when test='$month=02'> 10 <xsl:text>February </xsl:text> 11 </xsl:when> 12 <xsl:when test='$month=03'> 13 <xsl:text>March </xsl:text> 14 </xsl:when> 15 <xsl:when test='$month=04'> 16 <xsl:text>April </xsl:text> 17 </xsl:when> 18 <xsl:when test='$month=05'> 19 <xsl:text>May </xsl:text> 20 </xsl:when> 21 <xsl:when test='$month=06'> 22 <xsl:text>June </xsl:text> 23 </xsl:when> 24 <xsl:when test='$month=07'> 25 <xsl:text>July </xsl:text> 26 </xsl:when> 27 <xsl:when test='$month=08'> 28 <xsl:text>August </xsl:text> 29 </xsl:when> 30 <xsl:when test='$month=09'> 31 <xsl:text>September </xsl:text> 32 </xsl:when> 33 <xsl:when test='$month=10'> 34 <xsl:text>October </xsl:text> 35 </xsl:when> 36 <xsl:when test='$month=11'> 37 <xsl:text>November </xsl:text> 38 </xsl:when> 39 <xsl:when test='$month=12'> 40 <xsl:text>December </xsl:text> 41 </xsl:when> 42 </xsl:choose> 43 <xsl:choose> 44 <xsl:when test='substring ($date, 9, 1)="0"'> 45 <xsl:value-of select='substring ($date, 10, 1)'/><xsl:text>, 46</xsl:text> 47 </xsl:when> 48 <xsl:otherwise> 49 <xsl:value-of select='substring ($date, 9, 2)'/><xsl:text>, 50</xsl:text> 51 </xsl:otherwise> 52 </xsl:choose> 53 <xsl:value-of select='substring ($date, 1, 4)'/> 54</xsl:template> 55 56 59<xsl:template name='provider_type_cd'> 60 <xsl:param name='type_cd'/> 61 <xsl:choose> 62 <xsl:when test='$type_cd="CON"'> 63 <xsl:text>Consultant</xsl:text> 64 </xsl:when> 65 <xsl:when test='$type_cd="PRISURG"'> 66 <xsl:text>Primary surgeon</xsl:text> 67 </xsl:when> 68 <xsl:when test='$type_cd="FASST"'> 69 <xsl:text>First assistant</xsl:text> 70 </xsl:when> 71 <xsl:when test='$type_cd="SASST"'> 1Health Level Seven, © 2000. All rights reserved 88 2Membership Ballot August 2000 1 <xsl:text>Second assistant</xsl:text> 2 </xsl:when> 3 <xsl:when test='$type_cd="SNRS"'> 4 <xsl:text>Scrub nurse</xsl:text> 5 </xsl:when> 6 <xsl:when test='$type_cd="TASST"'> 7 <xsl:text>Third assistant</xsl:text> 8 </xsl:when> 9 <xsl:when test='$type_cd="NASST"'> 10 <xsl:text>Nurse assistant</xsl:text> 11 </xsl:when> 12 <xsl:when test='$type_cd="ANEST"'> 13 <xsl:text>Anesthetist</xsl:text> 14 </xsl:when> 15 <xsl:when test='$type_cd="ANRS"'> 16 <xsl:text>Anesthesia nurse</xsl:text> 17 </xsl:when> 18 <xsl:when test='$type_cd="MDWF"'> 19 <xsl:text>Midwife</xsl:text> 20 </xsl:when> 21 <xsl:when test='$type_cd="ATTPHYS"'> 22 <xsl:text>Attending physician</xsl:text> 23 </xsl:when> 24 <xsl:when test='$type_cd="ADMPHYS"'> 25 <xsl:text>Admitting physician</xsl:text> 26 </xsl:when> 27 <xsl:when test='$type_cd="DISPHYS"'> 28 <xsl:text>Discharging physician</xsl:text> 29 </xsl:when> 30 <xsl:when test='$type_cd="RNDPHYS"'> 31 <xsl:text>Rounding physician</xsl:text> 32 </xsl:when> 33 <xsl:when test='$type_cd="PCP"'> 34 <xsl:text>Primary care provider</xsl:text> 35 </xsl:when> 36 <xsl:otherwise> 37 <xsl:value-of select='$type_cd'/> 38 </xsl:otherwise> 39 </xsl:choose> 40</xsl:template> 41 42<xsl:template name='administrative_gender_cd'> 43 <xsl:param name='gender_cd'/> 44 <xsl:choose> 45 <xsl:when test='$gender_cd="M"'> 46 <xsl:text>Male</xsl:text> 47 </xsl:when> 48 <xsl:when test='$gender_cd="F"'> 49 <xsl:text>Female</xsl:text> 50 </xsl:when> 51 <xsl:otherwise> 52 <xsl:value-of select='$gender_cd'/> 53 </xsl:otherwise> 54 </xsl:choose> 55</xsl:template> 56 57</xsl:stylesheet>1Health Level Seven, © 2000. All rights reserved 89 2Membership Ballot August 2000 15.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 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 32Dolin, MD</td> 33</tr> 34<tr> 35<th align="left" width="16.67%">Date:</th><td align="left" width="16.67%">April 7, 362000</td> 37</tr> 38<tr> 39<th align="left" width="16.67%">Patient:</th><td align="left" width="16.67%">Henry Levin, 40the 7th</td><th align="right" width="16.67%">MRN:</th><td align="left" 41width="16.67%">12345</td><th align="right" width="16.66%">Sex:</th><td align="left" 42width="16.66%">Male</td> 43</tr> 44<tr> 45<th align="left" width="16.67%">Birthdate:</th><td align="left" width="16.67%">September 4624, 1932</td> 47</tr> 48</tbody> 49</table> 50</div> 51 52 <div> 53<div class="caption"> 54 55 History of Present Illness 56 </div> 57 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 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> 1Health Level Seven, © 2000. All rights reserved 90 2Membership Ballot August 2000 1</ul> 2</div> 3 <div> 4<div class="caption"> 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> 25 Smoking :: 1 PPD between the ages of 20 and 55, and then he quit. 26 </li> 27<li>Alcohol :: rare</li> 28</ul> 29</div> 30 <div> 31<div class="caption"> 32 Physical Examination 33 </div> 34<ul> 35<li> 36 37 Vital Signs 38 :: BP 118/78; Resp 16 and unlabored; T 98.6F; HR 86 and regular</li> 39</ul> 40<ul> 41<li> 42 43 Skin 44 :: 45 Erythematous rash, palmar surface, left index finger. 46 47 48 49 50</li> 51</ul> 52<ul> 53<li> 54 55 Lungs 56 :: 57 Clear with no wheeze. Good air flow. 58 59</li> 60</ul> 61<ul> 62<li> 63Cardiac :: 64 RRR with no murmur, no S3, no S4. 65 66</li> 67</ul> 68</div> 69 <div> 70<div class="caption"> 71 Labs 1Health Level Seven, © 2000. All rights reserved 91 2Membership Ballot August 2000 1 </div> 2<ul> 3<li> 4 CXR 02/03/1999: Hyperinflated. Normal cardiac silhouette, clear lungs. 5 </li> 6<li>Peak Flow today: 260 l/m</li> 7</ul> 8</div> 9 <div> 10<div class="caption"> 11 Assessment 12 </div> 13<ul> 14<li> 15 Asthma, with prior smoking 16 history. Difficulty weaning off steroids. Will try gradual taper. 17 18 </li> 19<li>Hypertension, well-controlled.</li> 20<li>Contact dermatitis on finger.</li> 21</ul> 22</div> 23 <div> 24<div class="caption"> 25 Plan 26 </div> 27<ul> 28<li>Complete PFTs with lung volumes.</li> 29<li>Chem-7</li> 30<li> 31 Provide educational material on inhaler usage and peak flow self-monitoring. 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> 39Signed by:Robert Dolin, MD on April 8, 2000</div> 40</body> 41</html>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 : CD0..* 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 <local_header> element to the end of every 13XML content model. Likewise, a <local_markup> element is added to the end of every XML content 14model within the CDA Level One Body.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. <dob> <name> vs. <person_name> <person.birth_dttm>). The source DTD may be missing a required 39element (e.g. CDA DTD requires <clinical_document_header.id>). The source and CDA DTDs may have 40different 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 43DTD (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 45transformation issues arise when the source's information model of the real world differs from the RIM. 46 47It is likely to be the case that transformation issues will be minimized to the extent that the CDA 48specifications and the underlying RIM are unambiguous. The CDA specification for use of local markup in 49the header (see 3.2.2.6 Localization) and in the body (see 3.3.2.4.6 Localization) can be used when local 50semantics have no corresponding representation in the CDA specification.1Health Level Seven, © 2000. All rights reserved 96 2Membership Ballot August 2000 15.3.5 Representing authenticated content 2The following describes the responsibility of the CDA for representing authenticated content. This position 3may be extended with the availability of further standards for digital signature, XML formatting and 4specific formatting standards for clinical documents. 5 6Observations: 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 20Presentation 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 29Presentation 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. 28 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. 46128 An argument could be made that CSS does meet these criteria, but only on screen, not in print. XSLT has 2large market acceptance and is an open standard (W3C Recommendation) but an XSLT “stylesheet” as 3implemented today always has an application and time-bound target syntax, such as a version/flavor of 4HTML or rtf, that does not meet our requirements. Full blown XSL, that is, XSLT plus XSL formatting 5objects, would meet our criteria, but this is not yet a standard and has not yet been implemented. DSSSL 6does meet all our criteria save market acceptance. 7Health Level Seven, © 2000. All rights reserved 97 8Membership Ballot August 2000 15.4 References 2 3Health 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 RIM data type specifications (DTD, abstract specification) 9 10World 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 24Other 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 37Other 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.1Health Level Seven, © 2000. All rights reserved 98 2Membership Ballot August 2000 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 14155.5 Acknowledgements 16 17In addition to those listed at the top of this document, the following people and committees have 18contributed to the development of this architecture: 19 20Carl Adler, Fred Behlen, Dean Bidgood, Carol Broverman, Hans Buitendijk, Ron Capwell, John Carter, 21Michal Coleman, Don Connelly, Gary Dickinson, Steve Doubleday, Joachim Dudeck, Dan Essin, Jasen 22Fici, Al Figler, Leo Fogarty, Gerard Freriks, Lloyd Harding, Richard Harding, Michael Henderson, Juggy 23Jagannathan, Ed Jones, Eliot Kimber, Tom Lincoln, John Majerus, David Markwell, John Mattison, Bob 24Moe, Wes Rishel, Angelo Rossi-Mori, Gunther Schadow, Anil Sethi, Anne Shanney, John Spinosa, 25Michael Toback, Wayne Tracy, Jason Williams. 26 27We'd also like to point out the need for a close working relationship between various committees in 28ensuring the harmony of the various work products generated by HL7. In particular, we gratefully 29acknowledge the contributions and domain expertise of the Medical Records / Information Management 30Technical Committee and the Orders & Observation Technical Committee. 31 321Health Level Seven, © 2000. All rights reserved 99 2Membership Ballot August 2000

Clinical Document Architecture Framework

Details

Download

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

Support