U.S. Health and Human Services ffice of the National Coordinator for Health IT Transitions of Care Initiative Companion Guide to HL7 Consolidated CDA for Meaningful Use Stage 2
Revision History Date Document Version Document Revision Description 8/23/2012 1.0 Initial draft based on the proposed MU2 requirements Page 2 of 75
Acknowledgements The authors of this document wish to recognize the following participants of the Transitions of Care Implementation Guidance Sub-Workgroup who contributed their time and expertise to the development of this guide. Placeholder: List of Initiative Participants Copyrights Include any standards referenced in the document here or other copyrighted material. This is an example: This material includes SNMED Clinical Terms (SNMED CT ) which is used by permission of the International Health Terminology Standards Development rganization (IHTSD). All rights reserved. SNMED CT was originally created by The College of American Pathologists. "SNMED " and "SNMED CT " are registered trademarks of the IHTSD. This material contains content from LINC (http://loinc.org). The LINC table, LINC codes, and LINC panels and forms file are copyright (c) 1995-2011, Regenstrief Institute, Inc. and the Logical bservation Identifiers Names and Codes (LINC) Committee and available at no cost under the license at http://loinc.org/terms-of-use. Page 3 of 75
Executive Summary The Companion Guide to Consolidated Clinical Document Architecture (CDA) for Meaningful Use Stage 2 provides supplemental guidance to the Health Level Seven (HL7) Implementation Guides for CDA Release 2: Integrating Health Enterprise (IHE) Health Story Consolidation, Draft Standard for Trial Use (DSTU) Release 1.1 - US Realm, or "The Consolidated CDA," which was first published in December 2011. The purpose of the document is to provide clear and unambiguous guidance to the healthcare community for implementation of regulatory requirements on care transition exchange packages. The development of the Companion Guide is a direct result of feedback from the healthcare community that Consolidated CDA is complicated and alone, does not provide clear, unambiguous guidance to enable successful implementations. The Standards & Interoperability (S&I) Framework, enabled by the ffice of the National Coordinator (NC) for Health Information Technology, ffice of Standards & Interoperability (SI) facilitated the development of the Companion Guide. As a companion, or a supplement, to the Consolidated CDA implementation guide, the Companion Guide does not replace the implementation guide, but rather references the guide where requirements align with the standard specification. The guide aims to provide additional clinical and functional context to assist the implementation community in their efforts to offer practical guidance that is outside the scope of the HL7 balloted standards. This guide is organized in sections that cover a wide range of content including introductory content and background information on the Transitions of Care Initiative, guidance on implementing the Meaningful Use Stage 2 requirements, Consolidated CDA document alignment and implementation recommendations from the Transitions of Care Initiative. Page 4 of 75
Table of Contents ffice of the National Coordinator for Health IT Executive Summary... 4 1. Introduction... 8 1.1. Transitions of Care Initiative verview... 8 1.2. Transitions of Care and Consolidated CDA... 8 1.2.1. Analysis of MU2 Requirements... 9 1.3. Purpose... 10 1.4. Audience... 10 1.5. Requisite Knowledge... 10 1.6. Contents of this Guide... 10 2. General Consolidated CDA Guidance... 12 2.1. Health Level Seven and CDA... 12 2.1.1. HL7 Version 3... 12 2.2. Navigating the Consolidated CDA Implementation Guide... 12 2.2.1. Template-Driven Approach... 12 2.3. Guidance on Accommodating MU2 Requirements... 16 2.3.1. ptions for Systems Sending and Receiving CDA Documents... 17 2.3.2. Supplementing Meaningful Use Stage 1 Requirements... 18 2.3.3. Migration Considerations (MU1 to MU2)... 19 2.3.4. Using CDA Documents to Meet the Needs of Care Transitions... 20 2.3.5. Handling Missing or Irrelevant Clinical Data... 20 3. Implementing MU2 Requirements... 24 3.1. MU2 Summary of Care Record... 24 3.1.1. Consensus Recommendations... 24 3.2. Patient Information... 25 3.2.1. Best Practices Guidance... 25 3.2.2. Indicated Elements... 25 3.2.3. Record Target Header Element... 26 3.3. Visit or Hospitalization Information... 28 3.3.1. Best Practices Guidance... 28 3.3.2. Indicated Elements... 28 3.3.3. Component f Header Element... 29 3.3.4. Documentation f Header Element... 31 3.4. Care Planning... 34 Page 5 of 75
3.4.1. Best Practices Guidance... 34 3.4.2. Indicated Sections... 34 3.4.3. Plan of Care Section Structure... 35 3.4.4. Instructions Section Structure... 35 3.4.5. Hospital Discharge Instructions Section Structure... 36 3.5. Conditions or Concerns... 36 3.5.1. Best Practices Guidance... 36 3.5.2. Indicated Sections... 37 3.5.3. Allergies (entries required) Section Structure... 38 3.5.4. Encounters (entries required) Section Structure... 38 3.5.5. Hospital Discharge Diagnosis Section Structure... 39 3.5.6. Problem (entries required) Section Structure... 39 3.5.7. Reason for Visit Section Structure... 39 3.6. Medications and Immunizations... 39 3.6.1. Best Practices Guidance... 39 3.6.2. Indicated Sections... 40 3.6.3. Immunizations (entries required) Section Structure... 41 3.6.4. Medications (entries required) Section Structure... 41 3.7. bservations and Results... 42 3.7.1. Best Practices Guidance... 42 3.7.2. Indicated Sections... 42 3.7.3. Results (entries required) Section Structure... 43 3.7.4. Social History Section Structure... 43 3.7.5. Vital Signs (entries required) Section Structure... 44 3.8. Procedures and Surgeries... 44 3.8.1. Best Practices Guidance... 44 3.8.2. Procedures (entries required) Section Structure... 44 4. Consolidated CDA Document Alignment... 45 4.1. Consolidated CDA and MU2 Requirements... 45 4.2. Assessing Consolidated CDA Documents... 45 4.2.1. CCD Alignment... 46 4.2.2. Consultation Note Alignment... 48 4.2.3. Discharge Summary Alignment... 49 4.2.4. H&P Note Alignment... 50 Page 6 of 75
5. ToC Initiative Recommended Approach... 52 5.1. ToC Key Information Exchanges... 52 5.1.1. ToC Priorities... 52 5.2. Recommended Conformance... 53 5.2.1. Use of Null Flavors... 53 5.3. Approach Preamble... 53 5.4. ToC Approach: Header... 54 5.5. ToC Approach: CCD... 55 5.5.1. ToC Approach: CCD Body... 55 5.6. ToC Approach: Discharge Summary... 57 5.6.1. ToC Approach: Discharge Summary Body... 58 6. Additional Guidance... 61 6.1. Tools... 61 6.1.1. HT/MDHT... 61 6.1.2. Trifolia... 61 6.1.3. NIST Validation... 62 6.2. Educational Resources... 62 6.2.1. ToC Quickstart Site... 62 6.2.2. Clinical Document Architecture (CDA)... 62 6.2.3. Blogs... 63 6.2.4. Meaningful Use... 64 6.2.5. Vocabularies... 64 Appendix A: Clinical Best Practices... 66 Appendix B: Consolidated CDA Structured Document Body Constraints... 70 Page 7 of 75
1. Introduction 1.1. Transitions of Care Initiative verview In support of their objective to facilitate nationwide adoption of health information technology and enabling interoperability for the exchange of health information, the Standards & Interoperability (S&I) Framework, enabled by the ffice of the National Coordinator (NC) for Health Information Technology, ffice of Standards & Interoperability (SI) has sponsored the development of harmonized interoperability specifications. These specifications are designed to support national health initiatives and healthcare priorities, including Meaningful Use (MU), the Nationwide Health Information Network (NwHIN), and the ongoing mission to improve health care delivery, advance care coordination, and reduce costs to realize better population health. Several initiatives comprise the S&I Framework, each focusing on a single interoperability challenge with a set of value-creating goals and outcomes to enhance the efficiency and effectiveness of healthcare delivery. The Transitions of Care (ToC) Initiative, among the first Initiatives launched by the S&I Framework, focuses on empowering patients, engaging the clinician, and enabling health information exchange in support of national health initiatives including increasing patient safety and improving health care outcomes. The ToC Initiative is supported by health care providers, health IT vendors, states, federal partners, government agencies, the standards community, and the research community. The purpose of the ToC Initiative is to improve the electronic exchange of core clinical information among providers, patients and other authorized entities electronically in support of Meaningful Use and Institute of Medicine (IM)-identified needs for improvement in the quality of care. The following question serves as the motivating factor for the Initiative: What if every care transition was accompanied by an unambiguously-defined core set of high-quality clinical data? Key Functions of the Initiative Focus on clinical content to be exchanged in patient care transitions; Build on existing standards to accelerate results; Work with community to lower the implementation burden; and Guide decision-making based on the requirements of Meaningful Use that are consistent with IM-identified needs for improvement in the quality of care. Key utputs of the Initiative Unambiguous definition of the clinical elements that should be included in care transitions; Definition of key clinical constructs that provide guidance on the ToC approach for the exchange of information in the event of a patient care transition; Agreement on a single standard (Consolidated CDA) in support of Meaningful Use requirements, which minimizes interoperability errors and streamlines patient care coordination; and Identification of tools and resources to lower the barrier to implementation. 1.2. Transitions of Care and Consolidated CDA Prior to the development of the Consolidated CDA implementation guide, there were several "sources of truth" for CDA. Eight Health Story implementation guides, Health Information Technology Standards Panel (HITSP)/C32, HITSP/C83, HITSP/C80, HITSP/C48, HL7, and Integrating the Healthcare Enterprise Page 8 of 75
(IHE) Templates are examples of the implementation guides that use the CDA standard. The multitude of implementation guides available resulted in the overlap of guidance. Furthermore, each guide contained multiple layers of references to other documents. The resulting occurrence forces developers to follow a reference trail in order to implement standards, increasing the risk of inconsistency in information exchange. In addition, a criticism of the existing implementation guides was the perceived depth of knowledge required to implement a CDA-based standard. There was no technical resource to guide implementation and ensure validity and accuracy, which allows for inconsistent implementations. As part of an effort to align standards cited by national regulations, the S&I Framework launched the CDA Consolidation Project as part of the Transitions of Care Initiative and worked alongside of HL7, Integrating the Healthcare Enterprise (IHE) and the Health Story Project to produce a single source for implementing CDA documents defined by the Centers for Medicare and Medicaid Services (CMS) Final Rule for Electronic Health Record Incentive Program Stage 1 and NC Final Rule for Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology. The resulting guide, the HL7 Implementation Guides for CDA Release 2: IHE Health Story Consolidation, DSTU Release 1.1 - US Realm, or "The Consolidated CDA," is an implementation guide for CDA documents including the Clinical Care Document (CCD), Consultation Note, and Discharge Summary. The Consolidated CDA standard is indicated by the CMS Proposed Rule for Electronic Health Record Incentive Program Stage 2 and NC Proposed Rule for Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology as the recommended standard. The Consolidated CDA standard improves and centralizes existing CDA templates and source implementation guides to allow for simplified, reusable implementations, ensuring documents contain consistent and accurate information for every transition of care. 1.2.1. Analysis of MU2 Requirements In the interest of streamlining adoption, the ToC Initiative pursued an analysis of the proposed Meaningful Use Stage 2 (MU2) requirements to perform due diligence and identify issues that adopters will likely have in pursing the proposed MU2 objectives while following the current Consolidated CDA implementation guide. bjectives of the ToC Analysis of MU2: Identify any gaps or ambiguities between the Consolidated CDA standard specification and the proposed Meaningful Use Stage 2 requirements. Identify gaps between the clinical needs previously defined by the ToC participants and the proposed Meaningful Use Stage 2 requirements for care transitions. Analysis of Data Element Requirements for Proposed MU2 bjectives: Clinical Summary (to Patient- Ambulatory Setting nly) View, Download, or Transmit to 3rd Party (to Patient) Transition of Care (Summary of Care Record) Page 9 of 75
The analysis findings resulted in proposed enhancements to the HL7 Structured Documents Work Group (SDWG) for the May 2012 ballot of the Consolidated CDA implementation guide and served as the basis for the guidance contained in this Companion Guide. 1.3. Purpose This Companion Guide captures the efforts of the ToC Initiative to provide contextual and purposeful implementation guidance for the health care community to ease the burden of implementations. The guide aims to supplement the CDA Consolidation implementation guide by providing additional clinical and functional context to assist the implementation community in their efforts to offer practical guidance that is outside the scope of the HL7 balloted standards. This Companion Guide enables the exchange of key clinical information among providers in the instance of a transition of patient care using concepts from the Consolidated CDA standard. Adoption and implementation of the recommended specifications establishes a common standard for the exchange of clinical information required for Meaningful Use and accelerates the adoption, for which eligible providers receive a monetary incentive. 1.4. Audience The audience of this Companion Guide includes, but is not limited to, software developers, vendors, and other health IT implementer parties pursuing CMS EHR Incentive Program and NC 2014 Edition EHR Standards and Certification requirements in support of Meaningful Use Stage 2 (MU2). While this guide includes informative content intended to educate the audience on the underlying HL7 Clinical Document Architecture, Release 2 (CDA R2) standard and a specific implementation guide called "The Consolidated CDA," or as it is officially named, the HL7 Implementation Guides for CDA Release 2: IHE Health Story Consolidation, DSTU Release 1.1 - US Realm, this guide remains a supplement to these standards, which are available through HL7. The HL7 CDA R2 standard serves as the authoritative source for the complete specification for implementation and development and may be accessed through the HL7 site by HL7 members. 1.5. Requisite Knowledge Readers of the Companion Guide are assumed to have functional knowledge of HL7 concepts including CDA and Reference Information Model (RIM) for both terminology and data types. Readers should also have knowledge of Extensible Markup Language (XML) and XPath syntax. Additionally, readers should have an understanding of terminologies such as SNMED CT, LINC, CPT, ICD, and RxNorm. Resources for these concepts are available in Section 6, Additional Guidance Section. 1.6. Contents of this Guide A description of each Companion Guide section is provided below. Section 1: Introduction This section contains an overview of the Transitions of Care Initiative, background on the development of the Consolidated CDA IG, and guidance to assist in understanding concepts integral to implementation of the MU2 requirements. Section 2: General Consolidated CDA Guidance This section contains information on how to navigate the Consolidated CDA IG, implementing considerations for Meaningful Use, migration strategies, and the inclusion of clinically-relevant data. Page 10 of 75
Section 3: Implementing MU2 Requirements This sections details all representations of MU2 Requirements in Consolidated CDA, as well as consensus recommendations for implementations and examples. Section 4: Consolidated CDA Document Alignment This section contains guidance on how to implement MU2 requirements using any of the current Consolidated CDA documents. Section 5: Transitions of Care Initiative Recommended Approach This section contains guidance on how to meet Meaningful Use requirements and the needs of clinicians, based on recommendations from the Transitions of Care Initiative. Section 6: Tools and Resources This section contains suggested tools and resources to assist in understanding, implementing, and validating implementation specifications. Appendix The appendix includes clinical workflow considerations and additional guidance on the exchange of clinical documentation using Direct. Page 11 of 75
2. General Consolidated CDA Guidance ffice of the National Coordinator for Health IT To assist in the implementation of Meaningful Use Stage 2 (MU2) requirements, this section provides guidance on navigating the Consolidated CDA implementation guide, guidance on CDA concepts that are relevant to Stages 1 and 2 of Meaningful Use and considerations for the successful exchange of Consolidated CDA documents during care transitions. This section contains guidance both for developers of EHR systems that generate or receive CDA documents, as well as guidance for providers who use those systems. The guidance is not merely about technical and strict compliance to regulations and standards, but is intended to encourage creation of highly functional and usable EHR systems that are adopted by clinicians because they provide the information needed to efficiently and effectively treat patients during care transitions. While the Companion Guide provides a brief overview of the CDA concepts in which successful MU2 implementations are reliant upon, these assume as prerequisites familiarity with the HL7 CDA R2 standard, as well as the Consolidated CDA implementation guide. 2.1. Health Level Seven and CDA To promote widespread adoption and interoperability, health IT Standards Development rganizations (SDs) accredited by the American National Standards Institute (ANSI), develop specifications which are vetted through open consensus. Health Level Seven (HL7) is a not-for-profit volunteer organization where members developing the specifications represent a wide range of healthcare community stakeholders. The resulting HL7 standards enable disparate healthcare applications to exchange key sets of clinical and administrative data as well as the architecture through which the data is captured. HL7 Clinical Document Architecture (CDA) describes an XML format which represents the patient data captured during an encounter in the form of a clinical document for exchange. Release 2.0 of HL7 CDA was published in 2005 and met with support of the healthcare industry which fostered adoption until reaffirmation in 2010. In the post-arra/hitech era, adoption of the standard has rapidly increased due to federal regulations, namely, the Meaningful Use of Electronic Health Record Technology. 2.1.1. HL7 Version 3 As part of an effort to create a streamlined and more scalable standard, HL7 embarked on the development of reusable methodologies in Version 3. As one of the first HL7 Version 3 (V3) specifications, CDA makes use of the HL7 Reference Information Model (RIM), a predefined set of data types, and select terminology domains. Within the CDA schema, the RIM defines the fields and vocabularies define the field values. To convey context and purpose within CDA, templates are used to constrain CDA schema and provides the architecture for CDA documents. Templates and their central role in Consolidated CDA are further described in the following sections. 2.2. Navigating the Consolidated CDA Implementation Guide Exceeding 500 pages, the Consolidated CDA implementation guide may be challenging to navigate. This section of the Companion Guide provides an overview on the basic concepts referenced in the document to assist with the navigation of the Consolidated CDA implementation guide. 2.2.1. Template-Driven Approach As the "source of truth" for consistent CDA implementations, the Consolidated CDA implementation guide contains a library of computable artifacts, or templates, which can be interchanged and republished to create fully-compliant CDA documents for exchange. The guide was designed to include Page 12 of 75
all of the necessary templates, defined in one place, to make it easier to analyze and implement the standard in a consistent manner. Templates constrain clinical content and correspond to the three levels of CDA which reflect degrees of semantic interoperability. At levels one and two, header, document, and section templates contain content that is, at a minimum, human-readable, which means that a provider may display and be able to read the content of a CDA document on a standard web browser without the need for any application. Entry templates at level three contain the machine-readable data which can be consumed by an information system and integrated for applications such as medication reconciliation and clinical decision support. For the purposes of this guide, it is important to state that these degrees of semantic interoperability are integral to consistent health information exchange practices and enhance the ability of information systems to use data effectively. To make it easier to navigate the document, the Consolidated CDA implementation guide is divided into four main chapters that are dedicated to each template type which comprise CDA documents. Beginning at the document-level, chapters detail the contents with the broader, human-readable contexts contained in the header and refine down to the specific machine-readable clinical statements conveyed at the entry-level. rganization of templates in the Consolidated CDA implementation guide: Chapter 2: General Header Template Chapter 3: Document-Level Templates Chapter 4: Section-Level Templates Chapter 5: Entry-Level Templates This guide recommends starting with a review of Chapter 3: Document-Level Templates. These templates describe the purpose and rules for assembling a CDA document type which includes specific constraints upon the US Realm Header defined for general use across all CDA documents within chapter 2. At the time of this publication, the Consolidated CDA implementation guide includes definitions for nine different types of commonly used CDA documents. Table 1: Consolidated CDA Document Type Templates Document Title Continuity of Care Document (CCD) Release 1.1 Consultation Note Discharge Summary Diagnostic Imaging Report (DIR) History and Physical Note (H&P) Description Includes a core data set of the most relevant, administrative, demographic and clinical information facts about a patient's healthcare, covering one or more healthcare encounters Includes the reason for a patient referral, history of present illness, physical examination, and decision-making component Contains a summary of a patient's admission to a hospital and provides pertinent information for the continuation of care following discharge from the hospital Contains a consulting specialist s interpretation of image data Includes current and past conditions including essential Page 13 of 75
Document Title perative Note Progress Note Procedure Note Unstructured Documents Description information that helps determine an individual's health status Records the pre- and post-surgical diagnosis, pertinent events of the procedure, as well as the condition of the patient following a surgical procedure Patient s clinical status during a hospitalization or outpatient visit; thus, it is associated with an encounter Records the indications for a procedure and, when applicable, post-procedure diagnosis, pertinent events of the procedure, and the patient s tolerance of a non-operative procedure Used when the patient record is captured in an unstructured format, such as a word or PDF document, that is encapsulated within an image file or as unstructured text in an electronic file Each document-level template contains the scope and intended use of the document type, as well as a description and explanatory narrative. It also includes the template metadata to indicate the value of certain attributes, the header constraints, and required and optional section-level templates. Each of the different document types defines the constraints, or limitations, on the two parts of a CDA document, the header and body. The templates are designed in order to create standardized clinical documents that are specifically intended to support provider workflows in various use cases. Section and entry templates specify standardized patterns used to express clinical concepts and provide the basis for reusability of the CDA documents. Section-level templates, which are constrained within a CDA document, revolve around a common clinical concept. Entry-level templates represent individual clinical statements through coded data elements and are mostly contained within section templates. In certain scenarios, it may be appropriate to include an entry-level template as a standalone clinical statement. Each document template defines a collection of required and optional sections, including entries within each section, which should be contained within the document type. Figure 1 represents the relationships between template types. Figure 1: Template Types Page 14 of 75
Containment relationships between templates are employed within the Consolidated CDA implementation guide as references to other template types that are used by or contained by that particular template. Tables detailing related templates as well as hyperlinks are available within each individual document, section, and entry template to provide contextual guidance for implementers. Template identifiers (template IDs) are employed to assert conformance to a particular template. In an exchange, originators of a CDA document may use template IDs to signal conformance to a specific template while recipients may filter content through rejecting certain template IDs. For the purpose of validation, template IDs set the rules for which the template is tested and tells the receiving system the fields to expect. It is necessary to include all template IDs that are required by the specification as well as any additional template IDs for which the template is asserting conformance. This practice assists the receiving system in organizing information, but is not required by all specifications. To this end, it is important to note that Consolidated CDA introduces harmonized templates that, in many cases, supersede specifications previously employed. Updated template IDs and any previous template IDs are detailed in Appendix B of the Consolidated CDA implementation guide. 2.2.1.1. Conformance As discussed in the previous section, contents of a CDA document are dictated through constraints at each level of CDA. CDA implementers characterize conformance requirements in terms of three general levels that correspond to three different, incremental types of conformance statements as defined in chapter 1.7 of the Consolidated CDA implementation guide. Level ne requirements impose constraints upon the CDA Header. The body of a Level ne document may be XML or an alternate allowed format. If XML, it must be CDA-conformant markup. These constraints support full CDA semantics including sections and structured entries. Level 2 requirements specify additional constraints at the section level of a CDA document. Most critically, this level specifies the section code and the cardinality of the sections themselves, whether optional or required. Level 3 requirements specify additional constraints at the entry level within a section. A specification is considered "Level Three" if it requires any entry-level templates. Constraints in the Consolidated CDA implementation guide are governed by conformance verbs which define template contents. The conformance verbs employed within Consolidated CDA were harmonized from HL7, IHE, and HITSP specifications, which are detailed within Appendix B of the Consolidated CDA implementation guide. Table 2 lists the conformance verbs, or keywords, described in chapter 1.8.3 of the Consolidated CDA implementation guide. Table 2: Consolidated CDA Conformance Verbs Conformance Verb SHALL SHALL NT SHULD/SHULD NT Description An absolute requirement An absolute prohibition against inclusion Best practice or recommendation. There may be valid reasons to ignore an item, but the full implications must be understood and carefully Page 15 of 75
Conformance Verb MAY/NEED NT Description weighed before choosing a different course Truly optional; can be included or omitted as the author decides with no implications Conformance verbs, when used in the Consolidated CDA implementation guide, are written in all capital letters and bolded to assist with identification by implementers. Figure 2 demonstrates conformance verbs, or keywords, employed to constrain the Allergies Section with entries required template. Figure 2: Example Representation of CDA Conformance 1. Conforms to Allergies Section(entries optional) template (2.16.840.1.113883.10.20.22.2.6). 2. SHALL contain exactly one [1..1] templateid (CNF:7527) such that it a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.2.6.1" (CNF:10379). 3. SHALL contain exactly one [1..1] code (CNF:15349). 4. This code SHALL contain exactly one [1..1] @code="48765-2" Allergies, adverse reactions, alerts (CodeSystem: LINC 2.16.840.1.113883.6.1) (CNF:15350). 5. SHALL contain exactly one [1..1] title (CNF:7534). 6. SHALL contain exactly one [1..1] text (CNF:7530). 7. SHALL contain at least one [1..*] entry (CNF:7531) such that it a. SHALL contain exactly one [1..1] Allergy Problem Act (2.16.840.1.113883.10.20.22.4.30) (CNF:7532). 2.3. Guidance on Accommodating MU2 Requirements As detailed in latter sections of this guide, achieving MU2 requirements does not rely on specifying a single CDA document type or implementation specification. Rather, MU2 requirements are fully achievable through a variety of specifications to be employed as needed to best meet the needs of an organization. Similarly, Consolidated CDA templates and the CDA R2 standard allow the same flexibility while maintaining conformance for validation. The guidance in this section provides assurance that clinical information is reliably and completely conveyed even if it is not included as part of a Consolidated CDA document type definition. Systems that are compliant with Consolidated CDA must also be compliant with CDA R2. It is important to reinforce the basic CDA R2 requirement of human readability, because providers rely on clinical information included in the clinical documents that they create (author) and send through their EHR systems. This principle assures that clinical documents will be accurately rendered in human-readable form by the receiving system, even if the clinical documents and section content are not known ahead of time. Page 16 of 75
2.3.1. ptions for Systems Sending and Receiving CDA Documents As outlined in chapter 1.3 of the Consolidated CDA implementation guide, fully-compliant CDA documents are specified for each document type. To meet the varying business needs of healthcare organizations, the ability to include additional optional CDA elements beyond the Consolidated CDA document definitions is allowable and maintains compliance with the underlying CDA R2 standard. This means that each specific document type (e.g., CCD, Discharge Summary) has certain required and optional sections, as well as constraints on entries within those sections, which may be supplemented by additional CDA section or entry templates to result in a fully-compliance CDA document. This concept is depicted in Figure 3. Figure 3: Additions to Consolidated CDA Document Type Definitions Principles in Practice: A CCD, as defined in Consolidated CDA, does not contain a Reason for Referral section as either a required or optional section. But what if a referring provider is sending a CCD to request a consultation of another provider and wishes to include a Reason for Referral? Consolidated CDA allows for the addition of this section to the defined document type. If the sender wants to include such a section, and the sender s system allows it to be included, the sender may include the Reason for Referral and send it, with expectation that it will be displayed. Page 17 of 75
Consistent with responsibilities of systems creating CDA documents, systems receiving CDA documents must be capable of rendering all human-readable content of any CDA document received, including additional sections beyond the document type definition. Human-readable content includes the header as well as narrative blocks of sections. Principles in Practice: While some systems may create CCDs with only the five minimum required MU1 sections, others may include additional optional CCD sections (up to all 17), and still others may include additional CDA templates not included in the CCD document type definition, such as the Reason for Referral example noted previously. The receiving system is not required to parse the structured entries (discrete fields) in the additional sections, but it must be able to display the entire CDA document, including narrative blocks, in human readable form. Adherence to the CDA R2 requirement human-readability allows vendors and providers to create as minimal or robust content to communicate pertinent patient clinical information despite varying business needs. Summary of agreement between senders and receivers of CDA documents: Senders: Send what is needed. Create content rich enough to comply with regulations (e.g., MU2) or more to support the needs of intended receivers to ensure continuity of patient care using Consolidated CDA templates. Receivers: Display everything human-readable that is received. Parse and import as discrete data what is required by regulations (e.g., MU2) or more (e.g., customer and HIE requirements) if possible, using Consolidated CDA templates. There are several techniques to exchange additional clinical content which may better serve the needs of an organization. In keeping with the mission of the ToC Initiative, it is recommended that developers of electronic health record systems enable providers to communicate the clinical content necessary in a care transition by supporting the need for additional optional sections within CDA documents which best support the provider workflow. Additional guidance on clinical workflow considerations are provided in Appendix A. 2.3.2. Supplementing Meaningful Use Stage 1 Requirements This guidance is written on the assumption that most vendors are not starting from scratch, but that Meaningful Use Stage 1 (MU1) already requires vendors to provide the capability to create an electronic copy of health information using the CCD or the American Society for Testing and Materials (ASTM) Continuity of Care Record (CCR) standards and to be able to receive and display both CCD and CCR. Based on ToC recommendations, one option to fulfill MU2 requirements for a Summary of Care Record is to create a CCD using the updated CCD Release 1.1 as defined in section 3.1.2 of the Consolidated CDA implementation guide. The assumption that many systems already send and receive CCD has a practical impact on how additional information is packaged and sent. Please see the following section on Migration Strategies for more details. Additional guidance on Consolidated CDA document types and MU2 summary of care record requirements are detailed in section 4 of this guide. Page 18 of 75
CCD document type considerations for additional optional sections: If the additional sections are included in the CCD definition, create one or more CCD documents, clearly titled as Continuity of Care Documents (Summarization of Episode Note) If the additional sections data are available at the same time that the CCD is generated, it is simplest to send them as additional sections to the CCD that is already required. They may be sent as narrative blocks only and/or as sections with both narrative blocks and structured entries, unless MU2 specifically requires structured entries. Include optional sections (even if not defined in CCD) as long as these sections reasonably fit within the basic purpose of the document as a summary for continuity of care purposes. If the additional sections do not reasonably fit within a summary (e.g., full details about a specific procedure, operation, or imaging study), create a separate document type, not called a CCD, but using the best fit document type as detailed in section 4 of this guide. The key point is that the document should be named as accurately as possible, so receivers will know what they are receiving even before they open the document. Thus, more than one document may be appropriate for a transition, as discussed in section 2.3.4 of this guide. 2.3.3. Migration Considerations (MU1 to MU2) This section provides guidance to assist in the transition from Meaningful Use Stage 1 to Stage 2. As noted in the introduction of this guide, the Consolidated CDA implementation guide did not exist at the time MU1 was released, but has since defined a harmonized CCD specification in support of interoperability. The CCD Release 1.1, as defined by Consolidated CDA, supersedes previous releases and meets MU1 requirements. As developers prepare for MU2, it is important to note considerations to ensure vendors are capable of meeting both MU1 and MU2 requirements to ensure providers achieve Meaningful Use, whether they are an early or late adopter. First and foremost, it is important to note that all of the data required in MU1 is also required in MU2. While the constraints are very similar, there are some changes that must be made. These migration considerations are applicable to developers who have certified according to C32 specifications and indicate enhancements to CCDs to be conformant with MU2 requirements and Consolidated CDA. Types of changes that must be considered for MU2 requirements: New template IDs for existing sections Additional sections required by MU2 Additional required entries within sections, or CDA Header elements, required by MU2 New vocabularies Data elements not carried over to Consolidated CDA Different constraints on existing elements For detailed guidance on these considerations, please reference Keith Boone s blog series on the topic. Specific guidance is available within the best practices guidance for each MU2 requirement in Section 3 of this guide. Page 19 of 75
2.3.4. Using CDA Documents to Meet the Needs of Care Transitions For transitions of care, one document does not apply to all patient care scenarios. Transitions may include varying levels of information within a document, as well as transmission of one or more documents at one or more points in time, in addition to other forms of information exchange, such as HL7 messages, unstructured Direct messages, and processes. For example, upon discharge from a hospital, a transition could include a CCD as a summary of care record, but could also include a Diagnostic Imaging Report (DIR) and/or a Pathology Report. Similarly, a referral may include a CCD as well as a History and Physical or a Progress Note (Visit Note) document. When multiple documents are sent for a care transition, it is not necessary or desirable to include redundant information on multiple documents. For example, if a medication list was sent in a CCD, and an perative Note and DIR are also sent to inform the receiving provider, there is no reason to include the medication list in more than one of the documents. In this example, the CCD would satisfy the MU2 requirements, and the additional documents would fulfill the needs of this particular care transition, without having to also fulfill MU2 requirements. These multiple types of documents should all be clearly named and should not be combined into a single document if the data does not align with the purpose of that document type. Similarly, even several instances of the same document should not be inappropriately combined, such as a scenario where the sending provider wanted to include a current CCD, but also attach a CCD from several months ago that contained relevant patient data from that particular visit. In this scenario, it is recommended that these documents be sent as separate documents so as not to misrepresent the intent and relevance of the pertinent patient data contained in each document. As a general rule, it is recommended to give preference to Consolidated CDA documents over other CDA document types not currently included in the specification, any alternative standards, or proprietary formats, to meet MU2 requirements. Because of the direction toward increasing semantic interoperability and ability to integrate structured data from the sending EHR into the recipient EHR, CDA should be the preferred format. Use of the CDA standard will allow for template-driven, consistent content that provides the smoothest incremental path to data consumption by EHR systems. While some EHR systems may only possess the capability to display a structured CDA document in a current version, future versions may be enhanced to fully integrate the data contained. Even though CDA documents are recommended, the use of non-cda document formats is permissible and even preferred where they are the best fit to the content being represented. HL7 CDA is an evolving standard and may not meet the needs of every care transition at this time. CDA templates to capture unstructured data for content, such as diagnostic images, EKGs, or dictated documents, may not be an ideal option. As an overarching principle, CDA is not one size fits all and should be employed where possible to increase interoperability and enhance the efficiency of health information exchange. 2.3.5. Handling Missing or Irrelevant Clinical Data Unavailable or Unknown Data In sections 1.8.8-1.8.9 of the Consolidated CDA implementation guide details guidance on how to handle unavailable and unknown information, as well as assertions that there is no information. In HL7 V3, unavailable, unknown or incomplete data are handled with flavors of null representing a coded value Page 20 of 75
which communicates the reasoning for missing information. Asserting a value for missing data is necessary for required data to meet validation and important in other circumstances as good practice. It is recommended that systems indicate the null flavors at the appropriate level of precision in order to convey accurate reasoning for the absence of required or pertinent data. The HL7 V3 Abstract Datatypes Specification, available to HL7 members, indicates a hierarchy of null flavor values. A more specialized code implies all of the more general codes above it in the hierarchy, as depicted in Figure 4. Figure 4: Null Flavor Hierarchy This Companion Guide does not limit the use of the null flavors. However, it offers a specific recommendation for handling required sections that are unavailable at the time of a transition or that contain data that is not pertinent to patient care needs. To demonstrate expression of a null flavor at the section level, an example is provided using the Hospital Course section. In this example, the null flavor NAV, outlined in blue, indicates that the information was not available at the time the Discharge Summary was created. Page 21 of 75
<!-- Hospital Course --> <component> <section nullflavor="nav" > <templateid root="1.3.6.1.4.1.19376.1.5.3.1.3.5"/> <code code="8648-8" displayname="hspital CURSE" codesystem="2.16.840.1.113883.6.1" codesystemname="linc"/> <title>hspital CURSE</title> <text> The hospital course was not documented yet</text> </section> </component> None or No Known Data In scenarios where the data reflects a value of none or that should not or did not occur, negation indicators are employed. Examples of such scenarios include a patient having no allergies or administration of a certain immunization is inadvisable (contraindication). For communicating these scenarios, a negation indicator (negationind) is used to flag the corresponding act as described in example 3 of the Consolidated CDA implementation guide chapter 1.8.9. However, consistent guidance on the use of negation indicators is not immediately clear between CDA R2 specifications. For the purposes of this guide, emphasis is placed on distinguishing between statements of no known, which employ negation indicators, and I don t know, which employ null flavors, given the potential impact on patient care. Similarly, circumstances where too much information or irrelevant data is provided upon a care transition, presents the same potential impact on patient care due to information overload. A summary of care record is just that, a summary, which means that it is not intended to be a complete patient record. For example, the Medications section must include current and active medications, but does not have to include all historical medications. There may be occasions where information exists in a patient s record, but the sender does not choose to include it in the summary of care record because it is not pertinent to the transition (e.g., a referral to a specialist). Irrelevant (Not Pertinent) Data For sections required by document-level template constraints or for Meaningful Use requirements that are not deemed relevant for the continuation of patient care, a null flavor for the missing information may be employed. However, at the time of this publication, the ToC Initiative determined that none of the available null flavors effectively communicated not clinically relevant. It is noted, however, that the MSK null flavor might be interpreted by some person to apply in these circumstances. Due to inconsistent guidance on the use of the MSK null flavor and potential interpretations including privacy and security implications, use of this null flavor may not be ideal. The recommendation of this guide is to include the section for conformance or MU2 requirements, with a narrative block that concisely states that information exists but was not sent, as depicted in the following example. Page 22 of 75
Principles in Practice: For example, in a Results section, which is required for MU2, outdated test results should not be included. Rather, the narrative may read: <text> Available results are not pertinent to this transition.</text> Please note that there are no constraints upon how the text is worded or how it is generated. Page 23 of 75
3. Implementing MU2 Requirements ffice of the National Coordinator for Health IT This section of the Companion Guide details the complete Summary of Care Record data elements and the Consolidated CDA sections that may be employed to meet the Meaningful Use Stage 2 (MU2) requirement. 3.1. MU2 Summary of Care Record Guidance to detail Final MU2 bjectives For the purposes of this guide, MU2 requirements have been organized into logical categories in order to best represent specific data element requirement guidance. Please note that these categories hold no meaning outside of organization purposes for this section of the Companion Guide. Hyperlinks are listed in the first column to corresponding Companion Guide sections for each category and applicable MU2 requirements. CG Category Section 3.X Table 3: MU2 Summary of Care Record Data Element Requirements & MU2 bjectives Data Element Requirement Immunizations administered during the visit EP: View/ Download/ Transmit EP: Transition of Care EP: Clinical Summary EH: View/ Download/ Transmit EH: Transition of Care 3.X Medication list 3.X Medications administered during the visit 3.1.1. Consensus Recommendations The rationale for resolving ambiguity when more than one section could meet MU2 requirements was based on applying the following principles: Look for direct alignment of MU2 wording and Consolidated CDA section name. Example: MU2 requires a Reason for Visit and Consolidated CDA has a Reason for Visit section Examine whether MU2 wording is close to Consolidated CDA wording and/or explained in the Consolidated CDA section description. Example: MU2 speaks of future appointments, future tests, goals, referrals to other providers and the Plan of Care section description mentions all these concepts. Examine whether MU2 explicitly points to a section. Example: MU2 speaks of an up-to-date problem list of current and active diagnoses. This states that diagnoses must be included in the Problem List section. Explicitly represent the MU2 data where possible, rather than relying on inference. Example: Use Reason for Visit to express MU2 reason for visit requirement, rather than assuming that the reason for visit can be inferred from other data such as diagnoses. Page 24 of 75
Evaluate whether structured data is required. Example: Standard vocabularies require structured entries, and thus results coded using LINC should be in a Results section with structured entries, rather than in a narrative section such as Hospital Discharge Studies. Ask whether there is already common usage in the industry. Being consistent with common practice will likely improve interoperability. Ask whether the document type being used already requires a section. E.g., if using a Discharge Summary document, the Plan of Care section is required, thus it is preferred over an Assessment and Plan section. 3.2. Patient Information This category captures MU2 requirements pertaining to patient information and the Consolidated CDA header elements which meet the requirement for an MU2 bjective. 3.2.1. Best Practices Guidance Guidance for implementations of the Consolidated CDA general header template to achieve MU2 requirements for patient information is provided below. Patient Name, Gender, and Date of Birth These data elements may be implemented as specified in the Record Target header element. Patient Preferred Language This data element may be implemented as specified the Record Target header element, but must use the International rganization for Standardization (IS) 639-1:2002 value set as required by MU2. Patient Race and Ethnicity These data elements require the use of the ffice of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, ctober 30, 1997 value set. This standard is available at http://www.whitehouse.gov/omb/fedreg_1997standards. For indicating multiple race codes for a patient, a CDA R2 extension is specified: sdwg:racecode. Additional information on CDA R2 extensions and their use is available in Appendix G of the Consolidated CDA implementation guide. 3.2.2. Indicated Elements Through analysis of Consolidated CDA, the ToC Initiative has determined the following Consolidated CDA header elements may be employed to meet the Patient Name, Gender, Date of Birth, Preferred Language, Race, and Ethnicity MU2 data requirements. Please note that these indicated Consolidated CDA header elements are inclusive of the components necessary to meet the MU2 data requirements and do not represent additional code system constraints imposed by the standard. MU2 Data Element Requirement Patient Name Patient Gender Patient Date of Birth CDA Header Element recordtarget/patientrole/patient/name recordtarget/patientrole/patient/administrativegendercode recordtarget/patientrole/patient/birthtime Page 25 of 75