CDAR2_IG_SUPPLEMENT_TO_IHE_CONSOL
Implementation Guide for CDA Release 2.0
Supplement to Consolidated CDA Templates for Clinical Notes
(US Realm)
DRAFT
January 2013
© 2012 Health Level Seven, Inc.
Ann Arbor, MI
All rights reserved.
Blue Cross and Blue Shield of Alabama
/ Co-Editor: / Penny Probst
Co-Editor/
Co-Chair: / Durwin Day / Co-Editor:
Co-Editor/
Co-Chair: / Craig Gabron / Co-Editor:
Co-Editor: / Daniel Vreeman / Technical Editor:
??? / ???
NOTES FOR DISCUSSION WITH CO-CHAIRS
· What about New Attachment Type acquisition? (Daniel may have created model, however we may still need to integrate all approvals (i.e., OESS, REGENSTRIEF, AWG, SDWG?)
· NEED TO add clarifying CDA validation (i.e., well formed only? CDA ONLY? CCD?, etc)
· Add Packaging information for CDA into BIN segment (Craig will lead with ML’s help at WG meeting or project call it time prior to WG)
· WHAT LOINC TO USE IN THE REQUEST?
· Ability to use LOINC’s in Structured location on RELMA also as unstructured...however those listed as Unstructured are restricted ONLY to unstructured. (Three options: Fully structured, partially structured, unstructured?) GUIDE PDF’s to the structured element (Structured Body or Nonxmlbody (3.4.2 for discharge summary)
· IN TOC.... Add Post Adjudicated Claims Examples.
· Add “User Stories” for each Healthcare Attachment type
o Durwin will write prototype for Claim, and see if appropriate for all.
Acknowledgements
The writers and editors of this document want to acknowledge the years of hard work and dedicated efforts of the current and past members of the Attachments Special Interest Group (ASIG), the Structured Documents and Attachments Work Groups at HL7 in building forward the research and development needed to achieve the goal of information exchange between the provider community and health plans/healthcare insurance companies.
The information needs of the industry that were identified and developed over the years became key input into the foundational content found in the Consolidated CDA Templates for Clinical Notes (C-CDA ). This standard is expected to be widely used in the exchange of clinical information between providers as well as providers and patients in satisfying many exchange criteria established under the Medicare/Medicaid EHR Incentive Program (aka, “Meaningful Use”).
This material contains content from LOINC® (http://loinc.org). The LOINC table, LOINC codes, and LOINC panels and forms file are copyright © 1995-2012, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and available at no cost under the license at http://loinc.org/terms-of-use.
Table of Contents
1 Preface 8
1.1 Revision History 8
2 Introduction 9
2.1 Audience 9
2.2 Purpose 9
2.3 Scope 9
2.4 Overview 10
2.4.1 Background 10
2.4.2 Approach 11
2.5 Organization of This Guide 11
2.6 Additional Attachment Information - Request and Response 12
2.6.1 Solicited and Unsolicited Attachments 12
2.6.2 Request Attachment Activity 13
2.6.3 Response Attachment Activity 14
2.6.4 Understanding Attachment activities 14
2.6.5 Attachment Request/Response Re-Association using Attachment ID 19
2.7 Definitions, Glossary and Acronyms 20
2.7.1 Definitions 20
2.7.2 Acronyms 20
2.8 Health Level Seven Organization 20
3 Understanding C-CDA 22
3.1 What is Clinical Document Architecture (CDA)? 22
3.2 Taking Advantage of Structured/Unstructured Content 23
3.2.1 Structured Content 24
3.2.2 Unstructured Content 24
3.3 What is C-CDA ? 24
3.4 This sub-chapter section may need to apply attachment needs specifically to the CCDA 25
4 Additional Information (Attachments) General 26
4.1 Standards to accomplish information exchange of the request and response 26
4.2 LOINC (Logical Observable Identifiable Names and Codes) 26
4.2.1 Obtaining LOINC and other resources from the Regenstrief Institute 27
4.2.2 Use of LOINC for Attachments 27
4.3 Using the LOINC code as an identifier in messages 30
4.3.1 The LOINC Committee 30
4.3.2 Obtaining the LOINC Database 30
4.4 Requesting Attachment Information 31
4.4.1 Using LOINC Code to request electronic documents 31
4.4.2 Using “Modifiers” LOINC Code to constrain the request. 31
4.4.3 Responding with Attachment Information 31
4.5 Solicited and Unsolicited Attachment Information 31
4.6 Using the LOINC Database to Identify Valid Attachment Types 31
4.6.1 Identifying valid attachment types in the LOINC Table 32
4.6.2 Identifying valid attachment types using RELMA 33
4.6.3 Searching RELMA 33
4.6.4 Browsing RELMA 33
4.6.5 Identifying valid attachment types using the online LOINC search application (http://search.loinc.org) 34
4.7 ISO Object Identifiers (OID’s) 34
4.8 Special considerations when using X12 standards 35
5 Additional Information (Attachments)Use Cases 36
5.1 Example – Claims Attachment 36
5.1.1 Claim Attachment – Solicited Attachment Example 36
5.1.2 Claim Attachment – Unsolicited Attachment Example 37
5.2 Example – Prior Authorization Attachment 37
5.2.1 Prior Authorization Attachment – Unsolicited Attachment Example 37
5.2.2 Prior Authorization Attachment – Solicited Attachment Example 38
5.3 Example – Referral Attachment 38
5.3.1 Referral Attachment – Unsolicited Attachment Example 38
5.3.2 Referral Attachment – Solicited Attachment Example 39
5.4 Example – Notification Attachment 39
5.4.1 Notification Attachment – Unsolicited Notice of Facility Discharge with Discharge Summary Example 40
6 Important information not Previously addressed in this supplement 41
7 Obtaining New Attachment Types 43
7.1 Updates to the LOINC database 43
Appendix A — Business Requirements for requesting and submitting attachment (Metadata). 44
Appendix B — Business Requirements for request, response and acknowledgement standards. 45
Appendix C — ASC X12 Standards that satisfy the business requirements listed in Appendix a. 46
Appendix D — Use of Stylesheets 47
Appendix E — Placeholder 48
Appendix F — Information from solicited / unsolicited temporary relocated while revisions are made. 49
Table of Figures
Figure 1: Constraints format example 35
Table of Tables
No table of figures entries found.
1 Preface
1.1 Revision History
The following provides a historical view of the iterations for this document and why each major revision was made.
Date / Purpose /September 2012 / Version 1.0
2 Introduction
This guide is intended to be used in conjunction with the Consolidated CDA Templates for Clinical Notes (C-CDA ) to describe to HealthCare industry stakeholders how to implement components of the C-CDA for the purposes described in this guide in section 2.2 below.
2.1 Audience
The audiences for this supplement are implementators, such as architects and developers, responsible for the exchange of supporting/attachment information among healthcare providers (hearafter known as ‘providers’), health plans/utilication management organizations and/or their business associates(hereafter known as ‘payers’).
2.2 Purpose
This guide is intended to be used as a supplement to the C-CDA. This guide endeavors to provide guidance to implementors as they exchange supporting information typically needed by payers from providers.
Examples of Healthcare Administrative Activities requiring this supporting information include but are not limited to additional information:
· In support of a healthcare claim or encounter
· In support of healthcare services review (e.g., Prior authorizations/pre-certifications, referrals)
· Needed for post adjudicated claim audits
For the purposes of this supplement, healthcare supporting/additional information will be referred to as Attachments Information. Throughout this supplement, Healthcare Administrative Activities will include any or all of the activities listed above.
Attachments are a means of electronically exchanging supporting information to augment each of the examples above. The ultimate goal of Attachments standardization in providing structured, standardized electronic data is to enable the fully automated exchange and processing of supplemental information in the various health care activities shown above. While some processes will always require human intervention, use of fully structured attachments may significantly reduce human intervention and turnaround time for adjudication or resolution.
2.3 Scope
This supplement is limited in scope to those functions which support the exchange of healthcare information among providers and payers in support of the administrative business functions of both as identied in section 2.2 of this supplement.
This supplement is limited in focus to address primarily how to use the C-CDA to assemble clinical information into a single electronic clinical document for exchange between entities. It will also offer guidance as to how to re-associate that single clinical document with the healthcare administrative activity for which additional information was originally needed. It may describe scenario’s for those business events which could be broader than the intended scope of this supplement to assist the audience in understanding the context of how the single clinical document exchange fits into the overall picture.
While the single clincal document can exist entirely on its own, for the purposes of this supplement we will be focused on the exchanging of that document from one point to another electronically. This supplement will present examples of that exchange and may use existing standards that accomplish that exchange in those examples. However, in depicting those examples the authors of this supplement acknowledge the use of those standards as examples does not limit implementations to only those exchange standards.
This supplement is independent from the the method for exchange (i.e., transport, networking, connectivity, security/privacy).
2.4 Overview
The sections below provide historical backgroud on claim attachments as well as a description of the approach use by the AWG to develop this supplement.
2.4.1 Background
The Administrative Simplification provision of the Health Insurance Portability and Accountability Act (HIPAA) of 1996 mandated the use of named health care electronic data interchange standards for the electronic conveyance of health care data that meets the business purposes specifically addressed under HIPAA.
The Centers for Medicare and Medicaid Services (CMS) worked with Health Plans and key industry stakeholders to identify the types of attachments needed by the health care industry. This group also worked with the ASC X12 Standard Development Organizations (SDO’s) to define an electronic transaction that could be used to support the request for Attachment information. The X12 277 transaction was the most viable option. It was also determined that a proposed claims attachment standard combining the standards development efforts of the Accredited Standards Committee (ASC) X12N and Health Level Seven (HL7) would be the best option to support sending the attachment information. The proposed solution was the X12 275 transaction along with the Health Level 7 (HL7) embedded within the BDS/Binary segment.
It was evident, that while the health care industry continues to evolve technically, in many cases they still rely heavily on paper based or imaged (scanned) health records for attachment data. Many health care delivery systems were not capable of providing discreet codified data. In addition, the health care industry like many other industries were moving towards using newer technologies such as Extensible Markup Language (XML) to transfer data. As all of this was occurring in the industry, parallel efforts within the HL7 organization brought forth the Clinical Document Architecture (CDA) - the first ANSI-accredited XML-based standard in the healthcare industry
The industry identified the following attachment types as the most widely used within the industry: Rehabilitation Services (10 separate disciplines), Clinical Reports, Laboratory Results, Ambulance, and Medications. The content of the attachment data for each type was documented in the Additional Information Specifications (AIS) developed by HL7. While recognizing that these five attachments did not represent all attachment data needed by the health care industry, the workgroups developing the attachments chose these based on industry outreach and estimated that these attachments comprise the majority of the attachment volume required by payers today.
2.4.2 Approach
With the advent of “Meaningful Use” and its clinical document exchange requirements between providers and other legally permitted entities, along with it’s similarity to the business model for clinical document exchange previously described in the Attachments model, a re-assessment of the attachments model was undertaken. It revealed that the C-CDA would to be the standard for this exchange, and that the content found in the C-CDA is largely consistent with that needed for Attachments purposes.
After much discussion, the AWG determined that it was not in the best interest of providers and/or their vendors to support multiple formats for this exchange based on the recipient. Rather than one standard format for the provider-to-provider information exchange and another (i.e., the original Additional Information Specifications) for provider-to-payer information exchange, the AWG agreed to adapt their approach to leverage and be consistent with that of the C-CDA with respect to formatting of clinical documentation.
The AWG then performed a gap analysis between the C-CDA content and that found in the AIS content. The AIS’s were the original Attachments specifications. Information needed for purposes described in section 2.2 that was present in the AIS but not in the C-CDA was identified and passed to the Structured Document Work Group for inclusion into the C-CDA. In some cases, this resulted in the addition of information from the original AIS to the C-CDA. Information present in the C-CDA but not in the AIS was evaluated and found to be acceptable for the purposes of claims attachments. The result was information from the original additional information specifications being added to the C-CDA.
The C-CDA was intended to have a broad industry footprint and not to be implementation specific. Information specific to implementations as described in section 2.2 is not included in the C-CDA. This supplement was created to capture the Attachments specifications not available in the C-CDA.
2.5 Organization of This Guide
PLACE HOLDER (complete when guide finalized)
2.6 Additional Attachment Information - Request and Response
Typically, in the course of doing business payers will need additional information from a provider to determine if the level of service being performed or requested is consistent with the patient’s insurance benefits. Payers also have general medical policies established that must be checked for consistency with the patients insurance benefits.
It is important to note that in all cases the request for additional attachment information comes in one of two forms, electronic or non-electronic. This supplement takes no position regarding the requirement to use electronic requests or responses, rather it simply addresses what information in a standardized format is to be exchanged when electronic requests or responses are used. However, while this supplement by necessity must define the complete attachment activity scenario, it only addresses attachment scenarios where a standard electronic response is involved.