Keith
P.S. The CDA book is now available for pre-order from Amazon!
Organization of the CDA Book
The CDA standard builds upon the HL7 Version 3 stack of standards. In the lowest layer of that stack are standards on vocabulary and data types. On top of those is the HL7 Reference Information Model.
This book is organized into 4 major sections. The Introduction describes clinical documents in general, and provides a brief history and overview of the CDA standard. The Data Types section covers each of the data types used by the CDA standard in detail. The Modeling section reviews the HL7 Reference Information Model and its application to the CDA Standard. Finally, the Implementation section covers creation, display, validation of CDA documents and reviews key features of a number of implementation guides that use the CDA standard.
A brief overview of each of the sections and the chapters in those sections should help you to find what you need.
Section I: Introduction
Chapter 1 Clinical Documentation
This chapter describes the four C's; key properties of clinical documents and from them derives the six key characteristics use in the CDA standard.
Chapter 2 The HL7 Clinical Document Architecture
This chapter provides a brief history of the CDA standard, describes the overall structure of a CDA document, and explains how the standard provides for incremental levels of interoperability.
Chapter 3 Extensible Markup Language
XML is standard for producing structured content similar to what appears in HTML. This chapter provides a brief overview of XML, elements, attributes, the XML declaration, namespaces, XML Schema, parsing technology, and character sets.
Key Terms in the Introduction Section
Clinical Document – A clinical document is typically produced by a clinician and documents clinical observations and services provided to a patient or subject of care.
CDA Document – A CDA document is a clinical document stored in the CDA format. All CDA Documents are clinical documents, but not all clinical documents are CDA documents.
Digital Signature – A digital signature is a collection of data produced by a cryptographic algorithm that can be used as proof that an entity authorized the signature of an electronic document. Note that the US is one of the few countries that allow for both electronic and digital signatures in its laws and regulation. Most other countries with policies on the use of electronic signatures for commerce require the use of digital signatures.
Electronic Signature – In the United States, an electronic signature is defined as “an electronic sound, symbol, or process, attached to or logically associated with a contract or other record and executed or adopted by a person with the intent to sign the record.” [1]
Medical Record – A patient’s medical record is the collection of documentation used and maintained by a healthcare provider organization to document the care provided to that patient. It is also known as the patient chart.
Semantic Interoperability – The IEEE defines interoperability [2] as “the ability of two or more systems or components to exchange information and to use the information that has been exchanged.” Semantic interoperability is focused on the ability to use and understand the information that has been exchanged.
Section II: Data Types
The most basic components to agree upon in communication are the data types to exchange. The data types used in the CDA standard are defined by the HL7 Version 3 Data Types - Abstract Specification. That specification is described as an abstract specification because it defines the properties, semantics and operations that can be performed on the data types rather than their concrete, computational representations.
The representation of these data types in XML is described in more detail by the XML Implementation Technology Specification included with the CDA Release 2.0 normative edition. This specification makes the implementation of these data types more concrete, and indicates how the information is to be transmitted.
The hierarchy of HL7 Version 3 data types is shown below in Figure 4, along with the subdivisions of this section in which they are covered.
Figure 4 HL7 Version 3 Data Type Hierarchy
The most important features of commonly encountered data types used in CDA documents are covered in this chapter. More detail can be found in the HL7 Data Types specification. This section is divided into six chapters describing each of the groups of data types shown above.
Chapter 4 Basic Data Types
This chapter covers the ANY data type and simply valued types including Boolean and numeric quantities. Included in this chapter is a discussion of what HL7 calls flavors of null, which represent the many different reasons why a value is not known.
Chapter 5 Text and Multimedia
This chapter describes how simple strings, text, images and other multimedia content are incorporated into a CDA document using the String (ST) and Encapsulated Data (ED) types. The ED data type supports representation of any kind of multimedia content that has a MIME type associated with it.
Chapter 6 Demographic Data
Demographic data is one of the first things gathered about patients. The eight different data types HL7 uses to support demographic data, including identifiers, names, addresses, telephone numbers and other communication addresses are explained in this chapter.
Chapter 7 Codes and Vocabularies
This chapter introduces the terms used to describe things in HL7 Version 3. It defines key terms such as Concept, Code, Coding System, and Value Set, and explains the difference between pre- and post-coordination. This chapter is an introduces material necessary to understand the following chapter on data types used for codes.
Chapter 8 Codes
Codes represent a concept, or idea. This chapter describe the CD data type and its simpler variants that are used to described codes in the HL7 Version 3 standards.
Chapter 9 Dates and Times
Time is the essence of this chapter. It describes the data types used to capture not just points in time, but intervals over time, and ways to express the timing events that recur periodically. Time is especially important with medications. This chapter shows how to represent the most common medication regimens in the CDA XML.
Chapter 10 Collections
Collections in HL7 are abstract types that can be used to create bags, lists or sets of any data type. This chapter explains what these different types are, and how they work with the HL7 data types representing codes and quantities.
Section III: CDA Modeling
This describes HL7 Modeling and how it is applied to the Clinical Document Architecture. Then it goes on to describe the CDA models for the three different levels of CDA content.
Chapter 11 HL7 Version 3 Modeling
This chapter describes that "language" of HL7 version 3, starting from the essential six RIM backbone classes of HL7 Version 3 which make up clinical statements. It explains the meaning of "mood" as used in HL7 modeling, and how negation works in a clinical statement. Along the way you will learn how HL7 model diagrams are interpreted as UML models, and to interpret the normative reprentations of the CDA standard.
Chapter 12 Clinical Document Infrastructure
This chapter describes the HL7 model for CDA and discusses features of the XML ITS that are used to generate the CDA XML from this model.
Chapter 13 The CDA Header
Every clinical document has a context that describes the patient, the document author, the related encounter and metadata about the content of the document itself. This chapter describes the RIM classes and XML representations of the CDA header that sets the context for the rest of the CDA document.
Chapter 14 The CDA Body
The CDA body represents the human readable content. In the simplest form of CDA, this is just a file created using traditional documenting tools. But CDA also has a standard format used to encode the narrative. This chapter describes how both of these formats are included in a CDA document, and when the latter form is used, how it can be displayed in a browser using an XSLT transform.
Chapter 15 Clinical Statements in the CDA
The HL7 CDA standard "invented" the notion of a model for clinical statements. This chapter explains what the components of clinical statements are, and how they can be used to represent the machine readable entries in the CDA document.
Section IV: Implementing CDA
Native support for CDA in applications requires a good bit of restructuring, so the most common way to start generating CDA documents is based on existing application interfaces. These are most commonly implemented using HL7 Version 2 messages. The next step after generating CDA documents is being able to do more than display them. Applications need to be able access the content of CDA documents in meaningful ways.
To simplify application development, CDA can be constrained to support specific use cases. There are a number of techniques that have been used to constrain CDA, and all of these are based on the HL7 Templates DSTU. To support these implementations, application developers need to be able to ensure that the CDA content they receive is valid according to the constraints that have been applied.
A number of organizations, including HL7, IHE, the Continua Health Alliance, the European Smart Open Systems and ANSI/HITSP have created implementation guides using the techniques described previously. The author has been engaged with each of these activities.
Chapter 16 HL7 Version 2 to CDA Release 2
The first place many organizations start when using the CDA standard is creating a CDA document from an existing HL7 Version 2 message. This chapter describes how you can do that for three different types of HL7 Version 2 message most commonly converted into a CDA document.
Chapter 17 Extracting Data from a CDA Document
A document is only useful if it is read. This brief chapter describes a few tools that you can use to "read" the clinical information contained within CDA document. It also explains a technique to access context information associated with a clinical statement using XSLT, which is of the more common information extraction tools.
Chapter 18 Templates
There are more than 100 CDA implementation guides, and more than 500 definitions of CDA components, called templates, that have been defined by these guides. This chapter explains what templates are, the different types, and how they are built. It also explains the meaning of some of the terms used for asserting conformance to a template. Finally, it explains how you can extend CDA to meet requirements that it does not directly support.
Chapter 19 Validating the Content of a CDA Document
This chapter demonstates some techniques that can be used to ensure that the CDA documents your applications are receiving conform to the rules being defined in CDA templates. It covers four different techniques to validate content, and includes a discussion on validating narrative.
Chapter 20 Implementation Guides on CDA
Work on implementation guides began on CDA Release 2.0 before the ink was even dry on the standard. This chapter explores the history of several important CDA implementation guides. It describes key features of these guides, and shows how the guides have influenced each other over the years.
Chapter 21 is for you to write.
References
[1] Electronic Signatures in Global and National Commerce Act. 15 USC 7001, June 30, 2006. Available on the web at http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?%20%20dbname=106_cong_public_laws&docid=f:publ229.106.pdf
[2] Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990.
Thanks for post.
ReplyDeleteThanks !
ReplyDeleteI am working on an NHIN project and I am in need of a CDA book now - will this book come out soon - early May perhaps? In the meantime - can you recommend another book on CDA?
ReplyDeleteThank you.
thank
ReplyDeleteYou said that the book will be available in print and in an electronic edition from Springer in the first half of this year.Its last quarter of the year so I would love to read about reader's response I think it might be best.
ReplyDeleteWhere can I get the realm codes? I cannot find any values (besides 'US') in your book. Thanks.
ReplyDeleteBrian Reinhold
Realm codes use ISO 2-character abbreviations for the nations in which there is a realm governing authority (e.g., an HL7 Affiliate). There are a few other realms outside that code set, but the only one you'll encounter in practice is the Universal Realm (UV).
Delete