1. Care Coordination and Interoperable Health IT Systems
Unit 5: Standards for Interoperable Health IT
Lecture d – Introduction to HL7 CDA®
Welcome to Care Coordination and Interoperable Health IT Systems, Standards for Interoperable Health IT, Lecture d.
This material (Comp 22 Unit 5) was developed by Columbia University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number 90WT0004.
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. To view a copy of this license, visit

2. Standards for Interoperable Health IT Learning Objectives
Objective 1: Explain why standards are required, how they are developed, and how adoption is encouraged (Lecture a)
Objective 2: Name and describe the types of interoperability standards available (Lecture b)
Objective 3: Summarize functionality of HL7 V2®, CDA®/CCDA, and FHIR® (Lectures c, d, and e)
Objective 4: Recognize HL7 V2® messages, CDA® documents, and FHIR® resources (Lectures c, d, and e)
This unit will cover the following learning objectives: 1) explain why standards are required, how they are developed, and how adoption is encouraged; 2) name and describe the types of interoperability standards available; 3) summarize functionality of HL7 V2®, CDA®/CCDA, and FHIR®; and 4) recognize HL7 V2® messages, CDA® documents, and FHIR® resources. This lecture will focus on HL7 CDA® and CCDA documents.

3. HL7 Version 3
HL7 Version 2® had great variances in implementation since it was not fully specified
HL7 created a new Version, Version 3, to improve semantic interoperability
It encoded all of its objects in XML instead of using V2® delimiters
All objects were based on a common information model called the Reference Information Model (RIM)
Two object types defined
Messages
Documents
HL7 version 3 was developed because of problems with HL7 version 2®. HL7 version 2® had great variance in implementation since it was not fully specified. With Version 3, HL7 tried to be much more precise to reduce variances between implementations. All V3 messages and documents were derived from a single information model to ensure a base consistency across the standard. This information model is called the Reference Information Model, or RIM. HL7 also encoded all V3 objects using XML or extended markup language, a popular encoding language for the web. This was considered more modern and generic than the HL7 specific encoding process of Version 2®. There were industry tools available to process XML formats. There were two object types that were defined for version 3 – Messages and Documents. The V3 Messages were similar in functionality to the V2® messages. V3 documents satisfied an outstanding need for which no standard yet existed – the need to provide a structured format to clinical documents.
Health IT Workforce Curriculum Version 4.0

4. HL7 Version 3 Reference Information Model (RIM)
This is a picture of the HL7 version 3’s Reference Information Model. Each box represents a class and contains attributes. The lines between classes signify their relationship to each other. The premise in the RIM is that the universe of health care is the divided into acts and roles. For example, an encounter is an act, an order is an act, and a medication administration is an act. People or entities play roles that relate to the act. For example, doctors order orders, patients are admitted to a hospital encounter, and nurses administer medications. Other entities would include medications and the patient’s location. Amazingly, HL7 was able to fit all of the information needed for health care interoperability on a single page.
5.18 Figure (HL7 Version 3 Interoperability Standards, Normative Edition, 2012)
Health IT Workforce Curriculum Version 4.0

5. HL7 Version 3 adoption V3 messaging had limited adoption in the U.S.
No motivation to move off V2®
V3 was harder to implement
No good tools or examples to help with the transition
However, V3 documents have been successful worldwide
The most notable document type is the Clinical Document Architecture (CDA)
HL7 version 3 messaging was somewhat successful outside the United States. However, it had limited adoption in United States. So, why was adoption so low? The first thing is that version 2® messaging had already achieved widespread adoption. While every V2® implementation had variances and associated implementation costs, the industry did not feel a strong enough need to move past V2®. Putting in a brand new version was expensive and hard. That would mean all the vendors would have to adapt and they are very slow to adapt to version 3 because it was harder to implement. There was not a smooth conversion between version 2® and version 3. However, version 3 documents solved a problem that V2® did not solve. It provided a way to structure clinical documents. A Version 3 document type called the Clinical Document Architecture was created to represent any clinical statement about a patient. The United States government decided to require implementation of CDA for patient summaries and for quality measure e-submissions in their certified technology and use of them as part of Meaningful Use. The Clinical Document Architecture has achieved widespread success as a result.
Health IT Workforce Curriculum Version 4.0

6. HL7 Clinical Document Architecture (CDA)
Is a standard for document sharing
Facilitates document exchange and reuse
Represents any clinical statement about a patient or group of patients
Examples include:
Operative report
Discharge summary
Laboratory report
Quality measure report on a patient cohort
The HL7 clinical document architecture or CDA is a structured document based on that Reference Information Model previously discussed. It facilitates both document exchange and reuse. It represents any clinical statement about a patient or group of patients. Some examples include an operative report, a discharge summary, a laboratory report, and a quality report on a cohort of patients.

7. About the CDA Is an HL7 Structured Document, not a message
Does not include rules for transmission (unlike messages)
Can be combined with another standard, such as HL7 V2® messaging, IHE XDS, or NHIN Direct, so that it can be exchanged
The CDA is a structured document, not a message. Unlike messages, it does not include rules for transmission. Instead, it can become combined with another standard and that other standard can provide the rules for transmission. Examples of other standards that could be combined with CDA are: HL7 version ® messaging, IHE Cross-Domain Document Sharing or IHE XDS, and NHIN Direct.
Health IT Workforce Curriculum Version 4.0

8. The CDA structure CDA Header CDA Body
Contains metadata to allow the document to be indexed and managed
CDA Body
Any content that represented a signed document
Example types
Discharge summary
Operative report
Visit summary
Now, let’s talk more about the structure of a CDA document. Every CDA document has a header and a body. The header has metadata to allow the document to be indexed and exchanged. The body contains any content that could be represented as a signed document. However, the reason why that is important is because it is key to always think of these CDA documents as representing real clinical documents you would find in a patient’s chart. The body would contain the real payload of this CDA document because it is the actual content. An example of a body type would be a discharge summary, operative report, or visit summary.
Health IT Workforce Curriculum Version 4.0

9. eXtended Markup Language (XML): a primer
Used to format CDA documents
Is similar to HTML, which is used to create webpages
HTML is used to create webpages
HTML contains a small set of directive tags (called markup) for how to present the document for viewing
Has any number of tags that define the contained data
Let’s take a step back and give a basic, informal primer on XML to help you understand CDA documents, but I encourage you to do more research on XML because CDA documents are formatted using XML. XML is similar to HTML, which is used to make webpages. HTML contains a small set of directive tags called markup that indicate how to present the document for viewing. XML also has a number of tags that define the data. So XML tags define how the information visually should look on a screen, but also how the data is structured for electronic processing.
Health IT Workforce Curriculum Version 4.0

10. Example of XML <title> Shortest Story </title>
Tells you that “Shortest Story” is a title
Can be nested:
<book>
<title> Shortest Story </title><contents> In the beginning…the end </contents>
</book>
Here is an example of XML. Imagine we have information about a book and its title is “Short Story”. You may find tags surrounding the title and they are called an open tag and a closed tag. The end tag has a forward slash, then the word “title”. So when you look at the open-title tag then “short story” then close-title tag, this tells you that the item between title and slash title is the title and that it should be processed as a title. Tagging can also be then nested. For example, in between these tags for book, you will know this is going to be about a book and that a book has two parts to it, a title and contents.
Health IT Workforce Curriculum Version 4.0

11. CDA supports incremental interoperability
CDA has a special feature that allows incremental interoperability. You always need a header and a body. For the lowest level of interoperability, the body is not structured and could consist of anything – examples include a PDF file, a Microsoft Word document, or a scanned image file. A CDA document containing a PDF file is better than just have the PDF document because you have a header to index the PDF. You know what kind of document it is, when it was created, who created it, and you can start doing some useful things with the header because it has structured data. The next level of interoperability is where you would have that header and an XML body that has rendering directions so that it displays nicely on the screen. The body would be broken into one or more coded sections of text with rendering instructions. A block of text with rendering instructions is also called a Narrative Block. The structured document could have just one section or multiple sections. For example, a nursing SOAP note has four sections - a subjective section, objective section, assessment section, and a plan section. The whole purpose of the Narrative Blocks is to ensure that whoever receives the document can display it as a human-readable document. All they need is a web browser and the CDA XML style sheet. While these two levels help organize and share documents, they do not allow the receiver to process the documents electronically. That is done at the highest level of interoperability. The highest level includes an additional version of the body in structured form referred to as entries. For every data type that is in the document, like a SOAP note or discharge summary, it is possible to have a structured representation of it. The CDA Entry for Substance Administration is used to represent med lists and has structured fields for the medication name, code, dose, status, time, and more. CDA Entries utilize the Reference Information Model’s classes, attributes, and controlled vocabulary, such as LOINC, SNOMED, ICD, CPT, and others.
5.19 Figure (Lorenzi, V., 2016)
Health IT Workforce Curriculum Version 4.0

12. CDA represented as a model
Let’s take the same idea of the CDA that was previously presented, but use the information model that is published in the CDA specification. The graphic is small so you can download the CDA specification from HL7 for further detail. Imagine that in each box represents a class containing the fields in a CDA document. The group of classes on the left contain all the fields for the header. The classes in the middle and to the right contain all the fields in the body. The human readable part of the Body is in the middle, either nonXMLbody or XMLbody. If XML, it is called the Narrative Block. The fields needed to represent CDA data as structured and machine-processable are to the right and are called entries. If you would like to examine this information model more closely, download the CDA standard from It is called the CDA RMIM which standards for Clinical Document Architecture Refined Message Information Model. Let’s explore each part of the CDA in more depth.
5.20 Figure (HL7 Clinical Document Architecture, Release 2, Normative Edition, 2005)
Health IT Workforce Curriculum Version 4.0

13. CDA Header Meta – data about the document Who created the document
Who is the document about
When was the document created
Where was the document created
Etc.
The header on the CDA information model looks relatively big, but really what the header has is any metadata about the document such as, who created it, who is it about, when was it created, where was it created, etc.
Health IT Workforce Curriculum Version 4.0

14. CDA Body Is either nonXML or XML
Provides a human – readable representation of the document
If it is an XML body, it will contain XML encoded sections of text with rendering instructions referred to as the Narrative Block
Recall that the CDA Body is either nonXML or XML. It provides a human-readable representation of the document. If it’s an XML body, it will contain XML encoded sections of text with rendering instructions referred to as the Narrative Block. The narrative block provides for the rendering of a human-readable document.
Health IT Workforce Curriculum Version 4.0

15. CDA sample
Here is a sample of a CDA. On the left is the CDA for a consultation note as it is rendered for the screen for human readability. Notice the sections called history of present illness, past medical history, and medications. When you look at the XML for this on the right, you will see a lot of tags and the header information encoded. The patient’s name is divided into the given name, the family name, and the suffix. There is the administrative gender code and the birth date and time. Then, you will see the body of the document which is an XML body. It contains a series of sections. The first section is for the History of Present Illness. The section is a narrative block of text which is human-readable. Notice that it contains rendering instructions to bold the text and to make the “th” in “seventh” raised. If we scrolled further down in the document, we would find more sections with narrative blocks and also perhaps some entries which are machine-processable representations of the content.
5.21 Figure (Adapted from HL7 Clinical Document Architecture, Release 2, Normative Edition, 2005). CDA format.
5.22 Figure (Adapted from HL7 Clinical Document Architecture, Release 2, Normative Edition, 2005). XML format.

16. Another example of narrative block: medications
Let’s look at a narrative block on medications. One of the first things listed is the section code, which is a LOINC code. The LOINC code means “history of medication used”. Then, the XML tags in this narrative block give instructions to the processor to display the title as “Medications” and then a string of text for each medication as an ordered list of items. The tags of the title, text, list, item, and content all have to do with how the content looks on the screen. Then there is information written like a sentence, “Take acetaminophen 500 mg oral tablet every 8 hours for 10 days”. This is to make it readable on a screen, instead of having multiple fields for “acetaminophen”, “500”, “mg”, etc. for structured data.
5.23 Figure (HL7 Implementation Guide: S&I Framework Transitions of Care Companion Guide to Consolidated-CDA for Meaningful Use Stage 2, Release 1 – US Realm, 2013)
Health IT Workforce Curriculum Version 4.0

17. CDA Entry
Is a fully structured and machine –processable representation of an item on the CDA
Types include vital signs, laboratory and allergy observations, substance administrations, clinical procedures, etc.
If present, same data must also be in a narrative block
A CDA entry is a fully structured and machine-processable representation of an item on the CDA. Types of entries include vital signs, laboratory and allergy observations, substance administrations, clinical procedures, and others. CDA does not require entries. If information is represented in an entry, it must also be in the narrative block. It is important to note that in the CDA standard, the XML Body is optional so then the lowest level of interoperability applies. CDA Entries are also optional, so then the medium Level of interoperability applies. However, at the highest Level of interoperability where CDA Entries are used, the Narrative Blocks are still required. This is essential so that the ability for any browser to render the document for human review is maintained.
Health IT Workforce Curriculum Version 4.0

18. Example of Entry: substance administration
Recall in the narrative block example, one of the medications shown was fluoxetine. In that same CDA document, there was also a structured representation of it as shown in this excerpt of the CDA document. It shows the fluoxetine represented as a CDA Substance Administration entry. It contains a code to further define the particular medication. A status code tells if it is an active, inactive, or completed medication. You can also see the effective time which is when the medication was prescribed and the priority for this order. Other important pieces of information are where the medication should be injected, what is the dose quantity, and rate quantity. By inspecting the fields in the substance administration entry example above you can tell that the medication has RxNorm code and formal display name Fluoxetine 15 mg oral tablet. At the time of this document, the medication was an active medication for the patient from June 12, 2012 to December 12, 2012.
5.24 Figure (HL7 Implementation Guide: S&I Framework Transitions of Care Companion Guide to Consolidated-CDA for Meaningful Use Stage 2, Release 1 – US Realm, 2013)

19. Rendering, validating, translating…
All CDA documents must be renderable with a single standard style sheet called cda.xsl.
Many vendors will also provide a style sheet
All CDA documents are encoded in XML, which can be validated automatically using a validation tool (e.g. NIST CCDA Document Validators)
All CDA documents must be renderable with a single standard style sheet called cda.xsl. Many vendors will also provide their own style sheet. All CDA documents are coded in XML, which can be automatically validated using a validation tool. One example of a validation tool would be the NIST CCDA document validator.
Health IT Workforce Curriculum Version 4.0

20. Why CDA implementation guides are important
CDA is a framework for communication of any structured document that represents a clinical statement.
CDA is not constrained enough to represent specific use cases or document types.
Implementation Guides
provide fuller specification of requirements
reduce variance in implementations.
CDA provides a standard framework for communication of any structured document that represents a clinical statement. Since it is generic, it is not constrained enough to represent a specific document type or to ensure the highest levels of interoperability. Implementation Guides on top of CDA provide fuller specification of requirements and reduce variance in implementations.
Health IT Workforce Curriculum Version 4.0

21. The need for a patient summary
Patient – centered care
Providing patients their summaries
Care Coordination
Providing summaries to the next provider of care
Standard machine – processable summaries would support technology for patient engagement and care coordination
At the same time that CDA was beginning to be adopted, the country and the world were looking for ways to improve health care by moving towards patient-centered care and coordinated care. For both efforts, the ability for an electronically-generated structured patient summary was seen as a helpful health IT tool and a standard solution was needed for this purpose.
Health IT Workforce Curriculum Version 4.0

22. Evolution of the CCDA 5.25 Figure (Lorenzi, V., 2016)
To satisfy the need for a patient care summary, several HL7 implementation guides were created based on the CDA. However, ASTM created another standard called the Continuity of Care Record, or CCR, which was not based on CDA. It gained some popularity with small providers. HL7 and ASTM worked together to create a merger of the CDA and CCR concepts. They created an implementation guide for CDA that had all the requirements of the CCR. This implementation guide was called the Continuity of Care Document or CCD. Another implementation guide provided additional constraints. It was called HITSP C32. Additional implementation guides on top of CDA were also created, such as for discharge summaries, progress notes, and operative reports. Finally a group of people got together and decided that all of these different implementation guides represented a patient’s health story and needed to be consolidated into a single implementation guide called the Consolidated CDA. Meaningful Use Stage 2 and Stage 3 both use CCDA to support patient engagement and care coordination. The CCDA Companion Guide provides guidance on how to use CCDA for these purposes. The most important part of the CCDA for Care Transition and Patient Engagement is the CCD. Let’s explore it further.
5.25 Figure (Lorenzi, V., 2016)
Health IT Workforce Curriculum Version 4.0

23. Purpose of CCD section of CCDA
“Provides a means for one health care practitioner, system, or setting to aggregate all of the pertinent data about a patient and forward it to another practitioner, system, or setting to support the continuity of care”
“Primary use case for the CCD is to provide a snapshot in time containing the pertinent clinical, demographic, and administrative data for a specific patient”
(HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, DSTU Release 1.1 US Realm Draft Standard for Trial Use, 2012)
The CCD section of the CCDA specification explains that its purpose is to “provide a means for one health care practitioner, system, or setting to aggregate all of the pertinent data about a patient and forward it to another practitioner, system, or setting to support the continuity of care. It provides a snapshot in time containing the pertinent clinical, demographic, and administrative data for a specific patient”.
Health IT Workforce Curriculum Version 4.0

24. Contents of the CCDA, CCD section:
Patient demographics
Problems / diagnoses
Immunizations
Vital signs
Encounters
Insurance information
Allergies and alerts
Family history
Results
Medical equipment
Functional status
Advance directives
Medication list
Social history
Procedures
Plan of care
The CCD part of the CCDA is also described as the core data set of the most relevant administrative, demographic, and clinical information facts about a patient's health care, covering one or more health care encounters. The CCD can include patient demographics, insurance information, advance directives, problems and diagnosis, allergies and alerts, medication list, immunizations, family history, social history, vital signs, results, procedures, encounters, medical equipment, plan of care, health care providers, and functional status. As you can tell, there are many sections of data that could be important in a transitions of care situation.
Health IT Workforce Curriculum Version 4.0

25. Example of structured XML file
Here, you see an example of a CCDA document that uses the CCD. Remember that it is just a CDA with additional constraints and specifications placed on it. That means certain sections and fields are required. Entries are required for all the medications, allergies, and results and the entries must use terminology, such as RxNorm and LOINC.
5.26 Figure (HL7 Implementation Guides for CDA Release 2: IHE Health Story Consolidation, DSTU Release US Realm)
Health IT Workforce Curriculum Version 4.0

26. HL7 Clinical Document Architecture (CDA) implementation guides are a key part of MU interoperability
For transitions of care and referrals and for health information exchange (HIE) communication:
CCDA
For communication with and via patient portals:
For reporting quality metrics:
Quality Reporting Document Architecture (QRDA)
For public health reporting:
Cancer registry reporting, case reporting
CCDA is not the only CDA Implementation Guide. There are also implementation guides for using CDA for electronic quality measure submissions and for submitting reports to public health authorities. All ONC 2014 and ONC 2015 certified EHRs are required to support CCDA and QRDA, or quality reporting document architecture, and public health CDA implementations. The MU and MIPS regulations require that CCDA be used to enable patient engagement and care coordination. The MU and MIPS regulations require that QRDA be used for electronic submission of clinical quality measures. They also allow for public health submission using other CDA implementation guides. Because of CDA’s heavy use in the Meaningful Use and MIPS regulations, it is rapidly achieving widespread adoption in the United States.
Health IT Workforce Curriculum Version 4.0

27. Unit 5: Standards for Interoperable Health IT, Summary – Lecture d, Introduction to HL7 CDA®
HL7 version 3 was created using a Reference Information Model as a result of limitations with HL7 version 2®
However, although HL7 version 3’s messaging standards are not highly adopted, its document standards have been adopted, notably the Clinical Document Architecture (CDA)
The Consolidated CDA (CCDA) further specifies the CDA and is used to send patient clinical information to patient portals and to send patient summaries to the next provider of care as part of Meaningful Use
This concludes Lecture d of Standards for Interoperable Health IT. To summarize, HL7 version 2® had limitations and so version 3 was created, this time using a Reference Information Model. Although the messaging standards were not highly adopted, there was much success with HL7 version 3’s document standards. The most notable standard is the clinical document architecture (CDA). The Consolidated CDA (CCDA) further specifies the CDA and is used to send patient clinical information to patient portals and to send patient summaries to the next provider of care as part of the Meaningful Use program.

28. Standards for Interoperable Health IT References – Lecture d
HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, DSTU Release 1.1 U.S. Realm Draft Standard for Trial Use, 2012.
HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, Release 1.1 – U.S. Realm.
HL7 Implementation Guide: S&I Framework Transitions of Care Companion Guide to Consolidated-CDA for Meaningful Use Stage 2, Release 1 – US Realm.
No audio.
Charts, Figures, Tables
5.18 Figure: HL7 Version 3 Interoperability Standards, Normative Edition (2012). HL7 Version 3 Reference Information Model (RIM).
5.19 Figure: (Lorenzi, V. (2016). CDA supports incremental interoperability.

29. Standards for Interoperable Health IT References – Lecture d (Cont’d – 1)
Charts, Figures, Tables
5.20 Figure: HL7 Clinical Document Architecture, Release 2, Normative Edition (2005). CDA represented as a model.
5.21 Figure: Adapted from HL7 Clinical Document Architecture, Release 2, Normative Edition (2005). CDA format of CDA sample.
5.22 Figure: Adapted from HL7 Clinical Document Architecture, Release 2, Normative Edition (2005). XML format of CDA sample.
5.23 Figure: HL7 Implementation Guide: S&I Framework Transitions of Care Companion Guide to Consolidated-CDA for Meaningful Use Stage 2, Release 1 – US Realm (2013). Example of a narrative block: medications.
5.24 Figure: HL7 Implementation Guide: S&I Framework Transitions of Care Companion Guide to Consolidated-CDA for Meaningful Use Stage 2, Release 1 – US Realm (2013). Example of an entry: substance administration.
5.25 Figure: Lorenzi, V. (2016). Evolution of CCDA.
5.26 Figure: HL7 Implementation Guides for CDA Release 2: IHE Health Story Consolidation, DSTU Release US Realm. Example of structured XML file.
No audio.

30. Unit 5: Standards for Interoperable Health IT, Lecture d – Introduction to HL7 CDA®
This material was developed by Columbia University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number 90WT0004.
No audio.
End.