CDAR2 IG Supplement to IHE Consolidated Templated Guide€¦ · Web view · 2012-07-18Should we...

CDAR2_IG_SUPPLEMENT_TO_IHE_CONSOL

Implementation Guide for CDA Release 2.0Supplement to Consolidated CDA Templates

(US Realm)DRAFT

September 2012

© 2012 Health Level Seven, Inc.Ann Arbor, MIAll rights reserved.

Primary Editor/ Co-Chair:

Jim McKinley Blue Cross and Blue Shield of [email protected]

Co-Editor:

Co-Editor/Co-Chair:

Durwin Day Co-Editor:

Co-Editor/Co-Chair:

Craig Gabron Co-Editor:

Co-Editor: ??? Technical Editor:

??????

NOTES FOR DISCUSSION WITH CO-CHAIRS Should we include a different list of acceptable media types? We

can use CCDATG’s list, however it includes MS Word and we recall some reluctance to include for attachments.

Value Set: SupportedFileFormats 2.16.840.1.113883.11.20.7.1 STATIC 20100512Word Processing/Narrative Formats CodeMSWord application/msword*PDF application/pdfPlain Text text/plainRTF Text text/rtfHTML text/htmlGraphic Formats CodeGIF Image image/gifTIF Image image/tiffJPEG Image image/jpegPNG Image image/png

What about New Attachment Type acquisition?

Supplement to HL7 Implementation Guide for CDA R2 Consolidated CDA Templates © 2012 Health Level Seven, Inc. All rights reserved. Sept 2012

mailto:[email protected]

AcknowledgementsThe writers and editors of this document want to acknowledge the years of hard work and dedicated efforts of the current and past members of the Attachments Special Interest Group (ASIG), the Structured Documents and Attachments Work Groups at HL7 in building forward the research and development needed to achieve the goal of information exchange between the provider community and health plans/healthcare insurance companies.

The information needs of the industry that were identified and developed over the years became key input into the foundational content found in the CCDATG. This standard is expected to be widely used in the exchange of clinical information between providers as well as providers and patients in satisfying many exchange criteria established under the Medicare/Medicaid EHR Incentive Program (aka, Meaningful Use).


b3664, 06/26/12,

Need a more formal stipulation as to regulation, etc.

Table of Contents1 PREFACE...........................................................................................................................7

1.1 Revision History.......................................................................................................7

2 INTRODUCTION................................................................................................................82.1 Audience..................................................................................................................82.2 Purpose....................................................................................................................82.3 Scope.......................................................................................................................82.4 Approach.................................................................................................................92.5 Organization of This Guide.......................................................................................92.6 Consolidated CDA Templated Guide (CCDATG)........................................................92.7 Additional Attachment Information Requesting and Responding...........................10

2.7.1 Additional Attachment Information Request......................................................122.7.2 Additional Attachment Information Response....................................................122.7.3 Solicited Reponse..............................................................................................132.7.4 Unsolicited Reponse..........................................................................................132.7.5 Understanding attachment activities.................................................................13

2.8 Definitions, Glossary and Acronyms.......................................................................152.8.1 Definitions.........................................................................................................152.8.2 Acronyms..........................................................................................................16

2.9 Health Level Seven Organization...........................................................................16

3 UNDERSTANDING CCDATG.............................................................................................173.1 What is Clinical Document Architecture (CDA)?.....................................................173.2 Taking Advantage of Structured/Unstructured Content.........................................18

3.2.1 Structured Content............................................................................................183.2.2 Unstructured Content........................................................................................193.2.3 Mobile Devices?.................................................................................................193.2.4 Explanation of Levels 1, 2 and 3........................................................................19

3.3 What is CCDATG?...................................................................................................193.4 Human Readable and Computer Processable Content...........................................20

4 ADDITIONAL INFORMATION (ATTACHMENTS) GENERAL..................................................224.1 Standards to accomplish information exchange of the request and response.......224.2 LOINC (Logical Observable Identifiable Names and Codes)....................................22

4.2.1 LOINC Codes for Electronic Supporting Documentation.....................................22


4.2.2 LOINC Names and Identifiers.............................................................................254.2.3 The LOINC Committee.......................................................................................264.2.4 Obtaining the LOINC Database..........................................................................26

4.3 Requesting Attachment Information......................................................................264.3.1 Using LOINC Code to request electronic documents..........................................264.3.2 Using “Modifiers” LOINC Code to constrain the request....................................26

4.4 Responding with Attachment Information..............................................................274.5 Solicited and Unsolicited Attachment Information.................................................274.6 Using the LOINC Database to Identify Valid Attachment Types..............................274.7 ISO Object Identifiers (OID’s).................................................................................27

5 ADDITIONAL INFORMATION (ATTACHMENTS)USE CASES................................................29

6 IMPORTANT INFORMATION NOT ADDRESSED IN THIS SUPPLEMENT...............................306.1 STUBB....................................................................................................................31

7 OBTAINING NEW ATTACHMENT TYPES............................................................................327.1.1 Placeholder language (if needed)......................................................................34

APPENDIX A — USINESS REQUIREMENTS FOR TRANSPORT (ENVELOP) MESSAGE OR TRANSACTION................................................................................................................36

APPENDIX B — BUSINESS REQUIREMENTS FOR REQUEST, RESPONSE AND ACKNOWLEDGEMENT STANDARDS.................................................................................37

APPENDIX C — ASC X12 STANDARDS THAT SATISFY THE BUSINESS REQUIREMENTS LISTED IN APPENDIX A....................................................................................................38

APPENDIX D — PLACEHOLDER...........................................................................................39


Table of FiguresFigure 1: Constraints format example...................................................................................18

Table of Tables

No table of figures entries found.


1 PREFACE

1.1 Revision HistoryThe following provides a historical view of the iterations for this document and why each major revision was made.

Date PurposeSeptember 2012 Version 1.0


2 INTRODUCTIONThis guide is intended to be used in conjunction with the Consolidated CDA Templated Guide (CCDATG) to describe to HealthCare industry stakeholders how to implement components of the CCDATG for the purposes described in this guide in section 2.2 below.

2.1 AudienceThe audiences for this implementation supplement are the architects, developers and implementors responsible for the exchange of supporting/attachment information between a provider and a healthcare entity such as a health plan or a health insurance company (hereafter known as ‘payers’).

2.2 PurposeThis guide is intended to be used as a supplement to the CCDATG. It endeavors to provide guidance to implementors as they exchange “supporting information” typically needed by payers from providers. Examples of healthcare activities requiring this supporting information include but are not limited too additional information:

In support of a healthcare claim or encounter In support of healthcare services review (e.g., Prior

authorizations/pre-certifications, referrals) Needed for post adjudicated claim audits

For the purposes of this supplement, healthcare “supporting/attachment information” will be referred too as “Attachments”.Attachments are a means of electronically exchanging supporting information to augment each of the examples above. The ultimate goal of Attachments standardization in providing structured, standardized electronic data is to enable the fully automated exchange and processing of supplemental information in the various health care activities shown above. While some processes will always require human intervention, use of fully structured attachments may significantly reduce human intervention and turnaround time for adjudication or resolution.

2.3 ScopeThis supplement is limited in scope to those functions which support the exchange of healthcare information between providers and payers in support


b3664, 07/10/12,

May need to broaden the audience in scope, and use these as ‘examples’.

of administrative business functions of both as identied in section 2.2 of this supplement.

2.4 ApproachINFORMATION SHOULD BE INSERTED HERE REGARDING THE INDUSTRY OUTREACH TO DEVELOP THE ATTACHMENTS CONTENT TO DATE.The Attachments Work Group (AWG) at HL7 had been developing the needed supporting information content for the purposes of claims attachments ever since the HIPAA Transactions and Codeset regulations were implemented. As well, they had spent many of those years writing additional information specifications focused to that end. With the advent of “Meaningful Use” and its clinical document exchange requirements between providers and other legally permitted entities, along with it’s similarity to the business model for clinical document exchange previously described in the Attachments model, a re-assessment of the attachments model was undertaken. It revealed that the CCDATG was going to be the standard for this exchange, and that the content found in the CCDATG was largely consistent with that needed for Attachments purposes.After much discussion, the AWG decided that it just did not make sense for providers and/or their vendors to have multiple formats for this exchange based on who the recipient was. Rather than having one standard format for the provider-to-provider information exchange and another (the additional information specifications) for provider-to-payer information exchange, the AWG agreed to adapt their approach to leverage and be consistent with that of the CCDATG with respect to formatting of clinical documentation.Next, the AWG set about making a comparison of the content found in the CCDATG and that found in the additional information specifications, which was the original Attachments specifications that were initially developed. Supporting information found in the additional information specifications needed for purposes described in section 2.2 and not already in the CCDATG was identified and passed to the Structured Document Work Group for inclusion into the CCDATG. Information found in the CCDATG but not in the additional information specifications was evaluated and found to be acceptable for the purposes of claims attachments. The result was information from the original additional information specifications being added to the CCDATG. Because CCDATG was intended to have a broad industry footprint, it did not make sense to include any information specific to implementations as described in section 2.2, hence the reason this supplement being prepared.


McKinley Desktop, 06/24/12,

This needs to be better described

b3664, 07/10/12,

May consider at background/historical instead.

2.5 Organization of This GuidePLACE HOLDER (complete when guide finalized)

2.6 Consolidated CDA Templated Guide (CCDATG)FILL IN INFORMATION ABOUT “WHY” CCDATG, OVERALL CONTENT (8 structured, 1 unstructured), ETC.

2.7 Additional Attachment Information Requesting and Responding

Typically, in the course of doing business payers occasionally will need additional information from a provider to determine if the level of service being performed or requested is consistent with the patients insurance benefits. As well, payers have general medical policies established that also must be checked for consistency with the patients insurance benefits. There must be a consistent method for requesting the additional information from the provider, and one for the provider to respond with or convey this information to the payer.The request of attachments information is always triggered by a business event of some kind which involves the recognition/awareness of the need for additional information. That triggering event may happen in a variety of ways and may occur in electronic or non-electronic form. Examples include, but are not lmited too, the following:


Table 01: Attachments Activity TableBusiness Event

DescriptionTriggering Request

Event Request Type Response Type

Business Case Type

A payers receipt of a claim that requires additional information prior to adjudication.

The receipt of the claim needing additional information

Electronic Electronic Solicited

A payers receipt of a claim that requires additional information prior to adjudication.

The receipt of the claim needing additional information

Electronic Non-electronic

Out of Scope1

A payers medical policy requirements/rules where the providers knows at the time of the claim billing that they must provide additional information with the billing

The providers awareness that additional information is required when submitting a certain type of claim.

Non-electronic Electronic Unsolicited

A payers medical policy requirements/rules where the provider knows in advance they must provide additional information to the payer before rendering the service or delivering the supply/product to the patient without using an electronic request

The providers decision to render a service or deliver a supply/product to the patient for which they knew a payer requirement/rule existed


A payer and provider mutually agree at any time to provide additional information without using an electronic request

Anything from a phone conversation, a postal letter, patient communication, etc


It is important to note that in all cases the request for additional attachment information comes in one of two forms, electronic or non-electronic. This supplement takes no position regarding the requirement to use electronic requests or responses, rather it simply addresses how to accomplish the information exchange when electronic requests or responses are used.For the purposes of this supplement, we will use the terms “Solicited” and “Unsolicited” to help clarify the scenarios (business cases) for which one or more standards are to be used. A response, whether Solicited or Unsolicited, refers to the act of providing additional attachment information needed. A Solicited Response is in response to an electronic request. An Unsolicited Response is in response to a non-electronic request. In both the Solicited and Unsolicited scenarios, the primary differentiator is whether an electronic 1 Is is important to note that header in either structured or unstructured scenarios is always considered structured and as such, available for computer processing to occur with it’s content.


b3664, 07/10/12,

Consider alternative that doesn’t imply paper (i.e., doesn’t use a Standard)

standard request was what triggered the response, where Solicited is triggered and unsolicited is not triggered by an electronic standard request.

Scenario Request mechanism Response Mechanism

N/A (Not in Scope) Non-electronic Non-electronicUnsolicited Non-electronic Electronic

Solicited Electronic Non-electronicSolicited Electronic Electronic

NPRM LANGUAGEIn general, health care providers will submit their electronic health care claims attachment information to the health plan for certain claim types, upon request, after the health plan has received and reviewed the claim. This follows the course of claimsadjudication today.

Health plans may also request, in advance, that additional documentation (the attachment) accompany a certain type of claim for a specific health care provider, procedure, or service. The ASIG refers to this scenario, of sending attachment information with the initial claim, as an unsolicited attachment because a request was not made after the fact, using the standard request transaction.

We are proposing that health care providers may submit an unsolicited electronic attachment with a claim only when a health plan has given them specific advance instructions pertaining to that type of claim or service.

We are proposing such a restriction around ‘‘unsolicited’’ electronic attachments, because we believe that there are legal, business, and technical implications for health care providers, health plans, and their business associates for handling and processing unsolicited attachments without prior direction. If health care providers were permitted to submit unsolicitedelectronic attachments with any claim without prior arrangement with the health plan, there would be a number of issues, including compliance with the Privacy Rule’s minimum necessary standards, and identifying the new business and technical procedures health plans would need to develop to review, evaluate, store, return, or destroy the unsolicited documents. Similarly, health care providers would need systems and processes to track submissions and returns.

2.7.1 Additional Attachment Information Request Additional attachment information requested by an originator and

requested of an information source

2.7.2 Additional Attachment Information Response Additional attachment information responded with from the

information source back to the request originator



This scenario is OMITTED in the X12 Standards, but doesn’t appear to be prohibited in the original NPRM.

2.7.3 Solicited Reponse a response from one party to another for additional information to a

Solicited Request

2.7.4 Unsolicited Reponse additional information provided from one party to another based on a

rule (condition/parameter) being met, where that rule was mutually agreed upon by the two parties well in advance of the event, such as a claim or prior authorization

2.7.5 Understanding attachment activities Because this supplement addresses all facets of the process in requesting of and responding with attachments information, and because the actors role will vary depending on the activity type, a table has been developed to help better understand these activities. Each row in the table represents a unique attachment activity that would require a unique business flow to describe the activity. As well, each row will call for a unique set of electronic standards to be used for each.As described later in Section 4.1 of this supplement, there are multiple standards available in the industry to accomplish the exchange of information for attachment purposes (i.e., request, response, acknowledgement, etc). For the purpuses of this supplement and the anticipated attachments regulation, example scenarios and use cases will reference those ASC X12 standards previously developed to accomplish attachments information exchange. Table 02 (Attachments Activity Table) below describes all scenarios addressed by this supplement for attachment exchange purposes. Column headings and table values are described below:

Business Need – The need of the originating actor for the ‘request’ activity type within the Business Need entry

Activity ID – A symbolic ID used to express, in abrieviated form, the attachment activity. (NOTE: This ID will be used to uniquely determine the standard(s) necessary to accomplish the attachments activity described in the row of the table)

Activity Type – Describes the type of activity of the originating actoro Request – electronically requested attachment informationo Response – attachment information provided in response to an

electronic requesto “Requested in Advance” Response – attachment information

provided in response to an “advance” non-electronic request for


attachment information typically based on a “rules based” request (i.e., mutually known rules, policy or guidelines).

Basis for Activityo Solicited – attachments information that is electronically

requested or the response to a electronic request.o Unsolicited – attachments information provided from the

originator to the receiver based ONLY on an “rules based” request and in the absence of an electronic request. It is important to understand that an “rules based” request is not in scope for this supplement since it is typically known to the receiver and not in electronic form. This is NOT meant to imply that attachment information should ever be exchanged without some form of a request.

Actoro Originator – the actor originating or initiating the attachments

activityo Receiver – the actor receiving the attachments activity

Table 02: Attachments Activity Table2

Business Need Activity ID

Originator Activity Type

Basis for Activity Actor

Solicited Unsolicited Originator Receiver

Claims Attachment

#1 Request X Payer Provider#2 Response X Provider Payer

#3“Requested in

Advance” Response

X Provider Payer

Prior Auth Attachment

#4 Request X Payer Provider#5 Response X Provider Payer

#6“Requested in

Advance” Response

X Provider Payer

Referral Attachment

#7 Request X Referred to provider

Referred from provider

#8 Response X Referred from provider

Referred to provider

#9“Requested in

Advance” Response

X Referred from provider

Referred to provider

2


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 “business need” “Solicited / Unsolicited” “Originator Activity Type” for additional information from the “Originator” to the “receiver”.By substituting the row values found for each of the heading column 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:

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 response for additional information from the provider to the payer

Activity #3 represents the information exchange for the Claims Attachment unsolicited “requested in advance” response for additional information from the provider to the payer

Activity #4 represents the information exchange for the prior auth attachment solicited request for additional information from the payer to the provider.

Activity #5 represents the information exchange for the prior auth attachment solicited response for additional information from the provider to the payer.

Activity #6 represents the information exchange for the Prior Auth attachment unsolicited “requested in advance” response for additional information from the provider to the payer.

Activity #7 represents the information exchange for the Referral Attachment solicited request for additional information from the referred to provider to the referred from provider.

Activity #8 represents the information exchange for the Referral Attachment solicited response for additional information from the referred from provider to the referred to provider.

Activity #9 represents the information exchange for the referral attachment unsolicited “requested in advance” response for additional information from the referred from provider to the referred to provider.


The purpose of doing this will be to allow for standards correlation to each of the activity ID’s with a current X12 standard….and later, if regulation expands to include it, other standards like IHE Profiles, HL7 Messaging Standards, etc.

2.8 Definitions, Glossary and Acronyms

2.8.1 DefinitionsAttachment Document. The CDA document that is part of an Attachment Package.Attachment Package . The combination of a CDA document and any adjunct files (e.g., images) that are transmitted together in fulfillment of an administrative transaction (e.g., included in the BGN segment of an ASC X12 275 transaction as transmitted from a provider to a payer). For HIPAA, the Attachment Package defines the full requirements of the required administrative transaction.Computer-decision variant . An instance of a CDA attachment with enough structure and coding so that it can be rendered with detailed data suitable for a computer decision algorithm. Attachments in the computer-decision variant can also be rendered so that a person can make a decision based on its contents. Contrast with human-decision variant.Human-decision variant. An instance of a CDA attachment intended solely for rendering so that a person can make a decision based on its contents. Contrast with computer-decision variant.Object 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 leaf.

2.8.2 AcronymsTo aid the implementer, this section will restate any acronyms used in this supplements in one common place.

CCDATG Attachments Payer


b3664, 07/16/12,

COPIED FROM ORIGINAL IG

2.9 Health Level Seven OrganizationFounded in 1987, Health Level Seven, Inc. (http://www.HL7.org) is a not-for-profit, ANSI-accredited standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services.HL7 complements ASC X12 in that its interests have been to support the clinical processes, whereas Task Group 2, X12N (the Healthcare Task Group of the Insurance Subcommittee of X12) focuses on administrative and financial processes within healthcare.For information on membership and obtaining HL7 standards, contact:

Health Level Seven3300 Washtenaw Ave., Suite 227Ann Arbor, MI 48104-4261(734) 677-7777mailto:[email protected] http://www.hl7.org


b3664, 07/17/12,

COPIED FROM OLD IG

http://www.hl7.org/

mailto:[email protected]

http://www.HL7.org/

3 UNDERSTANDING CCDATGThis Section will explain the CCDATG at a high level. Implementers should rely on the detail found in the CCDATG itself to provide guidance as to how to utilize that Standard. Below you will find the basics of CCDATG.

3.1 What is Clinical Document Architecture (CDA)?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. A CDA document has two primary groupings of information, a header and a body:

The headero Identifies and classifies the document and provides information

on authentication, the encounter, the patient, and the involved providers.

The body o Contains the clinical report, organized into sections whose

narrative content can be encoded using standard vocabularies.o 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, etc. The


b3664, 07/10/12,

Insert language stating that this is ONLY a high level,and by no means the authority….implementors should fully rely on the CCDATG for technical guidance.May be more appropriate in appendix.

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 supplement: A header paired with a structuredBody element will be referred

too as a “Structured Document”. A header paired with a nonXMLBody will be referred too as an

“Unstructured Document”3.More information about CDA can be found on the HL7 website (www.hl7.org).

3.2 Taking Advantage of Structured/Unstructured Content Use of the CDA standard allows for a wide-range of implementation flexibility with respect to the implementors (CDA originator and consumer) technical abilities. For the most novice of implementations, in most cases a CDA document may simply be rendered to a common internet XML aware brower using an XSL style sheet4, much like one might view a PDF on a personal computer application. Even an unstructured document may be rendered using a style sheet. The exception to this would be an Unstructured Document where the body content contained a media type (i.e., JPEG, GIF, PDF, etc) that would require additional software to interpret and render this encapsulated data. For move advanced implementations, that same CDA document may have its contents examined and discrete information extracted and be made available for computer usage/processing.The approach of using a style sheet to render a CDA document to a browser sets a low bar for originator and receiver of a CDA document. No matter what the technical level of the originator, the receiver will have the choice of leveraging the originators highest level of technical sophistication or simply chose to render using a browser. This may help the payers initially as they aren’t as familiar with CDA as the provider community is.Initially the limited capability of participants to support fully structured attachments and the need for further development of attachment content 34



KEEP/REWORD?

b3664, 07/10/12,

May need to constrain to ONLY internet and not mobile devices.


Will the style sheet supplied with the CCDATG also work with unstructured ??? for textual only?ALSO, we need to fully understand if the Header will ALWAYS be renderable or not?

b3664, 07/10/12,

Is this media or format?


Example – nonXMLBody:A nonXMLBody contains a text element, which has an optional mediaType attribute which identifies the encoding of the encapsulated data and identifies a method to interpret or render the data. Preferred mediaType values include "image/gif", "image/tiff", "text/rtf", "application/pdf", "image/g3fax", "text/html", "image/jpeg", "image/png", and "text/plain".A text element may contain a reference or thumbnail element. The reference has a required attribute of value, which contains a URL pointing to the external object. It may also contain an optional useablePeriod that can declare the length of time the object will be available.A component with a nonXMLBody:<component> <nonXMLBody> <text mediaType="text/plain"> <reference value="patient.txt"/> </text> </nonXMLBody></component>

http://www.hl7.org/

requires the use of the unstructured content capability of the CCDATG. For attachment purposes, even though a structured document format is defined in CCDATG, the use of the unstructured document option for those same document types defined in structured content is not expressly prohibited, provided that the required content defined for the structured document content is present in the unstructured document representation.

3.2.1 Structured Content Must follow conformance statements found in CCDATG.

3.2.2 Unstructured Content Must be limited to document types defined on Regenstrief

database tab (XXX). May include document content for document types already defined

in CCDATG as structured, but unstructured content must adhere to conformance statements described in the structured content.

If the request was for sub-document level information (section or entry), the unstructured format may be used for that section or entry. In this case, conformance criteria for a given section or entry may or may not be identical within structured documents those sections or entries are found. In this case, conformance requirements would all be considered as optional with the expectation that if the responder has the information that they should include it.

3.2.3 Mobile Devices?????

3.2.4 Explanation of Levels 1, 2 and 3????

3.3 What is CCDATG?CCDATG is a guide defining clinical information format based on CDA, constrained by conformance statements consistent with industry best practices for specific types of clinical documents. Some broadly used document types have been more fully developed in CDA than others. Examples of those document types include:

o CCD


b3664, 07/18/12,

Perhaps coveres min necc is concerns are raised.

b3664, 07/17/12,

Need to format better

b3664, 07/17/12,

Need to format better

o Consultation Noteo Diagnostic Imaging Reporto Discharge Summaryo History and Physicalo Operative Noteo Procedure Note o Progress Note

Other clinical information not listed above may be also exchanged using CCDATG by taking advantage of the unstructured content section, as described in Section 3.9 of the CCDATG. Throughout the CCDATG implementors will see references to sending and receiving EHR systems. This is because the CCDATG was written from the perspective of exchange between EHR systems. For the purposes of this supplment there is no assumption that exchange will occur between 2 EHR systems. Instead, as you will see in the use case section (section ?.?) the additional information a payer is seeking may exist in an providers electronic repository, such as an EHR system and may/maynot be passed through a practice management system or be sourced directly from the EHR.Section 1.5 of the CCDATG 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 3.1 through 3.8 of the CCDATG.

3.4 Human Readable and Computer Processable ContentThere are two variants of a CDA document when used as an attachment. These are as follows: The human-decision variant (HDV) is used solely for information that will be rendered for a person to look at, in order to make a decision. HL7 provides a non-normative style sheet for this purpose. The HDV is not required to have structured or coded answers. The only LOINC value used in an HDV CDA document is the LOINC for the Attachment Type Identifier. There are two further alternatives within the human-decision variant.


b3664, 07/12/12,

COMPLETELY CAPTURED FROM ORIGINAL IG


NEED A SECTION

It can be a single <nonXMLBody> (e.g., an image or scanned image) element that is embedded in the transaction or is a reference to an external file that provides the content for the body of the document, or It can contain a <structuredBody> element containing free text in XML elements that organize the material into sections, paragraphs, tables and lists as described in the subsequent sections of this document. The computer-decision variant (CDV) has the same content as the human-decision variant, but additional structured information and LOINC coded data is included so that a computer could provide decision support based on the document. Attachments in the CDV can be rendered for human decisions using the same style sheet that HL7 provides for rendering documents formatted according to the human-decision variant.These variants do not differ in functional content. All variants of the same attachment have required and optional content as specified in the Additional Information Specification document for that attachment. The variants only differ with regard to whether structured and coded data is mandated.Both variants place constraints upon what information must be present in the CDA to support the Attachment use case, described in Section 1.1 of each AIS document. Additional CDA structures (document sections, entries, etc.), may be present to support use cases other than those defined by this implementation guide. Anything not explicitly prohibited by the AIS may be present in the CDA document to support use cases other than those defined therein.HL7 has provided one or more XML stylesheets as part of this implementation package; however, these are neither balloted standards, nor are they required for use under HIPAA. Use of HL7 provided stylesheets is entirely up to the implementer.


4 ADDITIONAL INFORMATION (ATTACHMENTS) GENERAL

In general, the attachments request/response from between the provider and the payer will be using a standard not developed by HL7 nor included in either this document or the CCDATG. Business requirements of that standard will be specified in Appendix “A”.

4.1 Standards to accomplish information exchange of the request and response

The authors of this supplement realize 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 was developed by ASC X12 specifically for the requesting additional information, responding to that request, and acknowledgment of either/both and conforming to the business requirements found in Appendix “A”. Additional information regarding those transactions can be found in Appendix “B” of this document. 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 X12 transaction that could be used5.

4.2 LOINC (Logical Observable Identifiable Names and Codes)

4.2.1 LOINC Codes for Electronic Supporting DocumentationLOINC codes are used to identify:The implicit scope of a request in an ASC X12 277 transaction; e.g., to modify a request for serology lab values to specify only the abnormal results for a period 30 days prior to treatment, as a Modifier Code.An electronic attachment in its entirety (e.g., a request for the Ambulance attachment in support of a claim for ambulance services), as an Attachment Type 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 CDA Header.

5


b3664, 07/12/12,

ALL OF THIS CARRIED FORWARD FROM THE ORIGINAL IG.

b3664, 06/26/12,

Create Appendix and hyperlink

b3664, 06/26/12,

Create hyperlink.

b3664, 06/26/12,

Is this true?

b3664, 06/26/12,

Create Appendix and hyperlink

One or more Attachment Components of an electronic attachment (e.g., a request for the number of miles that the ambulance drove in support of a claim for ambulance services).A part or parts of a clinical report (e.g., the impression section of a radiology report in support of a claim or a specific service), as the Attachment Component identifier appearing in the <code> of the <section> in the CDA document.A category of laboratory results (e.g., hematology results that are related to the claim or a specific service), as the Attachment Component identifier appearing in the <code> of the <section> in the CDA document.A category of medication information (e.g., send the discharge medications that are related to the claim or a specific service), as the Attachment Component identifier appearing in the <code> of the <section> in the CDA document.One of a set of observations that compose a single attachment component (e.g., in an obstetrical study, one code identifies number of prior births, and another distinct code provides the estimated date of delivery), as an Attachment Component Answer Part.LOINC codes used in Additional Information Specifications are obtained by the HL7 ASIG attachment workgroup that developed the content for the specific attachment.Table 1.5-1 below describes briefly the use of LOINC in the various attachment components.


Table 1.5-1 Use of LOINC Codes, ASC X12 Transactions, and HL7 CDA Documents

ASC X12 277/278 ASC X12 275 HL7 CDA

Purpose of Attachment

Request for additional information to support a health care claim OR Services Review

Additional information to support a health care claim or encounter OR Services Review

Provide controlled content for ASC X12 275 BIN segment

LOINC Modifier

Codes

Used in the STC segment of the 277 or HI segment of the 278 to limit the scope or time frame of a request for information. e.g., Send information for up to 90 days before the related encounter

Reiterated in the STC segment

Not used in the CDA document

LOINC Attachment

TypeIdentifier

Used in the STC segment of the 277 or HI segment of the 278 to request an attachment in its entirety, e.g., Send the cardiac rehabilitation treatment plan

Reiterated in the STC segment in solicited method

Used in the <code> element in the header of the CDA document, e.g.This is the cardiac rehabilitation attachment

LOINC Attachment Component

Used in the STC segment of the 277 or the HI segment of the 278 to request a specific attachment component or part of a clinical report, .e.g., Send the rehab treatment plan author

Reiterated in the STC segment in solicited method

Used in the computer-decision CDA variant in the <code> element of a <section> to identify the attachment component being provided, e.g., This is the diagnosis information

LOINC Attachment Component Answer Part

Not used in the 277 Not used in the 275

Used in the computer-decision CDA variant in the <code> element of a clinical statement in an <entry> or <section>, to identify the answer part of an attachment component being provided, e.g., This is the name, identifier and taxonomy

The 275 must repeat the LOINC codes used in the STC segment of the 277 or the HI segment of the 278, but the heading of the CDA document need not. While LOINC Codes are used for questions, answers, and document classification, the queries posed by a LOINC code may be either more specific


or more general than the LOINC codes organizations use to classify clinical documents.

4.2.2 LOINC Names and IdentifiersEach LOINC record corresponds to a component. The LOINC record is a table entry in the LOINC database maintained by the Regenstrief Institute and the LOINC Committee. See section 4.2.4 for information on how to obtain the LOINC database. A LOINC record includes attributes to specify:The numeric code that identifies the component,The component name — e.g., potassium, hepatitis C antigen, distance the patient was transported (by an ambulance)The property reported — e.g., a mass concentration, length (distance)The time aspect — e.g., Whether the measurement is a momentary observation at a point in time, or an observation made over a span of timeThe source of the data used in the reported information — e.g., urine, blood, EMS transport The type of scale — e.g., whether the measurement is quantitative (a true measurement), nominal (red, blue, green), or simply narrative text providing the requested informationWhere relevant, the method used to produce the result or other observationA class code that associates the observation with others in a group, such as the observations associated with an obstetric ultrasound procedure Many medical concepts have multiple LOINC codes. The codes distinguish different methods of making the observation. For example, there are different LOINC codes for manual and automated leukocyte counts. Indeed, there are three codes for the patient’s body weight according to whether it was measured, estimated, or the datum is the weight that the patient reported. Different LOINC codes are also used to distinguish different ways to report the observation. For example, 10221-0 identifies the specimens taken during surgery when reported using narrative text, whereas 8721-3 would identify coded descriptions of the same specimens.LOINC codes may also identify sets of observations. For example, the LOINC code 18674-2 (ALCOHOL-SUBSTANCE ABUSE REHABILITATION TREATMENT PLAN, LONGEST PERIOD OF SOBRIETY FOR ABUSED SUBSTANCE) identifies a set of other observations, identified by other LOINC codes, including 18676-7 (ALCOHOL-SUBSTANCE ABUSE REHABILITATION TREATMENT PLAN, LONGEST PERIOD OF SOBRIETY), and 18675-9 (ALCOHOL-SUBSTANCE ABUSE REHABILITATION TREATMENT PLAN, ABUSED SUBSTANCE).


The LOINC codes are not intended to transmit all possible information about a test or observation. They are only intended to identify the observation. The LOINC code for a name is unique and permanent. The LOINC code has no intrinsic structure except that the last character in the code is a mod-10 check digit. LOINC codes must always be transmitted without leading zeroes and with a hyphen before the check digit (e.g., "8709-8" and "10154-3").The LOINC Committee assigns LOINC codes upon request from various agencies. In the context of attachments, the LOINC codes are obtained by the HL7 ASIG. The ASIG forwards appropriate requests to the LOINC committee for consideration. Requests go through a review process to ensure the concept has not been previously added and the meaning is clear.

4.2.3 The LOINC CommitteeLOINC is a committee of laboratories, system vendors, hospitals and academic institutions organized by the Regenstrief Institute and supported by grants from The John A. Hartford Foundation, Inc., the Agency for Health Policy Research and Development and The National Library of Medicine to create formal names and codes for laboratory results and clinical variables with numeric, coded, or narrative text values. The LOINC codes were designed specifically to provide a universal identifier for clinical observations. It has since been adopted by DICOM as well. For identifying observations in these "messages," the LOINC Committee distributes the over 50,000-record database and the Regenstrief LOINC Mapping Assistant (RELMA) software for perpetual use free via the Internet. Widespread use of LOINC will enable better and more efficient use of computer-stored clinical data.

4.2.4 Obtaining the LOINC DatabaseLOINC codes are registered by Regenstrief Institute and the Logical Observation Identifier Names and Codes (LOINC) Committee.The LOINC database provides sets of universal names and ID codes for identifying laboratory and clinical test results and other units of information meaningful in attachments such as clinical report documents. The LOINC database can be obtained from the Regenstrief Institute at http://www.LOINC.org.


http://www.LOINC.org/

4.3 Requesting Attachment Information

4.3.1 Using LOINC Code to request electronic documents????

Sender/receiver

4.3.2 Using “Modifiers” LOINC Code to constrain the request.

4.4 Responding with Attachment Information

4.5 Solicited and Unsolicited Attachment Information

4.6 Using the LOINC Database to Identify Valid Attachment Types

4.7 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 (http://www.iso.ch), and we will see below that the International Telecommunications Union (ITU, http://www.itu.int) 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.103). 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


b3664, 07/16/12,

GET HELP TO DRAFT THIS CONTENT

http://www.itu.int/

http://www.iso.ch/

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. The leaf may represent an assigning authority (in which case the @S attribute identifies the authority), or an instance of an object. An assigning authority owns a namespace, consisting of its sub-tree.Although OIDs look very obscure at first, they 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." 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.103 (above) was established by HL7 as a globally unique identifier for the ICD-9-CM code set for diagnoses. The numbers in the HL7 OID prefix "2.16.840.1.113883." indicate that:

The OID was assigned by a joint ISO-ITU (2.) assigning authority, it is specific to the country (16.) of the USA (840.) and is specific to the organization (1.)known as Health Level Seven (113883.).

Beyond that, the HL7 organization assigns any numbers - and these are maintained in a registry available on the HL7.org 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, etc.) Additional reference information about OIDs, including the current directory of OIDs assigned by HL7, is available at http://www.hl7.org/oid/index.cfm. 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.


http://www.hl7.org/oid/index.cfm

5 ADDITIONAL INFORMATION (ATTACHMENTS)USE CASES


6 IMPORTANT INFORMATION NOT ADDRESSED IN THIS SUPPLEMENT

In Chapter 5, 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:

1. The CCDATG offers specific document types in structured form along with document types suitable for unstructured format. The unstructured format should never be construed to include the patients entire medical record, unless specifically asked for in the request activity.

2. Timeliness considerations for responses to requests for attachment information may be unique to the stakeholders needs, scenario’s, etc., and establishing standard timeliness guidance should be avoided. However, establishing reasonable expectations minimum and maximum time between request and response may be appropriate.

a. For solicited requests, consideration should be given to the request envelop including a “respond-by” date for the response to be completed on or before that date to successfully complete the attachment activity.

b. For unsolicited requests, policy should be developed to guide payers in claims and prior auth attachment activities and providers in referral attachment activities what to do if the attachment is received but the claim, prior auth or referral never arrives and/or cannot be re-associated with the claim, prior auth or referral itself.

c. Guidance should be developed to communicate the ‘in advance’ payer rules for unsolicited attachment activity, which may include payers publishing on their provider web-sites information or other routine provider communications.

d. 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.

3. Attachment information, by default, is considered at the clinical document level. In some cases, the requestor of attachment information may be needing 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 request it.

4. Use of the unstructured document

6.1 STUBB


7 OBTAINING NEW ATTACHMENT TYPES


b3664, 07/16/12,

GET HELP TO DRAFT THIS CONTENT

Figure 1: STUBBED IN EXAMPLE ONLY

Severity Observation[observation: templateId 2.16.840.1.113883.10.20.22.4.8(open)]

Table xxx: Severity Observation Contexts

Used By: Contains Entries:Reaction Observation Allergy Observation

This clinical statement represents the severity of the reaction to an agent. A person may manifest many symptoms …

Table yyy: Severity Observation Contexts

Name XPath Card.

Verb Data Type

CONF#

Fixed Value

Green Severity Observation

observation[templateId/@root = '2.16.840.1.113883.10.20.22.4.8']

@classCode 1..1 SHALL 7345 2.16.840.1.113883.5.6 (HL7ActClass) = OBS

@moodCode 1..1 SHALL 7346 2.16.840.1.113883.5.1001 (ActMood) = EVN

templateId 1..1 SHALL SET<II>

7347

@root 1..1 SHALL 10525 2.16.840.1.113883.10.20.22.4.8code 1..1 SHALL CE 7349 2.16.840.1.113883.5.4 (ActCode)

= SEVseverityFreeText

text 0..1 SHOULD ED 7350

reference/@value

0..1 SHOULD 7351

statusCode 1..1 SHALL CS 7352 2.16.840.1.113883.5.14 (ActStatus) = completed

severityCoded

value 1..1 SHALL CD 7356 2.16.840.1.113883.3.88.12.3221.6.8 (Problem Severity)

interpretationCode

0..* SHOULD CE 9117

code 0..1 SHOULD CE 9118 2.16.840.1.113883.1.11.78 (Observation Interpretation (HL7))

1. SHALL contain exactly one [1..1] @classCode="OBS" Observation (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6) (CONF:7345).


2. SHALL contain exactly one [1..1] @moodCode="EVN" Event (CodeSystem: ActMood 2.16.840.1.113883.5.1001) (CONF:7346).

7.1.1 Placeholder language (if needed)Placeholder languag


APPENDIX A — USINESS REQUIREMENTS FOR TRANSPORT (ENVELOP) MESSAGE OR TRANSACTION.

Request ActivityResponse ActivityAcknowledgement Activity



Include here instead of Appendix “B”?


We need to develop in english the data we see carried in the X12 request transation(s) that will be essential to any other transport/envelop message/transaction

APPENDIX B — BUSINESS REQUIREMENTS FOR REQUEST, RESPONSE AND ACKNOWLEDGEMENT STANDARDS.



If we’re going to utilize acknowledgements, what are we needing to be acknowledged. Does this include something wrong in the CCDATG CDA document?

APPENDIX C — ASC X12 STANDARDS THAT SATISFY THE BUSINESS REQUIREMENTS LISTED IN APPENDIX A .


APPENDIX D — PLACEHOLDER


CDAR2 IG Supplement to IHE Consolidated Templated Guide€¦ · Web view · 2012-07-18Should we...

Documents

Transcript of CDAR2 IG Supplement to IHE Consolidated Templated Guide€¦ · Web view · 2012-07-18Should we...