CDAR2 IG Supplement to IHE Consolidated Templated Guide



AS_CDATEMPGD_R2_INFORM_2015DEC HL7 Attachment Supplement Specification:Exchange Implementation Guide Release 1For use with:Consolidated CDA Templates for Clinical Notes, Release 2HL7 Implementation Guides for CDA? Release 2: Consolidated CDA Templates for Clinical Notes Volume 1 Introductory Material orAdditional CDA R2 Templates – Clinical Documents for Payers – Set 1DEC 2015HL7 Informative Document: BallotSponsored by:Attachments Work GroupDurwin Day, Co-Editor/CoChairCraig Gabron, Co-Editor/CoChairRobert Dieterle, Co-Editor Deborah Meisner, Co-EditorLaurie Burckhardt, Co-EditorCopyright ? 2015 Health Level Seven International ? ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 International and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.Important Notes:HL7 licenses its standards and select IP free of charge. If you did not acquire a free license from HL7 for this document, you are not authorized to access or make any use of it. To obtain a free license, please visit HYPERLINK "" you are the individual that obtained the license for this HL7 Standard, specification or other freely licensed work (in each and every instance "Specified Material"), the following describes the permitted uses of the Material.A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and agree to the terms of HL7’s license, are authorized, without additional charge, to read, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part without paying license fees to HL7.? INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional items of Special Material in whole or part, into products and services, or to enjoy additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS as noted below, must become ORGANIZATIONAL MEMBERS of HL7.B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7's License, are authorized, without additional charge, on a perpetual (except as provided for in the full license terms governing the Material), non-exclusive and worldwide basis, the right to (a) download, copy (for internal purposes only) and share this Material with your employees and consultants for study purposes, and (b) utilize the Material for the purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant patent and other intellectual property rights of third parties (which may include members of HL7). No other license, sublicense, or other rights of any kind are granted under this Agreement. C. NON-MEMBERS, who register and agree to the terms of HL7’s IP policy for Specified Material, are authorized, without additional charge, to read and use the Specified Material for evaluating whether to implement, or in implementing, the Specified Material, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part. NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part, into products and services, or to enjoy the additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS, as noted above, must become ORGANIZATIONAL MEMBERS of HL7.Ownership. Licensee agrees and acknowledges that HL7 owns all right, title, and interest, in and to the Materials. Licensee shall take no action contrary to, or inconsistent with, the foregoing. Licensee agrees and acknowledges that HL7 may not own all right, title, and interest, in and to the Materials and that the Materials may contain and/or reference intellectual property owned by third parties (“Third Party IP”). Acceptance of these License Terms does not grant Licensee any rights with respect to Third Party IP. Licensee alone is responsible for identifying and obtaining any necessary licenses or authorizations to utilize Third Party IP in connection with the Materials or otherwise. Any actions, claims or suits brought by a third party resulting from a breach of any Third Party IP right by the Licensee remains the Licensee’s liability. Following is a non-exhaustive list of third-party terminologies that may require a separate license: Following is a non-exhaustive list of third-party terminologies that may require a separate license: TerminologyOwner/ContactCurrent Procedures Terminology (CPT) code setAmerican Medical Association CTInternational Healthcare Terminology Standards Developing Organization (IHTSDO) HYPERLINK "" or info@Logical Observation Identifiers Names & Codes (LOINC)Regenstrief InstituteInternational Classification of Diseases (ICD) codesWorld Health Organization (WHO) Table of Contents TOC \o "1-3" 1Important Notes: PAGEREF _Toc436739965 \h 23Preface PAGEREF _Toc436739966 \h 8101.1Revision History PAGEREF _Toc436739967 \h 8101.2Acknowledgements PAGEREF _Toc436739968 \h 8102Introduction PAGEREF _Toc436739969 \h 9112.1Audience PAGEREF _Toc436739970 \h 9112.2Purpose PAGEREF _Toc436739971 \h 9112.3Scope PAGEREF _Toc436739972 \h 10122.4History PAGEREF _Toc436739973 \h 10122.5Approach PAGEREF _Toc436739974 \h 11133Background PAGEREF _Toc436739975 \h 12143.1Essential Reference Material PAGEREF _Toc436739976 \h 12143.2Understanding C-CDA PAGEREF _Toc436739977 \h 12143.2.1Clinical Document Architecture (CDA) PAGEREF _Toc436739978 \h 12143.3ISO Object Identifiers (OID’s) PAGEREF _Toc436739979 \h 13153.4Structured/Unstructured Content PAGEREF _Toc436739980 \h 14163.4.1Structured Content PAGEREF _Toc436739981 \h 15173.4.2Unstructured Content PAGEREF _Toc436739982 \h 15173.5Content Types PAGEREF _Toc436739983 \h 16183.6Base 64 Encoding Content PAGEREF _Toc436739984 \h 16183.6.1Standard for Base 64 Encoding PAGEREF _Toc436739985 \h 16183.6.2Uses of Base 64 Encoding PAGEREF _Toc436739986 \h 17193.6.3Base 64 Encoding Examples PAGEREF _Toc436739987 \h 17194AttachmentS -- generaL PAGEREF _Toc436739988 \h 17194.1Attachment Exchange PAGEREF _Toc436739989 \h 17194.1.1Solicited and Unsolicited Attachments PAGEREF _Toc436739990 \h 17194.1.2Request Attachment Activity PAGEREF _Toc436739991 \h 18204.1.3Response Attachment Activity PAGEREF _Toc436739992 \h 19214.1.4Understanding Attachment Activities PAGEREF _Toc436739993 \h 20224.1.5Attachment Request/Response Re-Association using Attachment IDAttachment Unique ID PAGEREF _Toc436739994 \h 25274.2Standards to Accomplish Information Exchange of The Request and Response PAGEREF _Toc436739995 \h 27295LOINC (Logical observation identifiers name and codes) PAGEREF _Toc436739996 \h 28305.1Use of LOINC for Attachments PAGEREF _Toc436739997 \h 28305.1.1Obtaining LOINC and Other Resources From the Regenstrief Institute PAGEREF _Toc436739998 \h 29315.2Using the LOINC Code As An Identifier In Messages PAGEREF _Toc436739999 \h 30325.3Using the LOINC Database to Identify Valid Attachment Types PAGEREF _Toc436740000 \h 30325.3.1Identifying Valid Attachment Types In The LOINC Table PAGEREF _Toc436740001 \h 30325.3.2Identifying Valid Attachment Types Using RELMA and The Online LOINC Search Application () PAGEREF _Toc436740002 \h 31335.4Requesting LOINC Codes for New Attachment Types PAGEREF _Toc436740003 \h 33355.4.1Process for Requesting New Attachment Types PAGEREF _Toc436740004 \h 33355.4.2Updates to the LOINC database PAGEREF _Toc436740005 \h 33356Requesting/responding/submitting attachments PAGEREF _Toc436740006 \h 34366.1Unsolicited Attachment Exchange PAGEREF _Toc436740007 \h 34366.1.1Unsolicited Attachments with Claims Submission PAGEREF _Toc436740008 \h 34366.1.2Unsolicited Attachments with Prior Authorizations PAGEREF _Toc436740009 \h 34366.1.3Unsolicited Attachments with Notifications PAGEREF _Toc436740010 \h 34366.1.4Use of LOINC codes with Unsolicite Attachments PAGEREF _Toc436740011 \h 34366.2Solicited Attachment Exchange PAGEREF _Toc436740012 \h 34366.2.1Request and Response for Claims Submission PAGEREF _Toc436740013 \h 34366.2.2Request and Response for Prior Authorizations PAGEREF _Toc436740014 \h 34366.2.3Use of LOINC codes with Request and Response for Attachments PAGEREF _Toc436740015 \h 34366.2.4Using “Modifier LOINC Codes” to constrain the Request PAGEREF _Toc436740016 \h 34366.3Solicited Attachment Exchange PAGEREF _Toc436740017 \h 35376.4Requesting/Responding/Submitting Attachments PAGEREF _Toc436740018 \h 35376.4.1Using LOINC Code to Request/Respond Attachment (Solicited) PAGEREF _Toc436740019 \h 35376.4.2Using LOINC Code to Submit Attachments (Unsolicited) PAGEREF _Toc436740020 \h 37396.4.3Using “Modifier LOINC Codes” to Constrain The Request PAGEREF _Toc436740021 \h 37397Attachment Use Cases PAGEREF _Toc436740022 \h 39417.1Example – Claim Attachment PAGEREF _Toc436740023 \h 39417.1.1Claim Attachment – Solicited Attachment Example PAGEREF _Toc436740024 \h 39417.1.2Claim Attachment – Unsolicited Attachment Example PAGEREF _Toc436740025 \h 40427.2Example – Prior Authorization Attachment PAGEREF _Toc436740026 \h 41437.2.1Prior Authorization Attachment – Solicited Attachment Example PAGEREF _Toc436740027 \h 41437.2.2Prior Authorization Attachment – Unsolicited Attachment Example PAGEREF _Toc436740028 \h 42447.3Example – Referral Attachment PAGEREF _Toc436740029 \h 42447.3.1Referral Attachment – Solicited Attachment Example PAGEREF _Toc436740030 \h 42447.3.2Referral Attachment – Unsolicited Attachment Example PAGEREF _Toc436740031 \h 43457.4Example – Notification Attachment PAGEREF _Toc436740032 \h 45477.4.1Notification Attachment – Unsolicited Notice of Facility Discharge with Discharge Summary Example PAGEREF _Toc436740033 \h 45477.5Example – Post Adjudicated Claim Attachment PAGEREF _Toc436740034 \h 46487.5.1Post Adjudicated Claim Attachment – Solicited Attachment Example PAGEREF _Toc436740035 \h 46488Important information not Previously addressed in this supplement PAGEREF _Toc436740036 \h 4850Appendix A —Definitions, Abbreviations and acronyms. PAGEREF _Toc436740037 \h 5052Appendix B —Consolidated Clinical Document Architecture Release 2.1 (C-CDA R2.1). PAGEREF _Toc436740038 \h 5254B.1 Overview of Implementation Guide PAGEREF _Toc436740039 \h 5254B.2 Document Templates PAGEREF _Toc436740040 \h 5254B.3 LOINC Codes PAGEREF _Toc436740041 \h 5254What are C-CDA Document Types? PAGEREF _Toc436740042 \h 5355Appendix C —Clinical Documents for Payers – Set 1 Release 1.1 (CDP1 R1.1). PAGEREF _Toc436740043 \h 5658C.1 Overview of Implementation Guide PAGEREF _Toc436740044 \h 5658C.2 Document Templates PAGEREF _Toc436740045 \h 5658C.3 LOINC Codes PAGEREF _Toc436740046 \h 5658What are C-CDA Document Types? PAGEREF _Toc436740047 \h 5759Appendix D —C-CDA Document Transport and payload PAGEREF _Toc436740048 \h 6062D.1 Transport Options PAGEREF _Toc436740049 \h 6062D.2 Metadata requirements PAGEREF _Toc436740050 \h 6062D.3 Overview of X12 (real-time) PAGEREF _Toc436740051 \h 6163D.3.1 Security Metadata PAGEREF _Toc436740052 \h 6163D.3.2 Error Handling PAGEREF _Toc436740053 \h 6163D.4 Overview of a payload over CONNECT with ASC X12N Message PAGEREF _Toc436740054 \h 6264D.4.1 ASC X12N 275 over CONNECT (CORE) PAGEREF _Toc436740055 \h 6264D.4.2 CONNECT SAML Assertions PAGEREF _Toc436740056 \h 6466D.4.3 IHE XD* Metadata PAGEREF _Toc436740057 \h 6466D.5 Overview of a payload over CONNECT with XDR PAGEREF _Toc436740058 \h 6466D.5.1 esMD Security Metadata PAGEREF _Toc436740059 \h 7173D.5.2 Error Handling PAGEREF _Toc436740060 \h 7173D.6 Overview of payload over Direct (X12 Message) PAGEREF _Toc436740061 \h 7173D.6.1 Overview of payload over Direct PAGEREF _Toc436740062 \h 7274Appendix E —ASC X12N Standards transaction and error flow PAGEREF _Toc436740063 \h 7476Appendix F —Fast Healthcare Interoperability Resources (FHIR) PAGEREF _Toc436740064 \h 7678F.1 What is FHIR PAGEREF _Toc436740065 \h 7678F.2 Introduction to FHIR Resources PAGEREF _Toc436740066 \h 7678F.3 Use of FHIR to solict and exchange Attachments PAGEREF _Toc436740067 \h 7678Table of Figures TOC \h \z \c "Figure" HYPERLINK \l "_Toc436740068" Figure 1: Example - Claims Attachment (Solicited) PAGEREF _Toc436740068 \h 4042 HYPERLINK \l "_Toc436740069" Figure 2: Example – Claims Attachment (Unsolicited) PAGEREF _Toc436740069 \h 4042 HYPERLINK \l "_Toc436740070" Figure 3: Example – Prior Authorization (Solicited) PAGEREF _Toc436740070 \h 4143 HYPERLINK \l "_Toc436740071" Figure 4: Example – Prior Authorization (Unsolicited) PAGEREF _Toc436740071 \h 4244 HYPERLINK \l "_Toc436740072" Figure 5: Example – Referral Attachment (Solicited) PAGEREF _Toc436740072 \h 4345 HYPERLINK \l "_Toc436740073" Figure 6: Example – Referral Attachment (Unsolicited) PAGEREF _Toc436740073 \h 4446 HYPERLINK \l "_Toc436740074" Figure 7: Example – Notification Attachment (Unsolicited) PAGEREF _Toc436740074 \h 4648 HYPERLINK \l "_Toc436740075" Figure 8: Example – Post Adjudicated Claim Attachment (Solicited) PAGEREF _Toc436740075 \h 4648 HYPERLINK \l "_Toc436740076" Figure 71: X12 (real-time) PAGEREF _Toc436740076 \h 6163 HYPERLINK \l "_Toc436740077" Figure 72: CONNECT with ASC X12N Specification PAGEREF _Toc436740077 \h 6365 HYPERLINK \l "_Toc436740078" Figure 73: CONNECT w/ X12 275 PAGEREF _Toc436740078 \h 6567 HYPERLINK \l "_Toc436740079" Figure 74: Direct Message PAGEREF _Toc436740079 \h 7274 HYPERLINK \l "_Toc436740080" Figure 75: Direct Message PAGEREF _Toc436740080 \h 7274Table of Tables TOC \h \z \c "Table" HYPERLINK \l "_Toc436740081" Table 1: Request Attachment Activity Table PAGEREF _Toc436740081 \h 1820 HYPERLINK \l "_Toc436740082" Table 2: ASC X12N Attachments Activity Table PAGEREF _Toc436740082 \h 2224 HYPERLINK \l "_Toc436740083" Table 3: Attachments ID Re-association Table PAGEREF _Toc436740083 \h 2628 HYPERLINK \l "_Toc436740084" Table 4: Request and Response LOINC Code Usage for Solicited Structured Attachments PAGEREF _Toc436740084 \h 3638 HYPERLINK \l "_Toc436740085" Table 5: Time Window Modifier LOINC Codes PAGEREF _Toc436740085 \h 3840 HYPERLINK \l "_Toc436740086" Table 71: XD* Submission Set Metadata PAGEREF _Toc436740086 \h 6668 HYPERLINK \l "_Toc436740087" Table 72: XD* Document Entry Metadata PAGEREF _Toc436740087 \h 6769PrefaceRevision HistoryThe following provides a historical view of the iterations for this document and why each major revision was made. DatePurposeJanuary 2015Version 1.0March 10, 2015Version 1.1 Updated references to C-CDA and CDP1 RCDNov 23, 2015Version 2.0 Change Attachment useNovember 30,2015Version 3.2 move CDP1 and C-CDA Rx to Appendices, Move defn .. to appendix, reorganize base on new outlineAcknowledgementsThe writers and editors of the HL7 Attachment Supplement Specification: Exchange Implementation Guide Release 1 this document want to acknowledge those who have provided years of hard work and dedicated efforts to bring forward the research and development needed to achieve the goal of information exchange amongst the healthcare industry stakeholders. This includes the years of hard work and dedicated efforts of the current and past members of the Attachments Special Interest Group (ASIG), the Structured Documents andthe Attachments Work Groups at HL7(formerly the Attachments Special Interest Group (ASIG)) in building forward the research and development needed to achieve the goal of information exchange amongst the provider community and health plans/healthcare insurance companies. and the Structured Documents Workgroup at HL7.The information needs of the industry that were identified and developed over the years became key input into the foundational content found in the HL7 Implementation Guides for CDA? Release 2: Consolidated CDA Templates for Clinical Notes Volume 1 Introductory Material and Volume 2 Templates and Supporting Material . The information needs of the industry that were identified and developed over the years became key input into the foundational content found in the HL7 Implementation Guides for CDA Release 2: Consolidated CDA Templates for Clinical Notes Volume 1 Introductory Material and Volume 2 Templates and Supporting Material and Additional CDA R2 Templates – Clinical Documents for Payers – Set 1. These standards are expected to be widely used in the exchange of clinical information between providers as well as between 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? ( HYPERLINK "" ). The LOINC table, LOINC codes, and LOINC panels and forms file are copyright ? 1995-2015, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and are available at no cost under the license at HYPERLINK "" . ?Introduction The HL7 Attachment Supplement Specification: Exchange Implementation Guide Release 1 (hereafter referred to as “This Supplement”)This guide is intended to be used in conjunction with the HL7 Implementation Guides for CDA? Release 2: Consolidated CDA Templates for Clinical Notes Volume 1 Introductory Material and Volume 2 Templates and Supporting Material (hereafter referred to as C-CDA R2 in this guide) and Additional CDA R2 Templates – Clinical Documents for Payers – Set 1 (referred to as CDP1 in this guide) to describe to HealthCare industry stakeholders how to implement components of the C-CDA R2 and CDP1 for the purposes described in this guide in section 2.2 below. C-CDA Implementation Guides will jointly refer to C-CDA R2, CDP1 and other CDA implementation guides based on C-CDA R2. The combined set of document level templates defined in the C-CDA Implementation Guides will be referred to as C-CDA Documents in this guide.This guide will serve to direct implementers to the appropriate HL7 implementation standard used to format the content based on the clinical document being exchanged as an Attachment. Refer to the Sections 3.0 & 4.0 in the C-CDA Implementation Guides for additional information regarding levels of constraint, conformance statements, conformance verbs, cardinality, vocabulary conformance, and null flavor. AudienceThe audience for this Supplement this supplement are is implementers (such as architects and implementation developers) responsible for the exchange of Attachments between healthcare providers (hereafter known as ‘providers’), and health plans/utilization management organizations and/or their business associates (hereafter known as ‘payers’).PurposeThis Supplement is intended to be used along with the C-CDA Implementation Guides and provides guidance to implementers as they develop the means for exchanging supporting information as defined in section HYPERLINK \l "_Scope" 2.3.This Supplement will serve to direct implementers to the appropriate HL7 implementation standard used to format the content based on the clinical document being exchanged as an Attachment. Refer to the Sections 3.0 & 4.0 in the C-CDA Implementation Guides for additional information regarding levels of constraint, conformance statements, conformance verbs, cardinality, vocabulary conformance, and null flavor. This guide is intended to be used as a supplement to the C-CDA Implementation Guides. It provides guidance to implementers as they exchange additional supporting information needed amongst payers.This Supplement is independent of the the method for exchange (e.g., transport, networking, connectivity, security/privacy).This Supplement will refer to healthcare supporting/additional information as Attachments. Additionally, a healthcare claim or encounter may be referred to as a Claim without mention of encounter and Healthcare Administrative Activities will include any or all of the activities as defined in section HYPERLINK \l "_Scope" 2.3. Examples of Healthcare Administrative Activities requiring this supporting information include, but are not limited to, Attachments in suport of:a healthcare claim or encounterhealthcare services review (e.g., prior authorizations/precertifications, referrals)post adjudicated claim audits For the purposes of this supplement, healthcare supporting/additional information will be referred to as Attachments. Additionally, a healthcare claim or encounter may be referred to as a Claim without mention of encounter. 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 healthcare 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. ScopeThis Supplement is limited in focus to use of the C-CDA Documents to exchange clinical information between entities in a single electronic clinical document. Examples of that exchange using existing standards are included, however, use of those standards as examples does not limit implementations to only those exchange standards.This Supplement will also offer guidance for re-associating that single clinical document with the healthcare administrative activity for which additional information was originally needed. This supplement Supplement is limited in scope to those functions which support the exchange of healthcare information between providers and payers in support of the administrative business functions of both. as identified in HYPERLINK \l "_Purpose" section 2.2 of this Examples of Healthcare Administrative Activities requiring this supporting information include, but are not limited to:healthcare claim or encounterhealthcare services review (e.g., prior authorizations/precertifications, referrals)post adjudicated claim audits supplement.This supplement is limited in focus to use of the C-CDA Documents to exchange clinical information between entities in a single electronic clinical document. This may already exist as is, or need to be created for this exchange.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 scenarios 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 clinical document can exist entirely on its own, this supplement will focus on the electronic exchange of that document from one point to another. This supplement will present examples of that exchange using existing standards, however, use of those standards as examples does not limit implementations to only those exchange standards.This supplement is independent of the the method for exchange (e.g., transport, networking, connectivity, security/privacy).History The Administrative Simplification provision of the Health Insurance Portability and Accountability Act (HIPAA) of 1996 mandated the use of named healthcare electronic data interchange standards for the electronic conveyance of healthcare data that meets the business purposes specifically addressed under HIPAA. An NPRM was issued in 2005, but was withdrawn before a final rule was generated. In 2010, the Patient Protection and Affordable Care Act (PPACA) re-instituted the original requirement under HIPAA for Attachments.The Centers for Medicare & Medicaid Services (CMS) worked with Payers and key industry stakeholders to identify the types of ttachments needed by the healthcare industry. This group also worked with the Accredited Standards Committee (ASC) X12N Standard Development Organization (ASC X12N) to define an electronic transaction that could be used to support the request for Attachments. The ASC X12N 277 Health Care Information Status Notification Transaction and the ASC X12N 275 Patient Information transaction were the most viable ASC X12N options. It was also determined that a proposed claims attachment standard combining the standards development efforts of ASC X12N and Health Level Seven (HL7) would be one of the possible options to support sending the Attachment. The proposed ASC X12N solution was the ASC X12N 275 Patient Information Transaction with the HL7 Clinical Document embedded within the BDS/Binary segment. It was evident, that while the healthcare industry continues to evolve technically, in many cases it still relies heavily on paper based or imaged (scanned) health records for Attachment. Many healthcare delivery systems were not capable of providing discrete codified data. In addition, the healthcare industry like many other industries was 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.ApproachThe Attachment Work Group (AWG) worked with payers and other industry stakeholders to identify the types of attachments needed to support claims and prior authorization of healthcare services. The AWG collaborated with the Accredited Standards Committee (ASC) X12N Standard Development Organization (ASC X12) to define an electronic transaction that could be used to support the request for Attachments. The ASC X12 277 Health Care Information Status Notification Transaction Set was the most viable ASC X12 option. The AWG determined that a proposed claims attachment standard combining the standards development efforts of ASC X12 and Health Level Seven (HL7) would be one of the possible options to support sending an Attachment. The proposed solution was the ASC X12 275 Patient Information Transaction Set with the HL7 Clinical Document embedded within the BDS/Binary segment. With the advent of “Meaningful Use” and its clinical document exchange requirements between providers and other legally permitted entities, along with its 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 content found in the C-CDA (the standard named for Meaningful Use) is largely consistent with that needed for attachments purposes.After much discussion, tThe AWG determined that it was not in the best interest of providers and/or their vendors to support multiple only one formats way for theis exchange of the clinical information. based on the recipient. Rather than one standard format for the provider-to-provider information exchange and another (e.g., the original Additional Information Specification (AIS)) 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 the AIS content for each transaction type. Information needed for purposes described in HYPERLINK \l "_Purpose" section 3.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, the result was information from the original AIS’s being added to the C-CDA, and are now identified by their corresponding clinical document (Attachment) types (see HYPERLINK \l "_What_are_C-CDA" section 4.3). In other cases, the information was deemed not necessary or present in the claim transaction (e.g., Ambulance).Information present in the C-CDA but not in the AIS was evaluated and found to be acceptable for the purposes of Attachments. The C-CDA Documents are intended to have a broad industry footprint and not to be implementation specific. Information specific to implementations as described in HYPERLINK \l "_Purpose" section 3.2 is not included in the C-CDA. This supplement was created to capture the Attachments specifications not available in the C-CDA. The C-CDA Documents by themselves do not fully satisfy the needs of the industry for Attachment sinformation exchange. Additional metadata/enveloping is needed to assist in the correct pairing with a healthcare administrative activity and the Attachment itself. For this purpose, the Insurance Subcommittee of ASC X12N (ASC X12N) had developed a suite of Technical Report Type 3 (TR3) documents for use with the original AIS’Attachments. Throughout this Ssupplement, references and examples of Attachment activity may cite specific ASC X12N TR3s previously developed for this purpose, however there is no intent by the authors of this Ssupplement to limit those metadata/enveloping standards. to those provided by ASC X12N, and is provided for example purposes only.Background Essential Reference Material Insert esential refernce material here Understanding C-CDA This Section will explain the C-CDA Implementaiton Guides at a high level. Implementers should rely on the detail found in the individual guides to understand how to utilize each Standard. Relationship of standards and Implementation GuidesFigure SEQ Figure \* ARABIC1: Relationship Of Standards and IGs208429134881XML (W3C Standard)RIM Consolidated CDA IG R1.1 (DSTU)CDP1 IG (DSTU) Consolidated CDA IG R2 (DSTU)Attachments Work Group Supplemental IG (Informative) ASN X12N6020277/275 IGASN X12N6020 278/275 IGLOINC (Regenstrief)Future IGsCDA R2 IG00XML (W3C Standard)RIM Consolidated CDA IG R1.1 (DSTU)CDP1 IG (DSTU) Consolidated CDA IG R2 (DSTU)Attachments Work Group Supplemental IG (Informative) ASN X12N6020277/275 IGASN X12N6020 278/275 IGLOINC (Regenstrief)Future IGsCDA R2 IGThe HL7 Clinical Document Architecture Release 2 (CDA R2) is based on the HL7 Reference Information Model and the W3C XML standard. Release 1.1 and 2 of the Consolidated CDA are both based on CDA R2 and are designated C-CDA R1.1 and C-CDA R2 respectively. This document, the Clinical Documents for Payers – Set 1 (CDP1), incorporates, by reference, many of the C-CDA R2 templates. C-CDA R1.1 is DSTU. C-CDA R2 and CDP1 are balloted as DSTU. The Attachments Work Group created a Supplemental Implemenation Guide to describe how a payer requests a C-CDA document by LOINC code from a provider using an ANS X12N 277 or 278 transaction and receives it using the ASN X12N 275 transaction. This supplemental guide is an Informative Guide. Understanding C-CDA This Section will explain the C-CDA Implementaiton Guides at a high level. Implementers should rely on the detail found in the individual guides to understand how to utilize each Standard. Clinical Document Architecture (CDA)The HL7 Version 3 Clinical Document Architecture (CDA?) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange between healthcare providers and patients. It defines a clinical document as having the following six characteristics: 1) Persistence, 2) Stewardship, 3) Potential for authentication, 4) Context, 5) Wholeness and 6) Human readability.A CDA can contain any type of clinical content -- typical CDA documents would be a Discharge Summary, Imaging Report, Admission & Physical, Pathology Report and more. The most popular use is for inter-enterprise information exchange, such as is envisioned for a US Health Information Exchange (HIE).CDA is a document markup standard that specifies the structure and semantics of a clinical document (such as a discharge summary or progress note) for the purpose of exchange. A CDA document is a defined and complete information object that can include text, images, sounds, and other multimedia content. It can be transferred within a message and can exist independently, outside the transferring message. CDA documents are encoded in Extensible Markup Language (XML), and they derive their machine processable meaning from the RIM (HL7’s Reference Information Model), coupled with terminology. The CDA R2 model is richly expressive, enabling the formal representation of clinical statements (such as observations, medication administrations, and adverse events) such that they can be interpreted and acted upon by a computer. On the other hand, CDA R2 offers a low bar for adoption, providing a mechanism for simply wrapping a non-XML document with the CDA header or for creating a document with a structured header and sections containing only narrative content. The intent is to facilitate widespread adoption, while providing a mechanism for incremental semantic interoperability. Information about the components for CDA is being presented at a high level and is intended to convey only what is necessary for the implementer to understand the application with respect to Attachments. Refer to the C-CDA Implementation Guides for technical guidance on implementation of CDA for Attachments. A CDA document has two primary groupings of information, a header and a body:The header (See Section 2.1 US Realm Header (V2) in the CDA R2 Volume 2 – Templates and Supporting Material for more detail)Identifies and classifies the document and pProvides information on authentication, the encounter, the patient, and the involved providers. Note: the header will always be populated to the specifications in C-CDA R2 or CDP1 whether the attachment isThe body Contains the clinical report, organized into sections whose narrative content can be encoded using standard vocabularies.Can be represented using a nonXMLBody or a structuredBody element. nonXMLBody is used when the content is an external file such as a TIFF image, MS RTF document, PDF, etc. The NonXMLBody class is provided for those applications that can do no more than simply wrap an existing non-XML document with the CDA Header. structuredBody is used when the body will be XML structured content. XML structured content is always inserted into the structuredBody element, never as an external file. The StructuredBody contains one or more Section components.For the purposes of this Supplementthis supplement: A header paired with a structuredBody element will be referred to as a “Structured Document”. A header paired with a nonXMLBody element will be referred to as an “Unstructured Document”.More information about CDA can be found on the HL7 website ( HYPERLINK "" ).Consolidated Clinical Documentation Architecture (C-CDA)The Consolidated Templated implementation guide contains a library of CDA templates, incorporating and harmonizing previous efforts from Health Level Seven (HL7), Integrating the Healthcare Enterprise (IHE), and Health Information Technology Standards Panel (HITSP). It represents harmonization of the HL7 Health Story guides, HITSP C32, related components of IHE Patient Care Coordination (IHE PCC), and Continuity of Care (CCD), and it includes all required CDA templates in HYPERLINK "" Final Rules for Stage 1 Meaningful Use?and? HYPERLINK "" 45 CFR Part 170 – Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology; Final Rule.The Consolidated CDA was produced and developed through the joint efforts of Health Level Seven (HL7), Integrating the Healthcare Environment (IHE), the Health Story Project, and the Office of the National Coordinator (ONC) within the US Department of Health and Human Services (HSS).The project was carried out within the ONC’s Standards and Interoperability (S&I) Framework as the Clinical Document Architecture (CDA) Consolidation Project with a number of goals, one of which is providing a set of harmonized CDA templates for the US Realm.In the development of the Consolidated Templates specification, the Consolidation Project team reviewed the eight existing HL7 Health Story guides, CCD, and the additional constraints from IHE, HITSP and Stage 1 Meaningful Use.The Consolidation Project team members completed the analysis by creating a fully compliant CCD document, then layering in the additional HITSP, IHE and Stage 1 Meaningful Use constraints. When a new constraint introduced an issue, conflict or ambiguity, the item was flagged for review with the full consolidation team. The full analysis covered the CDA Header, section-level and entry-level requirements sufficient for Stage 1 Meaningful Use. The Project also reviewed document and section-level requirements for the full set of document types.ISO Object Identifiers (OID’s)OID is an acronym, used throughout HL7 specifications to mean ISO object identifier. ISO is the International Organization for Standardization (), and we will see below that the International Telecommunications Union (ITU, ) is also relevant. The HL7 OID registry, mentioned below, can be used to find, or create, OIDs for use in attachment implementations; and the mention of ISO and ITU is for background information only. The CDA uses OIDs to uniquely specify where to find more information regarding a coded data value or an identifier for a person, organization, or other entity.An OID is a globally unique string consisting of numbers and dots (e.g., 2.16.840.1.113883.6.1032.16.840.1.113883.6.260). This string expresses a tree data structure, with the left-most number representing the root and the right-most number representing a leaf.Each branch under the root corresponds to an assigning authority. Each of these assigning authorities may, in turn, designate its own set of assigning authorities that work under its auspices, and so on down the line. Eventually, one of these authorities assigns a unique (to it as an assigning authority) number that corresponds to a leaf node on the tree. OID’s present a systematic way to identify the organization responsible for issuing a code or entity identifier. HL7 is an assigning authority, and has the OID prefix "2.16.840.1.113883." broken down as follows: (2)represents the OID was assigned by a joint ISO-ITU (16)represents assigning authority which is specific to the country (840)reflects the USA (1)is specific to the organization (113883) represents Health Level Seven (as the assigning authority).Any OID that begins with this is further described by a registry maintained by the HL7 organization. For example, the OID 2.16.840.1.113883.6.2602.16.840.1.113883.6.103 (above) was established by HL7 as a globally unique identifier for the ICD-910-CM code set for diagnoses. Beyond that, the HL7 organization assigns any numbers - and these are maintained in a registry available on the website. HL7 uses its registry to assign OIDs within its branch for HL7 users and vendors upon their request. HL7 is also assigning OIDs to public identifier-assigning authorities both U.S. nationally (e.g., the U.S. State driver license bureaus, U.S. Social Security Administration, US National Provider Identifier (NPI) registry, etc.) and internationally (e.g., other countries' social security administrations, citizen ID registries) Additional reference information about OIDs, including the current directory of OIDs assigned by HL7, is available at . Organizations that wish to request an OID for their own use (e.g., to be able to create identifiers within a CDA document), may also obtain one from HL7 at this site.Structured/Unstructured Content Use of the CDA standard allows for a wide-range of implementation flexibility with respect to the implementer’s (CDA originator and consumer) technical abilities. For most implementers, a CDA document may simply be rendered to a common internet XML aware browser using a stylesheet, much like one might view a PDF on a personal computer application. Even in an unstructured document <nonXMLBody>, the Header may be partially rendered using a stylesheet. However, when exchanging information using the unstructured document, this mechanism may not work without additional engineering. The body of this document must either be made referenceable by the browser in a URL schema it recognizes, or separately decoded into its binary format. ?In the instance where the body type is in an Unstructured Document and the body content contains a media type (e.g., JPEG, GIF, PDF), that content would require additional software to interpret and render the encapsulated data using an appropriate viewer for the type of document (e.g., image viewer, adobe reader). This requires several steps, including configuring the browser to display the non-HTML content if needed (e.g., for application/pdf, application/msword or text/rtf content), linking to externally referenced content, or linking to and decoding the embedded base-64 encoded content.? In addition, considerations should be given to security concerns that might be introduced by displaying content which could include scripts.The use of a stylesheet to render a CDA document to a browser sets a low technical bar for the receiver of a CDA document. No matter what the technical level of the originator, the receiver will have the choice of leveraging the originator’s highest level of technical sophistication or simply choose to render using a stylesheet and a browser. This will enable receivers of Attachments to interpret the content of a clinical document without having to be an expert on CDA. Initially the limited capability of participants to support fully structured attachments and the need for further development of attachment content requires the use of the unstructured content capability of the C-CDA based Documents. For Attachments, even though a structured document template may be defined in C-CDA based Documents(attachment types where a document level template exists, excluding Unstructured Document), the use of the unstructured version of that document (e.g., nonXMLbody) is permitted. However, the required content defined for the equivalent structured document conformance must be present in the unstructured (nonXMLbody) document representation. Structured ContentEach C-CDA Implementation Guide describes the respective document types and conformance requirements for each of the structured documents listed in Appendix F .of this supplement. Conformance criteria for each of those document types, their sections and any applicable entries are found in the appropriate section of the C-CDA Implementation Guides. Unstructured Content In addition to the structured document types described in Appendix B and Appdix C there is a document which is available to be used for exchange of ANY document type. This is the Unstructured Document (described specifically in the C-CDA Implementation Guides). In many environments much of the patient record is still captured in an unstructured format that is encapsulated within an image file or as unstructured text in an electronic file such as MSWORD or PDF.There is a need to raise the level of interoperability for these documents to provide full access to the longitudinal patient record across a continuum of care. Until this gap is addressed, image and multi-media files will continue to be a portion of the patient record that remains difficult to access and share with all participants in a patient’s care. The Unstructured Document is here to bridge that gap. The Unstructured Document:Must be at the document level and should be limited to document types defined in Regenstrief’s LOINC database “external value set” (See HYPERLINK \l "_Toc436739859" HYPERLINK ":\\Users\\Robert\\Desktop\\Supplement%20IG\\4.2.2%20Unstructured%20Content%20-%20Review%20Document.docx" \l "_Toc335251857" section 5.5.1.1Section 5.3 “Using the LOINC Database to Identify Valid Attachment Types” for more information.If a LOINC code is not available for your document type, please refer to HYPERLINK \l "_Requesting_LOINC_Codes"Section 5.4.1 Process for Requesting New Attachment Types.May include content for document types already defined in the C-CDA Documents as structured, but unstructured content should adhere to conformance statements for the Header. Supported File Formats Value Set Content Types Insert description here The following Table reflects the value set of the file formats supported by HL7 Implementation Guide for CDA?, Release 2: Unstructured DocumentsTable SEQ Table \* ARABIC 1: Supported File FormatsValue Set: SupportedFileFormats 2.16.840.1.113883.11.20.7.1A value set of the file formats supported by the Unstructured Document IG.Value Set Source: SystemCode System OIDPrint Nameapplication/mswordMedia Type2.16.840.1.113883.5.79MSWORDapplication/pdfMedia Type2.16.840.1.113883.5.79PDFtext/plainMedia Type2.16.840.1.113883.5.79Plain Texttext/rtfMedia Type2.16.840.1.113883.5.79RTF Texttext/htmlMedia Type2.16.840.1.113883.5.79HTML Textimage/gifMedia Type2.16.840.1.113883.5.79GIF Imageimage/tiffMedia Type2.16.840.1.113883.5.79TIF Imageimage/jpegMedia Type2.16.840.1.113883.5.79JPEG Imageimage/pngMedia Type2.16.840.1.113883.5.79PNG Image Base 64 Encoding Content Insert esential refernce material here Standard for Base 64 EncodingInsert description here. Uses of Base 64 EncodingInsert description here. Base 64 Encoding ExamplesInsert examples here. AttachmentS -- generaLThe HL7 Attachment Supplement SpecificationThis Supplement and the C-CDA Implementation Guides do not require a specific standard for enveloping, however the industry best practices for required metadata to be contained in that envelope are specified in HYPERLINK \l "Appendix_A" HYPERLINK \l "Appendix_A" Appendix A of this Supplement.Appendix AAttachment ExchangeTypically, 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 Attachments additional information comes in one of two forms, electronic or non-electronic. This Ssupplement 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 an electronic exchange of an Attachment is involved.Solicited and Unsolicited Attachments For the purposes of this Ssupplement, we will use the terms “solicited” and “unsolicited” to help clarify the scenarios for which one or more standards are to be used. The response, whether solicited or unsolicited, refers to the act of providing Attachments needed. Solicited and unsolicited scenarios are tied closely to the response side of the attachment activity without regard to the mode of the request. They are also aligned closely with the entity establishing the Attachment re-association ID that is used to match the attachment itself with either the claim, referral, or prior authorization attachment activity (more about Attachment re-association ID in section 3.6.5).A solicited Attachment refers to the act of requesting and/or responding with information which was requested after a healthcare entity determines a need for additional information to complete the healthcare administrative activity. An unsolicited Attachment refers to the act of providing additional information that conforms to a set of rules-based criteria invoked at the time of the submittal of a healthcare administrative activity. This information is based on advance knowledge of rules defined by the information receiver. In the solicited scenario, the entity creating the request for Attachment additional information would assign an attachment IDAttachment Unique ID used to re-associate the Attachment response to the original aAttachment request. This Attachment Unique iIdentifier must be returned with the attachment response. In the unsolicited scenario, the entity that is the source for the Attachment would assign an Attachment ID. This Attachment identifier must be provided with the Attachment to be re-associate with the healthcare administrative activity. This guide takes no position with respect to the business reasons that initiate unsolicited attachments. However, industry best practices suggest that in the absence of business rules established in advance, attachment information should not be sent. Request Attachment ActivityA request for an Attachment additional information can originate in numerous ways and may be initiated by unique triggering business events depending on the originating actor. The table below reflects some of the more common scenarios for illustrative purposes:Table SEQ Table \* ARABIC 12: Request Attachment Activity TableHealthcare Administrative ActivityRequestAttachment IDAttachment Activity BasisModeTimingAssigning ActorLinkageClaimStandard ElectronicAfter claim receipt and reviewPayerPayer request and provider responseSolicitedPhone call, US Postal Service, Patient request, etcAfter claim receipt and reviewPayerPayer request and provider responseSolicitedRules Based At time of claims submitalProviderProvider claim and Attachment submittalUnsolicitedPrior Authorization Standard ElectronicAfter prior authorization receipt and reviewPayerPayer request and provider responseSolicitedPhone call, US Postal Service, Patient request, etcAfter prior authorization receipt and reviewPayerPayer request and provider responseSolicitedRules Based At time of prior authorization requestProviderProvider Prior Authorization request and Attachment submittalUnsolicitedReferralStandard ElectronicAfter referral receipt and reviewPayerPayer request and provider responseSolicitedPhone call, US Postal Service, Patient request, etc)After referral receipt and reviewPayerPayer request and provider responseSolicitedRules Based At time of referral request NOTEREF _Ref340760114 \f \h 44ProviderProvider referral request and Attachment submittalUnsolicitedNotificationRules BasedAt the time of scheduled admission or service, actual admission or discharge, approval for Health Services ReviewProvider or PayerUnknownUnsolicitedPost Adjudicated Claim Standard ElectronicAfter claim adjudicatedPayerPayer request and provider responseSolicitedResponse Attachment ActivityThe act of exchanging Attachments from an information source to an information receiver is considered a response. The information source is considered the entity that creates the Attachment needed by the receiving entity to support the healthcare administrative activity. Understanding Attachment Activities Because this Ssupplement addresses all facets of the process in the requesting of additional information of and responding with Attachments, and because the actor’s role will vary depending on the activity type, a table (Table 2) has been developed to better illustrate these activities. Each row in the table represents a unique attachment activity that would require a unique business flow to describe that activity. Additionally, each row will call for a unique set of electronic exchange standards to be used.As described later in Section 5.1 of this supplement, there are multiple standards available in the industry to accomplish the exchange of information for attachment purposes (e.g., request, response, acknowledgement). For the purposes of this supplement, eExample scenarios and use cases will reference those standards, such as ASC X12N, previously developed to accomplish Attachments exchange for example educational purposes ONLY. Out of scope are specific standards and methods for connectivity in moving the Attachment from point to point.Table 2 (Attachments Activity Table) below describes all the scenarios addressed by this supplement for attachment exchange purposes. Column headings and table values are described below:Healthcare Administrative Activity – The type of healthcare administrative activity of the originating actor for the ‘request’ activity type.Activity ID – A symbolic ID used to express, in abbreviated form, the attachment activity. (NOTE: This ID will be used to uniquely determine the standard(s) necessary to accomplish the attachment exchange activity described in the row of the table)Activity Type – Describes the type of activity of the originating actor.Request – explicitly requested additional informationAttachment, either electronically or some other method.Response – Attachment provided electronically in response to an explicit request.Attachment Submission – Attachment provided electronically in response to an “advance rule based” request for Attachments (e.g., mutually known rules, policy or guidelines).Attachment Activity BasisSolicited – Attachment which is:an explicit request orfor additional informationthe response to an explicit request.Unsolicited – Attachment from the Originator Actor to the Receiver Actor based ONLY on a “rules based” request and in the absence of an explicit request. ActorOriginator – the actor originating or initiating the attachment activity.Receiver – the actor receiving the attachment activity. Example Figure ID – Identifies specific Figures/Illustrations within this Supplement that depict the specific Healthcare Administrative Activity.Envelope/Transaction Standard Example – Identifies examples of electronic standards available to accomplish the specific attachment activity for that table row.Attachment Activity Table 2 association to standards Use of this table permits standards correlation to each of the Aactivity ID’s with a current ASC X12N TR3, or any other future standard(s) that perform a comparable function. Future regulation could expand to other standards comparable to the ASC X12N TR3s, to which the aActivity ID could correlate. Table SEQ Table \* ARABIC 2: ASC X12N Attachments Activity Table Healthcare Administrative ActivityActivity IDOriginator Activity TypeAttachment Activity BasisActorExample Figure IDEnvelope/Transaction StandardExampleSolicitedUnsolicitedOriginatorReceiverClaims Attachment#1RequestXPayerProvider1ASC X12N 277#2ResponseXProviderPayerASC X12N 275#3Attachment SubmissionXProviderPayer2ASC X12N 275 NOTEREF _Ref336508400 \f \h \* MERGEFORMAT 77Prior Auth Attachment#4RequestXPayerProvider3ASC X12N 278#5ResponseXProviderPayerASC X12N 275#6Attachment SubmissionXProviderPayer4ASC X12N 275 NOTEREF _Ref336509233 \f \h \* MERGEFORMAT 99Referral Attachment#7RequestXPayer/Referring ProviderReferred To Provider5ASC X12N 278 NOTEREF _Ref336509148 \f \h \* MERGEFORMAT 88#8ResponseXReferred To ProviderPayer/Referring ProviderASC X12N 275 NOTEREF _Ref336509233 \f \h \* MERGEFORMAT 99#9Attachment SubmissionXReferred To ProviderPayer/Referring Provider6ASC X12N 275 NOTEREF _Ref336509233 \f \h \* MERGEFORMAT 99Notification Attachment#10Attachment SubmissionXFacility providerPrimary care provider7ASC X12N 275 NOTEREF _Ref336509233 \f \h \* MERGEFORMAT 99Post Adjudicated Claim Attachment#11RequestXPayerProvider8ASC X12N 277 NOTEREF _Ref336508509 \f \h \* MERGEFORMAT 66#12ResponseXProviderPayerASC X12N 275 NOTEREF _Ref336508400 \f \h \* MERGEFORMAT 77*References to the Envelope Transaction Standards are generic in this table. Implementers should use the version of the Technical Report published for the purposes of exchanging Attachments based on their business requirements or regulatory mandate.To better understand the relationship of the row values for each attachment activity, a “table interpretation template” was developed:Table interpretation template:Activity “Activity ID” represents the information exchange for the “Healthcare Administrative Activity” “Solicited / Unsolicited” “Originator Activity Type” for Attachments from the “Originator” to the “receiver”.By substituting the row values found for each of the heading columns identified in “BOLD” type, a high level use case description can be created. The following examples are derived from the table using the template above:Claim Attachment Scenarios (Examples)Activity #1 represents the information exchange for the Claims Attachment solicited request for additional information from the payer to the provider.Activity #2 represents the information exchange for the Claims Attachment solicited Attachment response from the provider to the payer.Activity #3 represents the information exchange for the Claims Attachment unsolicited Attachment submission from the provider to the payer.Prior Authorization Attachment Scenarios (Examples)Activity #4 represents the information exchange for the Pprior Aauthorization Attachment solicited request for additional information from the payer to the provider. Activity #5 represents the information exchange for the pPrior Aauthorization Attachment solicited Attachment response from the provider to the payer. Activity #6 represents the information exchange for the Pprior Aauthorization Attachment unsolicited Attachment submission from the provider to the payer. Referral Attachment Scenarios (Examples)Activity #7 represents the information exchange for the Referral Attachment solicited request for additional information from the payer/referred to provider to the referring provider. Activity #8 represents the information exchange for the Referral Attachment solicited Attachment response from the referring provider to the payer/referred to provider. Activity #9 represents the information exchange for the Rreferral Attachment unsolicited Attachment submission from the referring provider to the payer/referred to provider. Notification Attachment Scenarios (Examples)Activity #10, represents the information exchange for the Nnotification Attachment unsolicited Attachment submissions from the facility provider to the primary care provider.Post Adjudicated Claims Scenarios (Examples)Activity #11 represents the information exchange for the Post Adjudicated Claim Attachment solicited request for Attachments additional information from the payer to the provider.Activity #12 represents the information exchange for the Post Adjudicated Claim Attachment solicited Attachment response for Attachments from the provider to the payer.Attachment Activity Table association to standards Use of this table permits standards correlation to each of the activity ID’s with a current ASC X12N TR3, or any other future standard(s) that perform a comparable function. Future regulation could expand to other standards comparable to the ASC X12N TR3s, to which the activity ID could correlate. Attachment Scenario and Scope The activities above are not meant to reflect and/or include business event activities other than those directly related to the requesting and responding with Attachments. Triggering events which create the need for Attachment additional information request or Attachment response/submittal may be indicated in examples in Chapter 6 but are NOT in scope for this Supplement. They are present to help the implementer understand where an attachment activity may fit within the overall business process. For example, when a provider requests authorization from a payer prior to rendering a service, the act of submitting the prior authorization request is not included in scope. Only the payer’s requesting Attachments additional information and the provider’s subsequent submittal of that Attachment are included.Attachment Request/Response Re-Association using Attachment Unique ID An essential component of an attachment activity is the ability to re-associate the Attachment with the request through the use of an Attachment IDAttachment Unique ID. Depending on the attachment activity, the entity responsible for assigning an Attachment IDAttachment Unique ID will vary. When the Attachment is unsolicited, the Attachment IDAttachment Unique ID SHALL be used in both the attachment and the enveloping metadata. When the Attachment is solicited, the Attachment IDAttachment Unique ID SHALL be used only in the enveloping metadata (for more information on enveloping metadata, see Appendix A - Business Requirements for requesting and submitting attachment (Metadata)).The table on the next page highlights how the Attachment IDAttachment Unique ID will be integrated into the attachment activity processes.Table SEQ Table \* ARABIC 3: Attachments ID Re-association Table Healthcare Administrative ActivityActivity ID RelationshipAttachment ActivityAttachment ID creatorIntended Re-association linkageClaim AttachmentPaired together as a solicited request for additional information and response with an Attachment for a Claim AttachmentActivity #1 represents the information exchange for the Claims Attachment solicited request for additional information from the payer to the providerPayer Provider returns the ID from the request (#1) in their Attachment response (#2)Activity #2 represents the information exchange for the Claims Attachment solicited Attachment response from the provider to the payerStand aloneActivity #3 represents the information exchange for the Claims Attachment unsolicited Attachment submission from the provider to the payerProviderProvider inserts ID into both claim and Attachment submissionPrior Authorization AttachmentPaired together as a solicited request for additional information and response with an Attachment for Prior Authorization AttachmentsActivity #4 represents the information exchange for the Prior Authorization Attachment solicited request for additional information from the payer to the provider.PayerProvider returns the ID from the request (#4) in their Attachment response (#5)Activity #5 represents the information exchange for the Prior Authorization Attachment solicited Attachment response from the provider to the payer.Stand aloneActivity #6 represents the information exchange for the Prior Authorization Attachment unsolicited Attachment submission from the provider to the payer.ProviderProvider inserts ID into both Prior Authorization request and Attachment submissionReferral AttachmentPaired together as a solicited request for additional information and response with an Attachment for Referral AttachmentsActivity #7 represents the information exchange for the Referral Attachment solicited request for additional information from the payer/referred to provider to the referring provider. Activity #8 represents the information exchange for the Referral Attachment solicited Attachment response from the referring provider to the payer/referred to provider. PayerReferring provider returns the ID from the request (#7) in their Attachment response (#8)Stand aloneActivity #9 represents the information exchange for the Referral Attachment unsolicited Attachment submission from the referring provider to the payer/referred to provider. ProviderReferring provider inserts ID into both the Referral request and Attachment submissionNotification AttachmentStand AloneActivity #10, represents the information exchange for the Notification Attachment unsolicited Attachment submissions from the facility provider to the primary care provider.Facility Provider(Unknown)Post Adjudicated Claim AttachmentPaired together as a solicited request for additional information and response with an Attachment for Post Adjudicated Claim AttachmentsActivity #11 represents the information exchange for the Post Adjudicated Claim Attachment solicited request for additional information from the payer to the providerActivity #12 represents the information exchange for the Post Adjudicated Claim Attachment solicited Attachment response from the provider to the payerPayerProvider returns the ID from the request (#11) in their Post Adjudicated Claim Attachment response (#12) Standards to Accomplish Information Exchange of The Request and ResponseThe authors of this Supplement acknowledge that there may be more than one standard that could accomplish the information exchange.They further acknowledge the development of a full suite of standard transactions developed by ASC X12N. For the purposes of this document, references to requests and responses to requests in examples and/or use cases will include a reference to the specific ASC X12N transaction that could be used. Non-Normative examples for the use of standard enveloping, messaging and transports to request and exchange CDA Attachments are included in Appendix D. As the technologies mature, we expect additional standards to be developed and are open to adapting this supplement to includeing them as wellin future versions. LOINC (Logical observation identifiers name and codes)Since its inception, Regenstrief has developed LOINC as an open standard. Regenstrief welcomes requests for new LOINC terms. It is because of submissions from the LOINC community that the vocabulary has been able to grow and adapt so quickly. Regenstrief is also always happy to receive specific suggestions about revisions or enhancements to existing content like synonyms and term descriptions as well. The general process for how to request these enhancements to LOINC are described on the LOINC website: Use of LOINC for AttachmentsThe HL7 encoding of Attachments makes extensive use of the code set Logical Observation Identifier Names and Codes (LOINC?). LOINC provides a universal set of codes and names for identifying laboratory and clinical tests, measures, documents, and other clinical observations. LOINC is an openly developed vocabulary standard used worldwide to facilitate the exchange and pooling of clinical results for care delivery, outcomes management, public health reporting, and research purposes. LOINC achieves these aims by creating a unique identifier code and a structured name for each observation. When used in conjunction with widely adopted messaging standards, LOINC can be an essential ingredient for efficient electronic processing and storage of clinical data that comes from many independent sources. LOINC is a controlled terminology that contains unique identifiers and “fully specified” names constructed in a formal structure that distinguishes among tests and observations that are clinically different. LOINC creates codes and a formal name for each concept that corresponds to a single kind of document, observation, measurement, or test result. For example, LOINC code 18842-5 (Discharge Summary) identifies a document with a formal name:Discharge summarization note:Find:Pt{Setting}:Doc:{Provider} The display name (called the LOINC Long Common Name) for this term is the familiar “Discharge Summary”.The formal LOINC name is “fully-specified” in the sense that it contains the features necessary to disambiguate among similar clinically distinct observations. The fully-specified name is constructed according to a six-part semantic model that produces an aggregate or pre-coordinated expression that intentionally does not capture all possible information about the testing procedure or result – only enough to unambiguously identify it.More information about the LOINC naming conventions can be found in the LOINC Users’ Guide and other resources available from the LOINC website (). In the context of Attachments, LOINC codes are used for several purposes. At a high level, LOINC codes are used to identify the specific kind of information being communicated in both a request and response (e.g., a discharge summary or diagnostic imaging report (DIR)). LOINC codes may also be used to request a specific C-CDA Document by specifying the LOINC code that corresponds to the specific document ID (see Appendix B and C for a complete list). This allows the requester to ask for a specific Attachmentdocument, for example, the C-CDA R2.1 Op Note, and not just an Op Note. This can then be responded to by the provider by supplying the Op Note from either of the C-CDA Implementation Guides.. LOINC codes may also be used to specify certain modifier variables in fulfilling the request for information (e.g. variables that indicate a modification to the default time period). In attachment responses that use C-CDA Document. LOINC codes are used to identify the Attachment Dcoument Type (Document), sections, and sometimes the individual entries (tests or observations). While a LOINC code can identify information at the section and sometimes the entry level, a request for Attachments additional information should always be at the Document level. In a structured document, the section/entry LOINC code may be helpful to the recipient in extracting/parsing information within the document. In this way, LOINC codes are used to identify: An electronic Attachment in its entirety (e.g.,Discharge Summary Report), as an Attachment Type Identifier.A specific document level template (e.g. C-CDA R2 Op Note versus the CDP1 Enhanced Op Note) Attachment Document Identifier.A category of clinical report (e.g., send any reports of CAT scans of the head that are related to the claim or a specific service), as an Attachment Type Identifier appearing in the C-CDA Header.The implicit scope of a request activity (e.g., to modify a request for information for a period 30 days prior to treatment) as a Modifier LOINC Code.Obtaining LOINC and Other Resources From the Regenstrief InstituteLOINC is produced, distributed, and copyrighted by the Regenstrief Institute, and is made available for both commercial and non-commercial use without charge under the license at . LOINC is published in regular releases, typically twice per year (in June and December).The LOINC database and many other resources are available from the LOINC website: Regenstrief also develops and distributes the RELMA desktop mapping program. RELMA is available from the LOINC website at no cost and provides tools for browsing the LOINC database and mapping local terms to LOINC. In addition, Regenstrief also provides the online LOINC search application () that enables searching of the LOINC database from a web browser.The LOINC website has a variety of useful documentation resources including Users’ Guides for LOINC and RELMA, an FAQ, and some online tutorials that are available to download for offline review. From the LOINC website, you can also subscribe to the LOINC mailing list and find out about upcoming meetings and training events.Using the LOINC Code As An Identifier In MessagesEach term in the LOINC database is assigned a unique, permanent code called the LOINC code. This is the code that systems should use to identify test results in electronic reports. The LOINC code has no intrinsic structure except that the last character in the code is a Mod-10 check digit. Consistent with the use of LOINC allowed by the LOINC License, the HL7 Attachment Supplement Specification ithis supplement guide requires that LOINC codes be used as published in the LOINC database, without leading zeroes and with the hyphen that precedes the check digit (e.g., "8709-8" and "10154-3").Along with the code, the HL7 Attachment Supplement Specification i this supplemental guide strongly recommends that one of the published LOINC names also be transmitted in the message. For most purposes, the LOINC Long Common Name is the best name to include in electronic messages.Using the LOINC Database to Identify Valid Attachment TypesThe AWG has reached out to the industry stakeholders to identify the types of Attachments that are currently needed. However, we expect that as the exchange of Attachments exchange matures, the need for new Attachment Ttypes will grow. Rather than including Attachment Types in this supplement as a “static” value set and requiring publication of a new version of this supplement before new types can be used, the Attachments Types will be implemented as a “dynamic” external value set, external to this supplement.The LOINC database, maintained and managed by the Regenstrief Institute, will maintain the content of the external value set of LOINC codes available for usage in the exchange of Attachments , and is further described below.Regenstrief provides specialized Attachment features in LOINC, RELMA, and the online LOINC Search application.Additional information about the use of the RELMA program and the LOINC database for Attachment purposes and can be found at: Valid Attachment Types In The LOINC TableThe LOINC Table (available in several file formats) contains a field called [HL7_ATTACHMENT_STRUCTURE]. This field can be populated by one of these values UNSTRUCTURED or STRUCTURED.UNSTRUCTURED LOINC TermsLOINC terms with this value are approved by the HL7 AWG for use as an unstructured Attachment ONLY. When sent as an Attachment, implementers SHALL use the Unstructured Document template of the C-CDA R2.1 (see section 1.1.24 in C-CDA R2 : Volume 2 Templates and Supporting Material). Conformant Unstructured Documents must carry the document-level templateId asserting conformance with the C-CDA R2.1 guide. SHALL contain exactly one [1..1] templateId (CONF:7710) such that itSHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.1.10" (CONF:10054). Implementers SHALL NOT use LOINC codes where the [HL7_ATTACHMENT_STRUCTURE] is Null or STRUCTURED as an Unstructured Document Attachment (see section 1.1.24 in C-CDA R2 : Volume 2 Templates and Supporting Material). Over time, HL7 may develop additional guides for communicating Attachments in a structured way. As new implementation guides are developed by HL7 for these Attachment Types, Regenstrief will update the value of the [HL7_ATTACHMENT_STRUCTURE] field to reflect the presence of a guide for structured reporting.STRUCTURED LOINC TermsLOINC terms with this value are approved by the HL7 AWG for sending as structured content using the C-CDA Documents. This does not mean that they must always be sent as fully structured content, but rather that such a structured specification exists and is approved for use. As indicated in the C-CDA Implementation Guides, any particular Attachment Type can be sent in a manner that conforms to CDA Level 1 (nonXMLBody), CDA Level 2 (structuredBody with sections that contain a narrative block), or CDA Level 3 (structuredBody containing sections that contain a narrative block and coded entries).If the Attachment is sent as CDA Level 1 (nonXMLBody) or CDA Level 2 (structuredBody with sections that contain a narrative block), it must include the required content defined for the fully structured document (CDA Level 3). That is, the expected information content in the documents is the same in both cases.Identifying Valid Attachment Types Using RELMA and The Online LOINC Search Application ()Both the RELMA desktop mapping program and the online LOINC search application provide many functions for searching and browsing the LOINC database. Both applications are maintained and enhanced by the Regenstrief Institute on a regular basis, with new releases made available on the LOINC website. The following sub-sections provide a basic overview of how to use these tools to identify valid Attachment types, but the most current information is available at: RELMAFrom the Search tab or the Mapping tab, a query on the HL7_ATTACHMENT_STRUCTURE field will return all of the LOINC codes of that kind (e.g. UNSTRUCTURED or STRUCTURED). RELMA uses a Google-like search syntax, so a search for keywords can be combined with a search on a particular field in the LOINC database. For example, to search for all the LOINC terms with value in HL7_ATTACHMENT_STRUCTURE of “UNSTRUCTURED” containing the word “consent”, you could enter this query in the search box:consent HL7ATTACHMENTSTRUCTURE:unstructuredAs with all search results in RELMA, the rows in the search results grid can be highlighted and then exported (to a CSV file, the clipboard, or other options).Browsing RELMAThe RELMA program also provides a convenient viewer for browsing the LOINC terms used in Attachments. The Attachments viewer is available from the “HIPAA” menu.From the main Attachments viewer, three sub-sections are available: Structured, Unstructured, and Request Modifier Codes.The Structured tab presents the high level Attachment Type classifications from the C-CDA R2 and CDP1 and this supplement, the set of LOINC document codes in that classification, and a linkage to the set of allowed section and entry-level codes where appropriate.The Unstructured tab lists all of the LOINC codes that are approved by the HL7 Attachments WG for use as an unstructured Attachment ONLY (e.g., they have a value of UNSTRUCTURED in the HL7_ATTACHMENT_STRUCTURE field).The Request Modifier Codes tab lists all the LOINC codes that can be used as request modifiers, as described in Section 5.4.3 of this supplement.Identifying Valid Attachment Types Using The Online LOINC Search Application () The search syntax of the online LOINC search application is the same as that of RELMA. This powerful search syntax can search on keywords anywhere in the LOINC records or with a particular field. For example, to search for all the LOINC terms with value in HL7_ATTACHMENT_STRUCTURE of “UNSTRUCTURED” you could enter this query in the search box:HL7ATTACHMENTSTRUCTURE:unstructuredSimilar to RELMA, the rows in the search results grid of the online search application can be highlighted and then exported to a CSV file.Requesting LOINC Codes for New Attachment TypesProcess for Requesting New Attachment TypesTo request a new Attachment Type, initial contact should be made to the HL7 Attachments WG via any of the work group Co-Chairs found at the following link: ()Regenstrief Institute assigns LOINC codes upon request from various agencies. In the context of attachments, the LOINC codes for new Attachment Types (initially Unstructured) are received by the AWG which forwards appropriate requests to the Regenstrief for consideration. Requests go through a review process to ensure the concept has not been previously added and the meaning is clear. Some complex requests are discussed and decided by the LOINC Committee before they are completed by Regenstrief. The AWG, having initially received a request considered as unstructured, would coordinate with the submitter of the new Attachment Type request to assist in the development of content (Sections/Entries) necessary to advance the Attachment from Unstructured to Structured formatting. Updates to the LOINC databaseWith each release (semi-annually), the LOINC database contains additional new terms and some edits to existing terms. LOINC development follows best practices for terminology system development by never reusing or deleting codes. If a LOINC term is identified as erroneous or a duplicate of a previous term it is flagged as “deprecated” in the database, but the record is not removed. Changes in concept status are made very judiciously.There are various mechanisms for staying abreast of LOINC updates that are available from the LOINC website. You can join the LOINC announcement email list (), subscribe to the LOINC news RSS feed (), follow on Twitter (@LOINC), or check the website for other new features.Requesting/responding/submitting attachments Unsolicited Attachment ExchangeInsert information hereUnsolicited Attachments with Claims SubmissionInsert information hereUnsolicited Attachments with Prior AuthorizationsInsert information hereUnsolicited Attachments with NotificationsInsert information hereUse of LOINC codes with Unsolicite AttachmentsInsert information hereSolicited Attachment ExchangeInsert information hereRequest and Response for Claims SubmissionInsert information hereRequest and Response for Prior AuthorizationsInsert information hereUse of LOINC codes with Request and Response for AttachmentsInsert information hereUsing “Modifier LOINC Codes” to constrain the RequestInsert information hereSolicited Attachment ExchangeThe LOINC codeset plays a critical role in the requesting/responding/submitting of Attachments, especially when the recipients EHR system is capable of interpreting a codified request and generating/creating the Attachments being requested automatically and without human intervention. In C-CDA Documents, the LOINC populated in the Document Type Code is used to identify the requested Attachment. A LOINC/Document TypeCode may be used to:Identify the specific document type constituting the Attachment being requested. Identify which document (s) to respond with when multiple document types exist that could satisfy the request. These LOINC codes, Known as “Modifier LOINC Codes”, may be used to “modify” the request in “a” above. More about these may be found in Section 4.4.4, “Using Modifier LOINC Codes to Constrain the Request. A LOINC Document ID Code may be used to:Identify the specific document template that should be used to generate the Attachment. Requesting/Responding/Submitting AttachmentsThe LOINC codeset plays a critical role in the requesting/responding/submitting of Attachments, especially when the recipients EHR system is capable of interpreting a codified request and generating/creating the Attachments being requested automatically and without human intervention. In C-CDA Documents, the LOINC populated in the Document Type Code is used to identify the requested Attachmentadditional information. A LOINC/Document TypeCode may be used to:Identify the specific document type constituting the Attachment additional information being requested. Identify which document (s) to respond with when multiple document types exist that could satisfy the request. These LOINC codes, Known as “Modifier LOINC Codes”, may be used to “modify” the request in “a” above. More about these may be found in Section 4.4.4, “Using Modifier LOINC Codes to Constrain the Request. A LOINC Document ID Code may be used to:Identify the specific document template that should be used to generate the Attachment. Using LOINC Code to Request/Respond Attachment (Solicited)When requesting an Attachmentadditional information, a single LOINC is used to codify the specific document type being requested. In C-CDA Documents, there could be multiple LOINC codes which represent a single document type (e.g., Operative Note) in general or that are further specialized (depending on “setting” and “Specialty/Training/Professional Level”). The LOINC Codes that are valid for each C-CDA Document type are defined in the respective C-CDA Implementation Guide Those tables identify the general LOINC code as "”recommended", and LOINC codes specialized by speciality/training/professional level as “”ValueSets”.Examples of those clinical document types, their recommended LOINC Codes are found in Appendix B and Appendix C.As mentioned in C-CDA, use of the "recommended" LOINC is preferred but not required. For the purposes of Attachments, the use of the "recommended" LOINC is preferred as the single LOINC used in the request for an Attachmentadditional information. However, use of the "Value Set" LOINC code in the request may also be permitted if the requestor deems it appropriate for their business purposes. To accommodate both Payer/UMO needs for Attachments additional information and the flexibility afforded the EHR Systems by C-CDA, special rules for requesting and responding have been developed for Attachments. Special request/response rules for solicited Structured Attachments are described in Table 5 below. Table SEQ Table \* ARABIC 4: Request and Response LOINC Code Usage for Solicited Structured AttachmentsRequest LOINCResponding EHR SystemPayer/UMO System“Recommended” LOINCRespond with "recommended" LOINC if able. If EHR system only capable of creating specialized LOINC, respond with “value set” LOINC code closest to matching request for that document type.If response contains "recommended" LOINC code, consider response a match to request. If response not a match, cross-walk “value set” LOINC code to ‘recommended’ code for document type and consider a match if identical to the Request LOINC.“Value Set” LOINCRespond with same "value set" LOINC as in the request if able. If unable, respond with other "value set" LOINC or "recommended" LOINC closest to the matching request for that document type NOTEREF _Ref340334515 \f \h Error! Bookmark not defined.14.If response contains "value set" LOINC Code identical to request, consider response a match to request. If response not a match, cross-walk "value set" LOINC Code to "recommended" and/or other "value set" LOINC code for document type and consider a match if either the "recommended" or "value set" LOINC for document type found.For solicited unstructured Attachment type request and response, the LOINC Code used in the request SHALL be returned in the response. Information on locating valid unstructured LOINC codes from the Regenstrief LOINC database is available in section 5.5.1.1. Using LOINC Code to Submit Attachments (Unsolicited)When submitting Attachment in an unsolicited model, the specific LOINC code to be used as the Attachment Type ID follows these rules:In the C-CDA Implementation Guides there are LOINC codes specified as “Recommended” and “Value Sets”. For structured documents and their unstructured counterparts, the “Attachment Type ID” SHOULD be the “Recommended” LOINC Code, but the “Value Set” LOINC Codes are permitted.For unstructured documents that do not have a structured counterpart, refer to section 5.5.1.1 for determining valid LOINC codes for unstructured Attachments.Using “Modifier LOINC Codes” to Constrain The RequestModifier LOINC Codes are used to further inform the recipient of the request for an Attachmentadditional information. if a specific “Time Window” or “Item Selection” criteria should be applied to constrain which document types within that time window or item selection criteria should be responded with.Below you will find a table of “Time Window” Modifier LOINC Codes and “Item Selection” Modifier LOINC Codes. These should be considered as illustrative purposes, with the full set of LOINC modifier codes available for use indicated as such on the LOINC database.Table SEQ Table \* ARABIC 5: Time Window Modifier LOINC CodesLOINCcode Long DescriptionExample (if appropriate)18789-8Include all data of the selected type within the date window associated with the service NOTE: This is the default value; it will be assumed if no time window modifier code is includedTests performed during a hospital stay or a note written to describe a clinic visit18790-6Include all data of the selected type on or before the date of service A pathology report to verify the diagnosis for the claim, or per-operative test results18791-4Include all data of the selected type within or aligned to a service Radiology report for test performed during a visit or ordered during the visit and performed within five days18792-2Include all data of the selected type on or after the date of service Status on follow-up18803-7Include all data of the selected type that represents observations made 30 days or fewer before the starting date of service18804-5Include all data of the selected type that represents observations made three months or fewer before the starting date of service18805-2Include all data of the selected type that represents observations made six months or fewer before the starting date of service18806-0Include all data of the selected type that represents observations made nine months or fewer before the starting date of service18807-8Include all data of the selected type that represents observations made one year or less before the starting date of service53033-7Include all data of the selected type that represents observations made two years or less before the starting date of service18793-0Use no fixed time limit on data—any of the selected type are relevant no matter when obtainedAttachment Use Cases The following sections indicate examples of attachment activities covered by this Supplement. These examples will provide typical business flows for each of these attachment activities. Where these examples depict information exchange consistent with an attachment activity (see Table 2: Attachment Activity Types), those specific activities will be identified and correlated back to an entry in that table using their “Attachment Activity ID #”. Some of the examples may include information exchanges that are considered out of scope for this supplement but necessary to reflect the complete business flow. Those considered out of scope will be clearly marked.As previously noted, where attachment activities are indicated the corresponding ASC X12N standard will also be indicated for example purposes, but should not be construed to be limited ONLY to that ASC X12N standard. Is it assumed for these standard references, the attachment activity will be an electronic standard. However, it may be possible for the request activity to be non-electronic (e.g., manual, paper, phone call, etc), provided that the necessary metadata (see Appendix A) is communicated for inclusion in the electronic response.In the sub-chapter sections below, you will find general examples for the solicited and unsolicited scenarios where Attachments are used in support of a healthcare claim or encounter, prior authorizations, referrals, notifications and post-adjudicated claims review/audits. These examples are intended for illustrative purposes only and should not be construed as exhaustive.Example – Claim Attachment When a provider submits a claim to a payer, the claim may meet a condition(s) which requires an Attachmentadditional information to complete the adjudication of the claim. When the conditions are of a consistent and recurring nature, the payer may make these conditions known in advance to the provider so that the provider may submit the Attachment with the claim (unsolicited). When the condition is of a more “ad hoc” basis, upon receipt/review of the claim the payer may request additional information n Attachment from the provider directly related to that claim (solicited). Claim Attachment – Solicited Attachment ExampleExample Scenario: A provider submits a healthcare claim/encounter to a payer who, upon review, determines that it needs additional information from the provider to complete the adjudication of the claim. The payer initiates a request for that additional information. The provider receives that request, and responds to the payer with the Attachment needed.The diagram below depicts the business flow of the example above for a solicited claim attachment. Arrow #1 represents a claim which is submitted from a provider to a payer. Arrow #2 (Attachment Activity #1) represents the request for additional information from the provider. (if electronic, ASC X12N 277 NOTEREF _Ref336508509 \f \h 66)Arrow #3 (Attachment Activity #2) represents the provider’s response with an Attachment (ASC X12N 275 NOTEREF _Ref336508400 \f \h 77).Figure SEQ Figure \* ARABIC 1: Example - Claims Attachment (Solicited)(OUT OF SCOPE: Information exchange depicted by Arrows#1 is considered out of scope for this supplement as it only acts as a triggering event for additional information needed.) Claim Attachment – Unsolicited Attachment ExampleExample Scenario: A payer has provided instructions to providers when specific additional information is needed for pre-defined conditions found on a claim. The provider submits a claim to the payer and the supplemental information in addition to the claim.The diagram below depicts the business flow of the example above for an unsolicited claim Attachment. Arrow #1 represents a claim which is submitted from a provider to a payer. Arrow #2 (Attachment Activity #3) represents the provider’s submittal of an additional information Attachment previously agreed to between payer and provider as an Attachment (ASC X12N 275 NOTEREF _Ref336508400 \f \h 77).Figure SEQ Figure \* ARABIC 2: Example – Claims Attachment (Unsolicited) Example – Prior Authorization Attachment Often healthcare services require specific authorization of coverage in order to secure reimbursement. Depending on the service to be provided and the specifics of patient’s condition/diagnosis, additional patient-specific criteria (e.g. age, sex) and plan coverage, clinical or other information might be needed to support approval of the service. The need for authorization may be known to the healthcare provider based on:contracts with the payer, eligibility, formulary or benefit inquiries, prior experience with providing the service for patients covered by the plan.Alternatively the provider may learn of the need for authorization by virtue of a service denial orcommunication from the payer. Prior Authorization Attachment – Solicited Attachment ExampleExample Scenario: When the provider is not aware that additional information is needed, only the request for authorization will be sent. The payer/utilization management organization (UMO) receives the request for authorization and upon review, determines that it needs additional information from the provider. The payer/UMO initiates a request for the required documentation. The provider responds to the payer with the Attachment needed.The diagram below depicts the business flow of the example above for an solicited prior authorization attachment. Arrow #1 represents a Service Authorization Request which is submitted from a provider to a payer (ASC X12N 278 NOTEREF _Ref336509148 \f \h 88).Arrow #2 (Attachment Activity #4) represents a request for additional information in support of a service authorization request from the payer to the provider (ASC X12N 278 NOTEREF _Ref336509148 \f \h 88). Arrow #3 (Attachment Activity #5) represents the provider’s response with an Attachment (ASC X12N 275 NOTEREF _Ref336509233 \f \h 99).Figure SEQ Figure \* ARABIC 3: Example – Prior Authorization (Solicited)(OUT OF SCOPE: Information exchange depicted by Arrow #1 is considered out of scope for this supplement as it only acts as a triggering event for additional information needed.) Prior Authorization Attachment – Unsolicited Attachment ExampleExample Scenario: When the requirement is known, the provider may submit the request at the time the service is planned. This request for prior authorization would be accompanied by the required Attachment in support of the request. The diagram below depicts the business flow of the example above for an unsolicited Prior Authorization Attachment. Arrow #1 represents a Service Authorization Request which is submitted from a provider to a payer (ASC X12N 278 NOTEREF _Ref336509148 \f \h 88). Arrow #2 (Attachment Activity #6) represents the provider’s response with an submission of additional information as an Attachment (ASC X12N 275 NOTEREF _Ref336509233 \f \h 99).Figure SEQ Figure \* ARABIC 4: Example – Prior Authorization (Unsolicited)Example – Referral Attachment Patients may be referred to other providers for consultations, services, evaluations, etc. The referral is usually initiated from a care provider, but may be initiated by a payer or other entity. The initiator of the referral may provide clinical information for use by the “referred to” provider (unsolicited). When information is not sent and additional information is needed, the “referred to” provider may request that pertinent information be sent (solicited). The following diagrams depict the referral processes. Referral Attachment – Solicited Attachment ExampleExample Scenario: Provider “A” is caring for a patient and refers that patient to a specialist (Provider “B”) for further assessment. Provider “A” sends a referral to Provider “B”. Provider “B” receives the request and, upon review, determines they need additional information from Provider “A” and sends them a request. Provider “A” responds with the Attachment.The diagram below depicts the business flow of the example above for an Solicited Referral Attachment. Arrow #1 represents a Referral Request which is submitted from provider “A”(referring) to a provider “B”(referred too) (ASC X12N 278 NOTEREF _Ref336509148 \f \h 88).Arrow #2 (Attachment Activity #7) represents a request for additional information in support of a referral request from the provider “B” to provider “A” (ASC X12N 278 NOTEREF _Ref336509148 \f \h 88). Arrow #3 (Attachment Activity #8) represents provider “A” response with an Attachment to provider “B” (ASC X12N 275 NOTEREF _Ref336509233 \f \h 99).Figure SEQ Figure \* ARABIC 5: Example – Referral Attachment (Solicited)(OUT OF SCOPE: Information exchange depicted by Arrows #1 is considered out of scope for this supplement as it only acts as a triggering event for additional information needed.) Referral Attachment – Unsolicited Attachment ExampleExample Scenario: Provider “A” is caring for a patient and needs to refer that patient to a specialist (Provider “B”) for further assessment. Provider “A” forwards a referral along with any necessary medical records as Attachments to provider “B”.The diagram below depicts the business flow of the example above for an unsolicited Prior Authorization Attachment. Arrow #1 represents a Referral which is submitted from a provider “A” to provider “B” (ASC X12N 278 NOTEREF _Ref336509148 \f \h 88). Arrow #2 (Attachment Activity #9) represents the submittal of medical records from provider “A” to provider “B” as an Attachment (ASC X12N 275 NOTEREF _Ref336509233 \f \h 99).Figure SEQ Figure \* ARABIC 6: Example – Referral Attachment (Unsolicited)Example – Notification Attachment Notification can be used to send unsolicited information among providers, payers, delegated UMO entities and/or other providers. This information can take the form of copies of health service reviews or notification of scheduled treatment, or the beginning and end of treatment. A participant who is the recipient of the information may acknowledge they received the data, or reject the data due to specific application layer processing, but may not respond with any review decision outcome. Notification falls into four categories:Advance Notification used to communicate scheduled admissions or services. Completion Notification used to communicate patient facility admission or discharge and services completion for any specific episode of care. Information Copy used for any Health Services Review information sent to primary care provider(s), service provider(s), or other healthcare entities requiring the information for specific purposes.Change Notification used to report changes to the detail of a previously sent notification or information copy.The information source is the entity that knows the outcome of the service review request, and can be either a UMO or a provider. For example, in a situation where the primary care provider can authorize specialty referrals that do not require review for medical necessity, appropriateness, or level of care, the primary care provider is the information source and may have responsibility for notifying both the UMO and the service provider of the specialty referral. In cases where the UMO is the decision maker, the UMO would send a notice of certification to the requesting provider and the service provider.Notification Attachment – Unsolicited Notice of Facility Discharge with Discharge Summary ExampleExample Scenario – A facility provider discharges a patient of a primary care provider, and forwards a notification to that effect.The diagram below depicts the business flow of the example above for a notification Attachment. Arrow #1 (Attachment Activity #10) represents the submission of request for additional information from the provider as an Attachment. (if electronic, ASC X12N 275 NOTEREF _Ref336509233 \f \h 99)Figure SEQ Figure \* ARABIC 7: Example – Notification Attachment (Unsolicited)Example – Post Adjudicated Claim Attachment After the adjudication of a claim or encounter, a payer may elect or be requested to review that claim or encounter to be sure the adjudication was consistent with applicable medical policy. This may include a scenario where additional information from the provider of service may be needed.Post Adjudicated Claim Attachment – Solicited Attachment ExampleExample Scenario: A payer, after adjudicating a claim/encounter, reviews that claim and decides to perform some type of post-adjudication re-consideration of the original disposition. The payer initiates a request for that additional information. The provider receives that request, and responds to the payer with an Attachment .The diagram below depicts the business flow of the example above for a solicited claim Attachment. Arrow #1 represents a claim which is submitted from a provider to a payer. Arrow #2 represents a payers remittance advice to the provider.Arrow #3 (Attachment Activity #11) represents the request for additional information from the provider. (if electronic, ASC X12N 277 NOTEREF _Ref336508509 \f \h 66)Arrow #4 (Attachment Activity #12) represents the provider’s response with an Attachment (ASC X12N 275 NOTEREF _Ref336508400 \f \h 77).Figure SEQ Figure \* ARABIC 8: Example – Post Adjudicated Claim Attachment (Solicited)(OUT OF SCOPE: Information exchange depicted by Arrows #1 and #2 are considered out of scope for this supplement as they only act as a triggering event for an Attachment.) Important information not Previously addressed in this supplementInformation in this section should be moved to another section or deletedIn Chapter 6, use cases are presented describing anticipated scenarios depicting attachment activities. While business rules are not included in those scenarios, the authors of this supplement believe there are some industry “best practices” that enhance the attachment activity, and may be addressed in mutual trading partner agreements, companion guides, operating rules or regulations. Examples of these business rules include, but are not limited to the following:The C-CDA Implementation Guides offer specific document types in structured format along with an unstructured format suitable for other document types not defined in the structured formats. .Timeliness considerations for responses to requests for attachment information may be unique to the stakeholders needs, scenarios, etc. Establishing standard timeliness guidance should be avoided. However, establishing reasonable expectations of minimum and maximum time between request and response may be appropriate.For solicited requests, consideration should be given to the request envelope including a “respond-by” date for the response to be completed on or before that date to successfully complete the attachment activity.For unsolicited responses, policy should be developed to guide payers in claims and prior authorization attachment activities and providers in referral attachment activities what to do if the attachment is received but the claim, prior authorization or referral never arrives and/or cannot be re-associated with the claim, prior authorization or referral itself.Guidance should be developed to communicate the ‘in advance’ payer rules for unsolicited attachment activity. This may include payers publishing on their provider web-sites information or other routine provider communications defining the requirements for unsolicited attachment submission(s).Proactively defined criteria and situations should be identified where non-conformance with ‘in advance’ rules for unsolicited attachment activity could result in a HIPAA disclosure violation. Examples could include a response attachment activity that exceeded the request (patient complete medical record) or response attachment activity not consistent with ‘in advance’ rules.Attachment information, by default, is considered to be at the clinical document level. In some cases, the requestor of attachment information may need information at the sub-document level (section or entry). In this case, development of guidance based on scenarios may be helpful to identify the most appropriate document type to request the needed information. Absent that guidance, it would be up to the requestor of attachment information to determine the most appropriate document type to use for the request.Use of the unstructured document is intended to accommodate attachment types for which a structured format hasn’t been developed. Structured document types MAY also be sent in an unstructured format (e.g., H&P Scanned Image, discharge summary PDF). It should be thought of as attachment types that would exist at the document level, and where appropriate, capable of being developed into a structured template.Definitions, Abbreviations and acronyms.AIS – Additional Information SpecificationASC X12N 277 – Health Care Information Status Notification - Technical Report Type 3 for Health Care Claim Request for Additional InformationASC X12N 275 – Patient Information – Technical Report 3 for Additional Information to Support a Health Care Claim or EncounterASC X12N 278 – Health Care Services Review Information Technical Report 3 for Health Care Services Request for Review and ResponseASC X12N 275 – Patient Information – Technical Report 3 for Additional Information to Support a Health Care Service ReviewAttachments - The additional information needed in support of a healthcare administrative activityAttachment Submission - Refers to additional information submitted to a payer but done so based on advance knowledge of this information need (e.g., rules based on medical policy) rather than in response to a near-term request from the payer Attachment Type – Refers to the type of document (i.e., CCD, History and Physical, Discharge Summary) to be exchangedAttachment Type Identifier – Refers to the LOINC code used to identify the Attachment TypeAttachment Unique ID – A unique identifer assigned to the Request for Attachment and/or the Attachment used for linking the request to the response.AWG – HL7 Attachment Work GroupC-CDA - Consolidated Clinical Document ArchitetureC-CDA Documents – Document level templates defined in the C-CDA R2 and CDP1C-CDA Implementation Guides – C-CDA R2 and CDP1C-CDA R1.1 – HL7 Implementation Guides for CDA Release 2: IHE Health Story Consolidation, DSTU Release 1.1 C-CDA R2 - HL7 Implementation Guides for CDA Release 2: Consolidated CDA Templates for Clinical Notes Volume 1 Introductory Material and Volume 2 Templates and Supporting MaterialCDA – Clinical Document ArchitectureCDP1 - HL7 Implementation Guides for CDA Release 2: Additional CDA R2 Documentation Templates -- Clinical Documents for Payers – Set 1 Claim - May represent a healthcare claim or a healthcare encounter.esMD - Electronic Submission of Medial Documentation GIF – Graphics Interchange Format is a digital bitmap image format Healthcare Administrative Activity - Healthcare activities where the need for Attachments may be required (e.g., Claims, Referrals, Prior Authorizations, etc). This includes but is not limited to establishing coverage, conforming with treatment protocols, providing historical documentation for future treatment or other administrative functionsJPEG – Joint Photographic Exerts Group is a compressed digital photography Image compressed using the Joint Photographic Experts Group methodLOINC – Logical Observation Identifiers, Names and Codes ().Mod-10 – Algorithm applied to a series of numbers to arrive at a single (0-9) digit (check digit). When used in LOINC codes, the algorithm is applied to the digits to left of the hyphen to compute the check digit to the right of the hyphenModifier – Refers to the “Item Selection” or “Time Window” value used to further constrain an Attachment Type requestModifier LOINC Code – Refers to the LOINC Code used as the modifier in a request for an Attachment TypeObject Identifier (OID) - An ISO Object Identifier (OID) is a globally unique string consisting of numbers and dots (e.g., 2.16.840.1.113883.3.1). This string expresses a tree data structure, with the left-most number representing the root and the right-most number representing a leafPayer - Refers to a healthcare entity, such as a health insurance company or UMO, that receives and process claims, prior authorizations and referralsPDF – Portable Document Format is a file format developed by Adobe as a means of distributing compact, platform-independent documentsPNG – Portable Network Graphics is a bitmapped image format that employs lossless data compression. Structured Document – a CDA header paired with a structuredBody elementTIFF – Tagged Image Format used for scanned images UMO – Utilization Management Organization Unstructured Document – a CDA header paired with a nonXMLbody element Consolidated Clinical Document Architecture Release 2.1 (C-CDA R2.1).Note: information in this Appendix needs to be limited ot CDA R2 and reorganized based on the outline below.Note: The second release of the C-CDA named C-CDA R2 was split into two volumes. This two-volume implementation guide (IG) contains an overview of Clinical Document Architecture (CDA) markup standards, design, and use (Volume 1) and a consolidated library of CDA templates for clinical notes applicable to the US Realm (Volume 2). These two volumes comprise a Draft Standard for Trial Use (DSTU). The C-CDA R2 replaces the HL7 Implementation Guides for CDA Release 2: IHE Health Story Consolidation, DSTU Release 1.1.B.1 Overview of Implementation GuideInsert Implementation Guide Overview hereB.2 Document TemplatesInsert Document Template description hereB.3 LOINC CodesInsert LOINC Code mapping hereTable xx: Clinical Document Types with Recommended LOINC Code for RequestsClinical document Type"Recommended" LOINCLOINC Long DescriptionC-CDA R2 Table ReferenceValueSetCare Plan52521-2 Overall Plan of Care/Advance Care Directive Consultation Note11488-4Consult NoteTable #28ConsultDocumentTypeCCD34133-9Summarization of Episode Note Diagnostic Imaging Report18748-4Diagnostic imaging ReportLOINC Imaging Document CodesDischarge Summary18842-5Discharge SummaryTable #37DischargeSummaryTypeCodeEnhanced Encounter77601-3Enhanced EncounterLOINC code for Enhanced EncounterHistory and Physical34117-2History and Physical noteTable #41HPDocumentTypeInterval77600-5IntervalLOINC code for Interval DocumentOperative Note11504-8Provider-unspecified Operation NoteTable #44SurgicalOperationNoteDocumentTypeCodeProcedure Note28570-0Provider-unspecified Procedure NoteTable #48ProcedureNoteDocumentTypeCodesProgress Note11506-3Provider-unspecified Progress NoteTable# 51ProgressNoteDocumentTypeCodeReferral Note57133-1Referral NoteTable# 54ReferralDocumentTypeTransfer Summary18761-7Provider-unspecified Transfer SummaryTable# 57TransferDocumentTypeWhat are C-CDA Document Types?C-CDA Implementaiton Gudes define clinical information in a format based on CDA, constrained by conformance statements consistent with industry best practices for specific types of clinical documents. Some broadly used clinical document types have been more fully developed in CDA than others. Examples of those clinical document types are: In the C-CDA R2Continuity of Care Document (CCD)Consultation NoteDiagnostic Imaging Report (DIR)Discharge SummaryHistory and PhysicalOperative NoteProcedure NoteProgress NoteCare PlanReferral NoteTransfer SummaryPatient Generated DocumentIn the CDP1Enhanced Encounter DocumentEnhanced Discharge DocumentEnhanced Operative Note DocumentEnhanced Procedure DocumentInterval DocumentOther clinical information not listed above may also be exchanged using C-CDA R2 by taking advantage of the “Unstructured Document”, as described in Section 1.1.24 of the C-CDA R2: Volume 1 Introductory Material. Throughout the C-CDA R2 implementers will see references to sending and receiving EHR systems. This is because the C-CDA R2 was written from the perspective of exchange between EHR systems. For the purposes of this supplement there is no assumption that exchange will occur between two EHR systems. Instead, as you will see in the use case portion of this supplement (Chapter 6), the additional information a payer is seeking may exist in a provider’s electronic repository, such as an EHR system, and may/may not be passed through a practice management system or be sourced directly from the EHR. Section 1 of the C-CDA R2: Volume 1 Introductory Material describes at a high level how templates are used to represent the organization of CDA structure in a document. Metadata found in the Header as well as specific clinical information found in the Body components as Documents, Sections within those documents, and entries within those sections are explained are described in Sections 1-4 of the C-CDA R2: Volume 2 Templates and Supporting Material and Sections 5-7 of the CDP1.Table xx: LOINC Codes for Specific C-CDA DocumentsGuideDocument TemplateLOINC(example)LOINC Long DescriptionNone specified (default)61000-nNo specific document format requestedC-CDA R2Continuity of Care Document (CCD) urn:hl7ii:2.16.840.1.113883.10.20.22.1.2:2014-06-0961001-nCCDAR2: Continuity of Care DocumentC-CDA R2Consultation Note urn:hl7ii:2.16.840.1.113883.10.20.22.1.4:2014-06-0961003-nCCDAR2: Consultation NoteC-CDA R2Diagnostic Imaging Report (DIR) urn:hl7ii:2.16.840.1.113883.10.20.22.1.5:2014-06-0961004-nCCDAR2: Diagnostic Imaging ReportC-CDA R2Discharge Summary urn:hl7ii:2.16.840.1.113883.10.20.22.1.8:2014-06-0961005-nCCDAR2: Discharge SummaryC-CDA R2History and Physical urn:hl7ii:2.16.840.1.113883.10.20.22.1.3:2014-06-0961006-nCCDAR2: History and PhysicialC-CDA R2Operative Note urn:hl7ii:2.16.840.1.113883.10.20.22.1.7:2014-06-0961007-nCCDAR2: Operative NoteC-CDA R2Procedure Note urn:hl7ii:2.16.840.1.113883.10.20.22.1.6:2014-06-0961008-nCCDAR2: Procedure NoteC-CDA R2Progress Noteurn:hl7ii:2.16.840.1.113883.10.20.22.1.9:2014-06-0961009-nCCDAR2: Progress NoteC-CDA R2Care Plan urn:oid:2.16.840.1.113883.10.20.22.1.1561010-nCCDAR2: Care PlanC-CDA R2Referral Note urn:oid:2.16.840.1.113883.10.20.22.1.1461011-nCCDAR2: Referral NoteC-CDA R2Transfer Summary urn:oid:2.16.840.1.113883.10.20.22.1.1361012-nCCDAR2: Transfer SummaryCDP1Enhanced Encouner Document urn:oid:2.16.840.1.113883.10.20.35.1.162001-nCDP1: Enhanced Encouner DocumentCDP1Enhanced Discharge Document urn:oid:2.16.840.1.113883.10.20.35.1.262002-nCDP1: Enhanced Discharge DocumentCDP1Enhanced Operative Note Document urn:oid:2.16.840.1.113883.10.20.35.1.362003-nCDP1: Enhanced Operative NoteCDP1Enhanced Procedure Document urn:oid:2.16.840.1.113883.10.20.35.1.462004-nCDP1: Enhanced Procedure NoteCDP1Interval Document urn:oid:2.16.840.1.113883.10.20.35.1.562005-nCDP1: Interval NoteThe requester should only specify a format if a specific document is preferred. Provider may return any appropriate document type consistant with curent regulation or, in the absence of applicable regulations, with trading partner agreementClinical Documents for Payers – Set 1 Release 1.1 (CDP1 R1.1).Note: information in this Appendix needs to be limited to CDP1 and reorganized based on the outline below.In the Fall of 2013, additional work was done by the Electronic Submission of Medial Documentation (esMD) Initiative to map existing CMS Medicare Fee For Service (FFS) and other use cases where an enhanced set of information is required to be supported in the proposed C-CDA R2 templates. The resulting analysis revealed the need for additional, highly constrained document templates to augment those defined by the C-CDA R2. This work resulted in the creation of documents defined in the Clinical Documents for Payers – Set 1 (CDP1). C.1 Overview of Implementation GuideInsert Implementation Guide Overview hereC.2 Document TemplatesInsert Document Template description hereC.3 LOINC CodesInsert LOINC Code mapping hereTable xx: Clinical Document Types with Recommended LOINC Code for RequestsClinical document Type"Recommended" LOINCLOINC Long DescriptionC-CDA R2 Table ReferenceValueSetCare Plan52521-2 Overall Plan of Care/Advance Care Directive Consultation Note11488-4Consult NoteTable #28ConsultDocumentTypeCCD34133-9Summarization of Episode Note Diagnostic Imaging Report18748-4Diagnostic imaging ReportLOINC Imaging Document CodesDischarge Summary18842-5Discharge SummaryTable #37DischargeSummaryTypeCodeEnhanced Encounter77601-3Enhanced EncounterLOINC code for Enhanced EncounterHistory and Physical34117-2History and Physical noteTable #41HPDocumentTypeInterval77600-5IntervalLOINC code for Interval DocumentOperative Note11504-8Provider-unspecified Operation NoteTable #44SurgicalOperationNoteDocumentTypeCodeProcedure Note28570-0Provider-unspecified Procedure NoteTable #48ProcedureNoteDocumentTypeCodesProgress Note11506-3Provider-unspecified Progress NoteTable# 51ProgressNoteDocumentTypeCodeReferral Note57133-1Referral NoteTable# 54ReferralDocumentTypeTransfer Summary18761-7Provider-unspecified Transfer SummaryTable# 57TransferDocumentTypeWhat are C-CDA Document Types?C-CDA Implementaiton Gudes define clinical information in a format based on CDA, constrained by conformance statements consistent with industry best practices for specific types of clinical documents. Some broadly used clinical document types have been more fully developed in CDA than others. Examples of those clinical document types are: In the C-CDA R2Continuity of Care Document (CCD)Consultation NoteDiagnostic Imaging Report (DIR)Discharge SummaryHistory and PhysicalOperative NoteProcedure NoteProgress NoteCare PlanReferral NoteTransfer SummaryPatient Generated DocumentIn the CDP1Enhanced Encounter DocumentEnhanced Discharge DocumentEnhanced Operative Note DocumentEnhanced Procedure DocumentInterval DocumentOther clinical information not listed above may also be exchanged using C-CDA R2 by taking advantage of the “Unstructured Document”, as described in Section 1.1.24 of the C-CDA R2: Volume 1 Introductory Material. Throughout the C-CDA R2 implementers will see references to sending and receiving EHR systems. This is because the C-CDA R2 was written from the perspective of exchange between EHR systems. For the purposes of this supplement there is no assumption that exchange will occur between two EHR systems. Instead, as you will see in the use case portion of this supplement (Chapter 6), the additional information a payer is seeking may exist in a provider’s electronic repository, such as an EHR system, and may/may not be passed through a practice management system or be sourced directly from the EHR. Section 1 of the C-CDA R2: Volume 1 Introductory Material describes at a high level how templates are used to represent the organization of CDA structure in a document. Metadata found in the Header as well as specific clinical information found in the Body components as Documents, Sections within those documents, and entries within those sections are explained are described in Sections 1-4 of the C-CDA R2: Volume 2 Templates and Supporting Material and Sections 5-7 of the CDP1.Table xx: LOINC Codes for Specific C-CDA DocumentsGuideDocument TemplateLOINC(example)LOINC Long DescriptionNone specified (default)61000-nNo specific document format requestedC-CDA R2Continuity of Care Document (CCD) urn:hl7ii:2.16.840.1.113883.10.20.22.1.2:2014-06-0961001-nCCDAR2: Continuity of Care DocumentC-CDA R2Consultation Note urn:hl7ii:2.16.840.1.113883.10.20.22.1.4:2014-06-0961003-nCCDAR2: Consultation NoteC-CDA R2Diagnostic Imaging Report (DIR) urn:hl7ii:2.16.840.1.113883.10.20.22.1.5:2014-06-0961004-nCCDAR2: Diagnostic Imaging ReportC-CDA R2Discharge Summary urn:hl7ii:2.16.840.1.113883.10.20.22.1.8:2014-06-0961005-nCCDAR2: Discharge SummaryC-CDA R2History and Physical urn:hl7ii:2.16.840.1.113883.10.20.22.1.3:2014-06-0961006-nCCDAR2: History and PhysicialC-CDA R2Operative Note urn:hl7ii:2.16.840.1.113883.10.20.22.1.7:2014-06-0961007-nCCDAR2: Operative NoteC-CDA R2Procedure Note urn:hl7ii:2.16.840.1.113883.10.20.22.1.6:2014-06-0961008-nCCDAR2: Procedure NoteC-CDA R2Progress Noteurn:hl7ii:2.16.840.1.113883.10.20.22.1.9:2014-06-0961009-nCCDAR2: Progress NoteC-CDA R2Care Plan urn:oid:2.16.840.1.113883.10.20.22.1.1561010-nCCDAR2: Care PlanC-CDA R2Referral Note urn:oid:2.16.840.1.113883.10.20.22.1.1461011-nCCDAR2: Referral NoteC-CDA R2Transfer Summary urn:oid:2.16.840.1.113883.10.20.22.1.1361012-nCCDAR2: Transfer SummaryCDP1Enhanced Encouner Document urn:oid:2.16.840.1.113883.10.20.35.1.162001-nCDP1: Enhanced Encouner DocumentCDP1Enhanced Discharge Document urn:oid:2.16.840.1.113883.10.20.35.1.262002-nCDP1: Enhanced Discharge DocumentCDP1Enhanced Operative Note Document urn:oid:2.16.840.1.113883.10.20.35.1.362003-nCDP1: Enhanced Operative NoteCDP1Enhanced Procedure Document urn:oid:2.16.840.1.113883.10.20.35.1.462004-nCDP1: Enhanced Procedure NoteCDP1Interval Document urn:oid:2.16.840.1.113883.10.20.35.1.562005-nCDP1: Interval NoteThe requester should only specify a format if a specific document is preferred. Provider may return any appropriate document type consistant with curent regulation or, in the absence of applicable regulations, with trading partner agreementC-CDA Document Transport and payloadThis appendix covers standards based approaches to sending a C-CDA Document using electronic transactions. This Appendix will use CDA any C-CDA Document. D.1 Transport OptionsX12 275, CONNECT w/ X12 275 (X12 message), CONNECT (XDR), Direct (X12 message), and Direct are five transport and payload mechanisms covered in this appendix.TransportMessage/MetadataClinical PayloadX12 (real-time) (SOAP)ASC X12N 275 with CAQH CORECDACONNECT (SOAP)ASC X12N 275 with CAQH CORECDACONNECT (SOAP)XDRCDADirect (SMTP)ASC X12N 275 (X12 MIME)CDADirect (SMTP)XML MIMECDAD.2 Metadata requirementsWhen an EHR or other patient record system creates any clinical document (Attachment) consistent with the C-CDA Implementation Guide Standards, it does so without regard to the recipient or that recipient’s purpose for obtaining that Attachment. Because of this, the recipient may need additional information (metadata) to better understand which healthcare attachment activity for which the Attachment is intended.The following metadata SHALL accompany the attachment information being exchanged:Requestor (Payer/UMO) Name and Identifier (plan ID, HPID, etc)Request receiver Name and ID (ETIN, etc)Provider of Service Name and ID (NPI)Attachment Control ID (payer or provider assigned, depending on solicited/unsolictied)Attachment Information ID needed (LOINC Code), both in request and responseDate Requested and Response Due DatePayer Contact InformationDate of Service/EncounterIn addition to the metadata above, the following MAY be included if the situation indicates:Patient Control Number (assigned by provider on claim)Patient Medical Record Number (assigned by provider on claim)Property and Casualty Claim NumberCase Reference IDAttachment Request Tracking ID.D.3 Overview of X12 (real-time)This section defines how a transaction may be submitted with the X12 275. Submission under this mechanism is constrained to real-time transmissions (batch transmissions are out of scope):Figure STYLEREF 1 \s 8 SEQ Figure \* ARABIC \s 1 1: X12 (real-time)1344295120650Security Metadata (optional)ASC X12N 275 with CDASOAP Envelope over HTTP<SOAP Header></SOAP Header></SOAP Body><SOAP Body>X12ASC X12N EnvelopeInterchange/functional Groups00Security Metadata (optional)ASC X12N 275 with CDASOAP Envelope over HTTP<SOAP Header></SOAP Header></SOAP Body><SOAP Body>X12ASC X12N EnvelopeInterchange/functional GroupsD.3.1 Security MetadataWhen using the Phase II CAQH CORE Rule 270: Connectivity Rule 2.2.0, the Security Metadata must be placed in the Body element of the SOAP envelope, as illustrated below (example is for using standards defined by the HL7 Digital Signature and Delegation of Rights DSTU and applied to transaction as specified in the S&I PPA Implementation Guide):<securityMetadata><digitalSignature>...</digitalSignature><delegationofRights>...</delegationofRights ></securityMetadata>D.3.2 Error HandlingEnvelope level errors shall be handled in accordance with Phase II CAQH CORE Rule 270: Connectivity Rule Version 2.2.0. To handle CORE-compliant envelope processing status and error codes, two fields called errorCode and errorMessage are included in the CORE-compliant Envelope. errorMessage is a free form text field that describes the error for the purpose of troubleshooting/logging. When an error occurs, PayloadType is set to CoreEnvelopeError.Errors in processing security metadata shall be treated as CORE envelope level errors. The CORE envelope error codes will use the security specific error codes identified in REF _Ref342463211 Error! Reference source not found.. REF _Ref342463211 Error! Reference source not found. shows the error, the error code, and a description of information which may populate the attributes of the CORE errorMessage fieldX12 Interchange Envelope Conformance errors in the transaction shall be communicated in an X12 TA1 response. The possible TA1 error codes are located in the ASC X12N TA1 005010X231A1 Implementation Specification.X12 Standard Conformance & Implementation Guide Conformance errors in the transaction shall be communicated in an X12 999 response. The possible 999 error codes are located in the ASC X12N 999 005010X231A1 Implementation Specification.Application processing errors in the transaction shall be communicated in an X12 824 response. The possible 824 error codes are located in the ASC X12N 824 005010X186A1 Implementation Specification. When the error has been caused by a specific segment or segments, the response should identify the segment or segments that caused the error. It is the responsibility of the responder to select an appropriate error code from the Insurance Business Process Application Error Codes.The relevant ASC X12N Implementation Guides for error and acknowledgment handling are available at Insurance Business Process Application Error Codes are maintained by the Washington Publishing Company and are available at Overview of a payload over CONNECT with ASC X12N MessageThis section defines how a CDA document may be sent over CONNECT with the CAQH CORE ASC X12N Document Submission Service Interface SpecificationD.4.1 ASC X12N 275 over CONNECT (CORE)Healtheway (previously the Nationwide Health Information Network (NHIN)) adopted the Phase II CAQH CORE Rule 270: Connectivity Rule Version 2.2.0 to exchange ASC X12N Administrative Transactions between one or more Health Information Exchanges via the Internet. CONNECT is the open-source solution used by CMS supporting Exchange participants. The “CAQH CORE X12 Document Submission Service Interface Specification” defines specific constraints on the use of the CAQH CORE Connectivity Rule. REF _Ref391441997 \h Error! Reference source not found. below presents the components of a request or response message using 275 and CONNECT with the NHIN CAQH CORE X12 Document Submission Service Interface Specification.Specific CONNECT implementations may provide support for X12 transactions with a CAQH CORE wrapper without an XDR wrapper. Implementations of CONNECT should be capable of sending and receiving CAQH CORE-wrapped X12 transactions with an XDR wrapper, and optionally without an XDR wrapper based on trading partner agreements.CDA transactions using XDR specifications shall conform with NHIN Document Submission v2.0 transmissions. The XDR XML body element will contain a reference to the 275, where the metadata information block is encapsulated with the XDR submission set and its document attributes. XDR submission specifications (i.e., submission set & document metadata attributes) for esMD are available in Section 3.2 (Submission Specifications) within the NHIN esMD XDR Specification.Figure STYLEREF 1 \s 8 SEQ Figure \* ARABIC \s 1 2: CONNECT with ASC X12N SpecificationNote: Per specifications, encoding for XDR may be indicated in the metadata, and encoding must be Base64.D.4.2 CONNECT SAML AssertionsSAML assertions for transactions with CMS must conform to the “Implementation Guide for Health Information Handlers for Electronic Submission of Medical Documentation Project,” section 5.3.5.5: esMD SAML Assertions Details, which states:The CONNECT SAML Assertions define the exchange of metadata used to characterize the initiator of a request so that it may be evaluated by the Payer Gateway in local authorization decisions. The purpose of this SAML Assertion exchange is to provide the Payer Gateway with the information needed to make an authorization decision using the policy enforcement point for the requested esMD function. Each initiating SOAP message must convey information regarding the Registration Requestor’s attributes and authentication using SAML 2.0 Assertions.SAML assertions for transactions with Commercial Payers must conform to the eHealth Exchange Authorization Framework Specification v3.0.D.4.3 IHE XD* MetadataSystems using an HPD Plus DSMLv2 document payload over CONNECT or Direct should adopt the IHE Cross Enterprise Document Reliable Interchange (XDR) profile with XDS Repository Submission Request Provide and Register Document set – b (ITI-41) transaction metadata.Cross-Enterprise Document Reliable Interchange (XDR) provides document interchange using a reliable messaging system. This permits direct document interchange between EHRs, PHRs, and other healthcare IT systems in the absence of a document sharing infrastructure such as XDS Registry and Repositories.Cross-Enterprise Document Media Interchange (XDM) provides document interchange using a common file and directory structure over several standard media, including email. This permits the use of person-to-person email to convey documents. XDM defines no new metadata but leverages the existing XDS metadata.D.5 Overview of a payload over CONNECT with XDRThis section defines how a transaction may be sent over CONNECT with the eHealth Exchange CAQH CORE X12 Document Submission Service Interface Specification.The Nationwide Health Information Network has adopted the Phase II CAQH CORE Rule 270: Connectivity Rule Version 2.2.0 to exchange ASC X12N Administrative Transactions between one or more Health Information Exchanges via the Internet. The “CAQH CORE X12 Document Submission Service Interface Specification” defines CONNECT specific constraints on the use of the CAQH CORE Connectivity Rule. The figure below presents the components of a transaction using CONNECT with the NwHIN Exchange CAQH CORE X12 Document Submission Service Interface Specification:Figure STYLEREF 1 \s 8 SEQ Figure \* ARABIC \s 1 3: CONNECT w/ X12 275Note: Per specifications, encoding for XDR may be indicated in the metadata, and encoding must be Base64.Table STYLEREF 1 \s 8 SEQ Table \* ARABIC \s 1 1: XD* Submission Set MetadataS.NoExisting or ExtensionXD* Metadata AttributeDefinitionData TypeRequired1ExistingAuthorRepresents the humans and/or machines that authored the document. This attribute contains the following sub-attributes: authorInstitution, authorPerson, authorRole, authorSpecialty, authorTelecommunication?R21.1ExistingauthorInstitution (sub-attribute of author)XON.1 - Name of the Provider or Agent sending the request XON.10 - ID of the Provider or Agent sending the requestXONR21.2ExistingauthorPerson (sub-attribute of author)Contact person for administrative questionsXCN.2 - Last NameXCN.3 - First NameXCN.4 - Middle NameXCN.5 - SuffixXCN.6 - PrefixXCNO1.3ExistingauthorTelecommunicationTelephone/fax/email for esMD administrative questionsXTN.1 - [NNN] [(999)]999-9999 [X99999] [B99999] [C any text]XTN.4 - Email AddressXTN.6 - area codeXTN.7 - phone numberXTN.8 - extensionXTNO2ExistingCommentsDescription of reason for the replacement, follow up, or termination for a prior request?O3ExistingcontentTypeCodeThe code specifying the type of clinical activity that resulted in placing these XDS Documents in this XDS-Submission Set. These values are to be drawn for a vocabulary defined by the XDS Affinity Domain.R24ExistingcontentTypeCodeDisplayName R25ExistingentryUUIDA unique ID or a globally unique identifier within the document submission request for the SubmissionSet. Intervening portal generates this as part of generating the XDR/XDM messageUUIDR6ExistingintendedRecipientIntended Recipient represents the organization(s) or person(s) for whom the Document Submission set is intended.The Intended Recipient for the Registration Request will be a Payer or Payer Contractor to whom the Provider or Agent sends the message. This Intended Recipient will be identified by the Unique Payer ID.For Payer, use XON datatype:XON.1 - Organization NameXON.10 - Organization NPI or Alternate IDXON/XCNR27ExistingpatientIDThe patientId represents the subject of care of the document.?R28ExistingsourceIDGlobally unique identifier, in OID format?R9ExistingsubmissionTimePoint in Time at the Document Source when the Submission Set was created and issued for registration to the Document Registry. Shall have a single value.This shall be provided by the Document Source (in case of e-mail with significant delay).Timestamp should be to at least the secondDTMR10ExistingtitleRepresents the title of the Submission Set. ?O11ExistinguniqueIDA globally unique identifier, in OID format, assigned by the Sender to the submission set in the transmission. The length of this Unique Identifier shall not exceed 128 bytes.?RTable STYLEREF 1 \s 8 SEQ Table \* ARABIC \s 1 2: XD* Document Entry MetadataS.NoExisting or ExtensionXD* Metadata AttributeDefinitionData TypeRequired1ExistingauthorRepresents the humans and/or machines that authored the document. This attribute contains the following sub-attributes: authorInstitution, authorPerson, authorRole, authorSpecialty. Note that the sender information is carried in the Submission Set author attribute, not necessarily this one. R21.1ExistingauthorInstitution (sub-attribute of author)XON.1 - Name of the Provider or Agent XON.10 - ID of the Provider or Agent fXONR21.2ExistingauthorPerson (sub-attribute of author)Contact person for esMD administrative questionsXCN.2 - Last NameXCN.3 - First NameXCN.4 - Middle NameXCN.5 - SuffixXCN.6 - PrefixXCNO2ExistingclassCodeThe code specifying the particular kind of document. Supports environments where content is provided without context, for example a PDF document or a patient's document as patients do not understanding coding systems. Could consider a well-known class code which identifies the entry as a "directed" entry.XDR/XDM - R23ExistingclassCodeDisplayNameThe name to be displayed for communicating to a human the meaning of the classCode. Shall have a single value for each value of classCode.XDR/XDM - R24ExistingcommentsDescription of reason for the replacement, follow up, or termination for a prior requestO5ExistingconfidentialityCodeThe code specifying the level of confidentiality of the Document.XDR/XDM - R26ExistingcreationTimeRepresents the time the author created the document in the Document Source. Shall have a single value. If the creation time of the document is unknown it is better to specify nothing than use a value that is misleading.DTMXDR/XDM - R27ExistingentryUUIDA unique ID or a globally unique identifier within the document submission request for the SubmissionSet. Intervening portal generates this as part of generating the XDR/XDM messageUUIDR8ExistingformatCodeGlobally unique code for specifying the format of the document. XDR/XDM - R29ExistingformatCodeDisplayNameThe name to be displayed for communicating to human readers the meaning of the formatCode.XDR/XDM - R210ExistinghashHash key of the request/response XML document.SHA1XDR - OXDM - R11ExistinghealthcareFacilityTypeCodeThis code represents the type of organizational setting of the clinical encounter during which the documented act occurred.XDR/XDM - R212ExistinghealthcareFacilityTypeCodeDisplayNameThe name to be displayed for communicating to a human the meaning of the healthcareFacilityTypeCode. Shall have a single value corresponding to the healthcareFacilityTypeCode. XDR/XDM - R213ExistinglanguageCodeSpecifies the human language of character data in the document. The values of the attribute are language identifiers as described by the IETF (Internet Engineering Task Force) RFC 3066.XDR/XDM - R214ExistingmimeTypeMIME type of the document in the Repository. Shall have a single value.R15ExistingpatientIDThe patientId represents the subject of care of the document.XDR/XDM - R216ExistingpracticeSettingCodeThe code specifying the clinical specialty where the act that resulted in the document was performed.XDR/XDM - R217ExistingpracticeSettingCodeDisplayNameThe name to be displayed for communicating to a human the meaning of the practiceSettingCode. Shall have a single value corresponding to the practiceSettingCode.XDR/XDM - R218ExistingsourcePatientIdThe sourcePatientId represents the subject of care medical record Identifier (e.g., Patient Id) in the local patient Identifier Domain of the Document Source. It shall contain two parts:Authority Domain IdAn Id in the above domain (e.g., Patient Id).XDR/XDM - R219ExistingtitleRepresents the title of the document. Max length shall be 128 bytes in UTF-8 format.O20ExistingtypeCodeThe code specifying the precise kind of document R221ExistingtypeCodeDisplayNameThe name to be displayed for communicating to a human the meaning of the typeCode. Shall have a single value corresponding to the typeCode.R222ExistinguniqueIDGlobally unique identifier for the document in submission-set assigned by the Document Source in OID format. Shall have a single value.A globally unique identifier assigned to each document in the SubmissionSet. The length of the Unique Identifier shall not exceed 128 bytes. The structure and format of this ID shall be consistent with the specification corresponding to the format attribute. This ID will be generated based on the UUID.Generated based on the UUID. The same ID will be returned with the response message.R23ExistingURIRequired in XDM to address the location in the zip package of the documentXDR - OXDM - RD.5.1 esMD Security MetadataWhen using CONNECT, the Security Metadata must be placed in the Body element of the SOAP envelope. Refer to illustration in section REF _Ref404291589 \r \h 0: REF _Ref404291591 \h D.3.1 Security Metadata.D.5.2 Error HandlingXD* error codes are defined in Section 4 of Integrating the Healthcare Enterprise’s (IHE’s) Information Technology Industry (ITI) Technical Framework, Volume 3. For errors related to processing the XD* metadata, the esMD Response to a Registration Request will use the XD* error codes.For errors related to processing the esMD Security metadata in the context of Provider Registration, the esMD Response to a Registration Request will use the esMD security specific error codes identified in REF _Ref342463211 Error! Reference source not found.. REF _Ref342463211 Error! Reference source not found. shows the esMD error, the esMD error code, and a description of information which will populate the fields of the ebRS RegistryResponse. Application processing errors shall be communicated in an ebRS RegistryResponse using the Insurance Business Process Application Error Codes. It is the responsibility of the responder to select an appropriate error code from the Insurance Business Process Application Error Codes; codes that are highly relevant to the esMD Registration Request are identified in Section REF _Ref342464106 \n Error! Reference source not found., REF _Ref342464137 Error! Reference source not found.. The ebRS RegistryResponse errorCode field must contain the selected esMD error or Insurance Business Process Application Error Codes. When the error has been caused by a specific HPD Plus attribute, the ebRS RegistryResponse location field should identify the Object Class and Attribute that caused the error.D.6 Overview of payload over Direct (X12 Message)This section defines how a transaction may be sent using Direct. The figure below presents the components of a transaction over Direct:Figure STYLEREF 1 \s 8 SEQ Figure \* ARABIC \s 1 4: Direct MessageNote: XDM and XDR metadata allow for indication of encoding method. This method must be Base64. XDM is optional in cases where more than one clinical document is included in Attachment 1.D.6.1 Overview of payload over DirectThis section defines how a transaction may be sent Direct. The figure below presents the components of a transaction over Direct:Figure STYLEREF 1 \s 8 SEQ Figure \* ARABIC \s 1 5: Direct MessageNote: XDM and XDR metadata allow for indication of encoding method. This method must be Base64. XDM is optional in cases where more than one clinical document is included in Attachment 1.ASC X12N Standards transaction and error flowASC X12N has created several standards for enveloping the Attachment NOTEREF _Ref336509233 \f \h 99Fast Healthcare Interoperability Resources (FHIR)F.1 What is FHIRInsert Implementation Guide Overview hereF.2 Introduction to FHIR ResourcesInsert Document Template description hereF.3 Use of FHIR to solict and exchange AttachmentsInsert LOINC Code mapping here ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download