Integration Guide for Data Originators of Claim Status Version 1.1 December 23, 2010
Integration Guide for Data Originators of Claim Status Revision History Date Version Description Author November 25, 2009 DRAFT 0.1 Initial Draft J Terrien November 27, 2009 DRAFT 0.2 Edited initial draft. D Callaghan December 2, 2009 DRAFT 0.3 Edited mapping & added branding information J. Terrien January 14, 2010 1.0 Inserted 276/277 sample transactions and finalized J. Terrien December 23, 2010 1.1 Renamed document for clarity, other minor edits D Callaghan Page 2
Integration Guide for Data Originators of Claim Status Table of Contents 1. ABOUT THIS GUIDE...4 1.1 Purpose/Background... 4 1.2 Audience... 4 1.3 Scope... 4 1.4 Related Documentation... 4 2. OVERVIEW...6 3. SERVICE REQUIREMENTS...7 3.1 Connectivity... 7 3.2 Message Versions... 7 3.3 Messages Handled... 7 3.4 Processing Instructions... 7 3.5 Technology Assumptions... 7 4. TRANSACTION REQUIREMENTS...9 4.1 ANSI ASC X12N 276 Health Care Claim Status Request Transaction... 9 4.2 ANSI ASC X12N 277 Health Care Claim Status Response Transaction... 17 5. ERROR HANDLING...18 6. OTHER REQUIREMENTS...20 APPENDIX A: CLAIM STATUS PORTLET USER INTERFACE...21 APPENDIX B: ANSI ASC X12N 276 HEALTH CARE CLAIM STATUS REQUEST...24 APPENDIX C: ANSI ASC X12N 277 HEALTH CARE CLAIM STATUS RESPONSE...25 Page 3
Integration Guide for Data Originators of Claim Status 1. ABOUT THIS GUIDE 1.1 Purpose/Background The purpose of this document is to describe Covisint s standard interface with a claim status information source, using the X12N HIPAA 276/277 transactions to request the status of a health care claim and to respond with the information regarding the specified claim. This specification is not intended to replace the ANSI ASC X12N 276/277 transaction requirements in the National Implementation Guide. This specification contains data clarification derived from specific business rules that apply exclusively for use with Covisint s Claim Status Service. 1.2 Audience This specification is intended for application developers and implementers of electronic claim status services to use in conjunction with the ANSI ASC X12N National Implementation Guide. This document outlines the technology and data flow necessary for engaging in Electronic Data Interchange (EDI) with Covisint. 1.3 Scope 1.3.1 Included Topics An Overview of the data flow of the X12 276/277 transactions between Covisint and the Service Provider (i.e. claim status source or payer) Data transmission detail specific to the Covisint environment (X12 276/277) Valid responses for claim status requests Error handling for syntax, segments, and elements 1.3.2 Excluded Topics Trade Partner (TP) agreements and their scope and content Standard transaction requirements contained in the ANSI ASC X12N National Implementation Guide End user process to create, submit and/or process information contained in the X12 276/277 Batch claim status processing via submission of a batch file containing multiple claim status requests 1.4 Related Documentation 1.4.1 Covisint Documents Page 4 AppCloud TM Federation Technology Guide AppCloud TM Service Provider Health Care Claim Status Transaction
Integration Guide for Data Originators of Claim Status Specification X12N 276-277 Mappings an excel spreadsheet with the X12N Claim Status message that can be used by service providers (payers) for additional mapping analysis Connect Operations - Messaging 1.4.2 Industry Documentation ANSI ASC X12N National Implementation Guide (ASC X12N HIPAA Implementation Guide for Health Care Claim Status Request and Response (ASC X12N 276/277 (004010X092)) www.wpc-edi.com Page 5
Integration Guide for Data Originators of Claim Status 2. OVERVIEW Covisint s Multi-payer Claim Status Service allows a user to submit claim status requests to any supported payer using a single interface. A user can access this service from a community or physician office portal. Service providers (payers) may choose to implement Single Sign-On and User Federation to the Service Provider s web-site to provide additional claim status information and other services to end-users. See Related Documents for more information on this configuration. This solution is intended to support real-time claim status transactions containing a single claim status request. Both synchronous and asynchronous transport protocols are supported to enable participation by the widest range of payers. The following diagram illustrates the data flow for claim status transactions. Figure 1 Claim Status via Community or Physician Practice Portal Page 6
Integration Guide for Data Originators of Claim Status 3. SERVICE REQUIREMENTS 3.1 Connectivity Any Covisint supported transport protocol may be used, including: HTTP(S) LLP (TCP/IP) FTPS AS2 Websphere MQ Refer to the Covisint Connect Operation Messaging document for detailed information on establishing connectivity. 3.2 Message Versions Message requirements and standards are based on the ANSI ASC X12N National Implementation Guide (ASC X12N HIPAA Implementation Guide for Health Care Claim Status Request and Response ASC X12N 276/277 (004010X092)) 3.3 Messages Handled The claim status service is specific to the following ANSI ASI X12N transactions: ANSI ASC X12N 276 Health Care Claim Status Request Transaction ANSI ASC X12N 277 Health Care Claim Status Response Transaction 3.4 Processing Instructions End-user enters patient demographics and claim information (e.g. dates of service, amount billed) for one or more claim status inquiries. User submits the list of claim status inquiries Covisint s Claim Status service creates and sends real-time HIPAA compliant claim status requests to the various payers (service providers), using any Covisint standard transport protocol preferred by each payer. The user can view the submitted transactions in a response queue with the associated status (e.g. completed, waiting for response, error) As each payer (service provider) responds to their claim status inquiry with a claim status response, the transaction is processed and made available for viewing by the end-user (X12 277) 3.5 Technology Assumptions For this solution, Covisint will be a submitter and will use the agreed codes from the TP agreement when submitting claim status transactions to a payer. All claim status transactions will be real-time, containing a single claim inquiry. The 276 and 277 transactions will be linked by the transaction trace number contained in the TRN segment. All 276 requests will contain a TRN segment with a unique transaction identifier. The payer must return this information in the 277 response, as it is used to link the 277 to the original request for routing and display purposes. Covisint s portal based service allows the user to submit claim status requests containing only the minimum search criteria required for HIPAA compliance. Not all payers will support all search Page 7
Integration Guide for Data Originators of Claim Status options and may reply with a claim status category code of claim not found for some inquiries. When the 276 does not uniquely identify a claim within the payer s system, the payer s response may include multiple claims that meet the identification parameters supplied by Covisint. The maximum claims that can be returned in a response is limited to five (5), unless otherwise mutually agreed between Covisint and the payer. Covisint s claim status service does not support inquiries at the service line level. Covisint s claim status service can accept and render for display any HIPAA compliant 277 transaction. However, if a payer has specific requirements for displaying the claim status information that varies from Covisint s standard presentation, then custom mapping will be required. Custom mapping is outside the scope of this document. It is the responsibility of the payers to provide HIPAA compliant 277 transactions. Covisint s claim status service does not perform HIPAA compliance checking. Page 8
4. TRANSACTION REQUIREMENTS 4.1 ANSI ASC X12N 276 Health Care Claim Status Request Transaction The following are the attributes and requirements for the claim status request: Covisint Standard Interface ANSI ASI X12N 276 Claim Status Request Ref LOOP ID SEG ID REQ/OPT ELEMENT ID ELEMENT DESCRIPTION 1 ISA Segment (Interchange Control Header) - Required 2 ISA01 Req Authorization Information Qualifier X12 Req Data Type Min/Max Denotes no Authorization Information present M ID 2/2 "00" 3 ISA02 Req e02-authorization Information 10 spaces M AN 10/10 Spaces 4 ISA03 Req e03-security Information Qualifier Denotes no Security Information present M ID 2/2 "00" 5 ISA04 Req e04-security Information 10 spaces M AN 10/10 Spaces 6 ISA05 Req e05-interchange ID Qualifier Mutually Defined M ID 2/2 "ZZ" EXPECTED VALUE 7 ISA06 Req e06-interchange Sender ID Determined by Sender M AN 15/15 Per trading partner agreement 8 ISA07 Req e07-interchange ID Qualifier Mutually Defined M ID 2/2 Per trading partner agreement 9 ISA08 Req e08-interchange Receiver ID Determined by Receiver M AN 15/15 Per trading partner agreement 10 ISA09 Req e09-interchange Date Date Interchange created M DT 6/6 Format is YYMMDD 11 ISA10 Req e10-interchange Time Time Interchange created M TM 4/4 Format is HHMM 12 ISA11 Req 13 ISA12 Req e11-interchange Control Standards Identifier M ID 1/1 "U" e12-interchange Control Version Number MI ID 5/5 " 00401" 14 ISA13 Req e13-interchange Control Number Determined by Sender M N0 9/9 varies 15 ISA14 Req e14-acknownledgement Request No Acknowledgement Requested M ID 1/1 "0" 16 ISA15 Req e15-usage Indicator M ID 1/1 "P" 17 ISA16 Req e16-component Element Separator Used to delineate sub-elements M 1/1 ">" Page 9
Covisint Standard Interface ANSI ASI X12N 276 Claim Status Request Ref LOOP ID SEG ID REQ/OPT ELEMENT ID ELEMENT DESCRIPTION 18 GS Segment (Functional Group Header) - Required X12 Req Data Type Min/Max EXPECTED VALUE 19 GS01 Req e01-functional Identifier Code Eligibility Inquiry (276) M ID 2/2 "HR" 20 GS02 Req e02-application Senders Code Determined by Sender M AN 2/15 Per trading partner agreement 21 GS03 Req e03-application Receivers Code Determined by Receiver M AN 2/15 Per trading partner agreement 22 GS04 Req e04-date Creation Date M DT 8/8 Format is CCYYMMDD 23 GS05 Req e05-time Creation Time M TM 4/8 Format is HHMM 24 GS06 Req e06-group Control Number M N0 1/9 "1" 25 GS07 Req e07-responsible Agency Code Denotes X12 Standards Committee M ID 1/2 "X" 26 GS08 Req 27 ST Segment (Transaction Set Header) - Required e08-version/release Industry ID Code Denotes X12 Version Number M AN 1/12 "004010X093A1' 28 ST01 Req e01-transaction Set identifier Code M ID 3/3 "276" 29 ST02 Req e02-transaction Set Control Number M AN 4/9 "0001" 30 BHT Segment (Beginning of Hierarchical Transactions) - Required 31 BHT01 Req e01-hierarchical Structure Code Information Receiver. M ID 4/4 "0010" 32 BHT02 Req e02-transaction Set Purpose Code Code Identifying the purpose of the transaction. M ID 2/2 "13" 33 BHT03 Not used e03-reference Identification Not Used. O AN 1/30 Transaction set creation date. O DT 8/8 34 BHT04 Req e04-date 35 BHT05 Not used e05-time Transaction set creation time. O TM 4/8 36 BHT06 Not used e06-transaction Type Code Transaction Type Code. O ID 2/2 37 Loop 2000A (information source) Insurer/Payer - Required 38 HL Segment - Hierarchical Level - Required System Date in CCYYMMDD format. Page 10
Covisint Standard Interface ANSI ASI X12N 276 Claim Status Request Ref LOOP ID SEG ID REQ/OPT ELEMENT ID ELEMENT DESCRIPTION 39 HL01 Req e01-hierarchical ID Number X12 Req Data Type Min/Max 40 HL02 Not used e02-hierarchical Parent ID Number Not Used. O AN 1/12 41 HL03 Req e03-hierarchical Level Number 42 HL04 Req e04-hierarchical Child Code 43 Loop 2100A Payer Name - Required 44 NM1 Segment (Payer Name) - Required 45 NM101 Req e01-entity Identifier Code 46 NM102 Req e02-entity Type Qualifier 47 NM103 Req EXPECTED VALUE Assigned by the sender to identify a particular data segment. M AN 1/12 "1" ( increment by 1 for each additional HL loop) Code identifying the characteristic of a level in a hierarchical structure. M ID 1/2 "20" Code indicating whether or not there are subordinate segments. O ID 1/1 "1" Code identifying the source of the eligibility information (payer). M ID 2/3 "PR" Used to indicate source of information is a Non - Person Entity. M ID 1/1 "2" e03-name Last or Organization Name The name of the organization. O AN 1/35 Payer name, per trading partner agreement 48 NM104 Not used e04-name First Not Used. O AN 1/25 49 NM105 Not used e05-name Middle Not Used. O AN 1/25 50 NM106 Not used e06-prefix Not Used. O AN 1/10 51 NM107 Not used e07-name Suffix Not Used. O AN 1/10 52 NM108 Req e08-identification Code Qualifier Id Code Qualifier. X ID 1/2 "PI" 53 NM109 Req e09-identification Code Payer Identifier X AN 2/80 Payer id, per trading partner agreement 54 Loop 2000B (Information Receiver) Medical Service Provider (i.e. physician, hospital, laboratory) - Required 55 HL Segment - Hierarchical Level - Required 56 HL01 Req e01-hierarchical ID Number 57 HL02 Req e02-hierarchical Parent ID Number Assigned by the sender to identify a particular data segment. M AN 1/12 "2" Identifying the number of the next highest hierarchical data segment. O AN 1/12 "1" Page 11
Covisint Standard Interface ANSI ASI X12N 276 Claim Status Request Ref LOOP ID SEG ID REQ/OPT ELEMENT ID ELEMENT DESCRIPTION 58 HL03 Req e03-hierarchical Level Number 59 HL04 Req e04-hierarchical Child Code 60 Loop 2100B Information Receiver Name - Required 61 NM1 Segment (Information Receiver Name) - Required X12 Req Data Type Min/Max Code identifying the characteristic of a level in a hierarchical structure. M ID 1/2 "21" Code indicating whether or not there are subordinate segments. O ID 1/1 "1" EXPECTED VALUE 62 NM101 Req e01-entity Identifier Code 63 NM102 Req e02-entity Type Qualifier 64 NM103 Req e03-name Last or Organization Name Code identifying an organizational entity, a physical location, property or an individual. M ID 2/3 "41" Used to indicate source of information is a Non - Person Entity. M ID 1/1 "1" or "2" Information Receiver Last Name or Organization Name O AN 1/35 65 NM104 Situational e04-name First Information Receiver First Name O AN 1/25 Provider First name 66 NM105 Situational e05-name Middle Not Used. O AN 1/25 67 NM106 Not used e06-prefix Not Used. O AN 1/10 68 NM107 Situational e07-name Suffix Not Used. O AN 1/10 69 NM108 Req e08-identification Code Qualifier Code designating structure. X ID 1/2 "XX" 70 NM109 Req e09-identification Code Receiver's FI id X AN 2/80 Provider's NPI. 71 Loop 2000C Service Provider Level - Required 72 HL Segment - Hierarchical Level - Required 73 HL01 Req e01-hierarchical ID Number 74 HL02 Req e02-hierarchical Parent ID Number 75 HL03 Req e03-hierarchical Level Number Assigned by the sender to identify a particular data segment. M AN 1/12 "3" Identifying the number of the next highest hierarchical data segment. O AN 1/12 "2" Code identifying the characteristic of a level in a hierarchical structure. M ID 1/2 "19" Provider Last or Organization name receiving the information. Page 12
Covisint Standard Interface ANSI ASI X12N 276 Claim Status Request Ref LOOP ID SEG ID REQ/OPT ELEMENT ID ELEMENT DESCRIPTION 76 HL04 Req e04-hierarchical Child Code 77 Loop 2100C Provider Name - Required 78 NM1 Segment - Provider Name - Required X12 Req Data Type Min/Max Code indicating whether or not there are subordinate segments. O ID 1/1 "1" EXPECTED VALUE 79 NM101 Req e01-entity Identifier Code Code identifying an organizational entity, a physical location, property or an individual M ID 2/3 "1P" 80 NM102 Req e02-entity Type Qualifier Code qualifying the type of entity M ID 1/1 "1" or "2" 81 NM103 Req e03-name Last or Organization Name Provider Last or Organization Name O AN 1/35 82 NM104 Situational e04-name First Provider First Name O AN 1/25 83 NM105 Situational e04-name Middle Provider Middle Name O AN 1/25 84 NM106 Situational e06-prefix Not Used. O AN 1/10 85 NM107 Situational e07-name Suffix Not Used. O AN 1/10 86 NM108 Req e08-identification Code Qualifier Identification Code Qualifier X ID 1/2 "XX" 87 NM109 Req e09-identification Code Provider Identifier X AN 2/80 Billing provider's NPI 88 Loop 2000D Subscriber Level 89 HL Segment - Hierarchical Level - Required 90 HL01 Req e01-hierarchical ID Number 91 HL02 Req e02-hierarchical Parent ID Number 92 HL03 Req e03-hierarchical Level Number 93 HL04 Req e04-hierarchical Child Code Assigned by the sender to identify a particular data segment. M AN 1/12 "4" Identifying the number of the next highest hierarchical data segment. O AN 1/12 "3" Code identifying the characteristic of a level in a hierarchical structure. M ID 1/2 "22" Code indicating whether or not there are subordinate segments. O ID 1/1 "0" or "1" Billing provider's Last or Organization Name from the original submitted claim Billing provider's first name from the original submitted claim Billing provider's middle name from the original submitted claim Page 13
Covisint Standard Interface ANSI ASI X12N 276 Claim Status Request Ref LOOP ID SEG ID REQ/OPT ELEMENT ID ELEMENT DESCRIPTION X12 Req Data Type Min/Max EXPECTED VALUE 94 DMG Segment - Subscriber Demographic Information - Situational Segment is required if the subscriber is the patient e01 Date Time Period Format 95 DMG01 Req Qualifier Date expressed X ID 2/3 "D8" 96 DMG02 Req e02- Date Time Period Subscriber birth date Format CCYYMMDD X AN 1/35 Subscriber's date of birth 97 DMG03 Req e03 - Gender Code Subscriber gender code ID AN 1/1 "U" or "F" or "M" 98 Loop 2100D Subscriber Name - Required 99 NM1 Segment - Subscriber Name - Required 100 NM101 Req e01-entity Identifier Code Code identifying the individual. M ID 2/3 "IL"or"QC" 101 NM102 Req e02-entity Type Qualifier Person. M ID 1/1 "1" 102 NM103 Req e03-name Last or Organization Name Last Name. O AN 1/35 Subscriber's Last Name 103 NM104 Situational e04-name First First Name. O AN 1/25 Subscriber's First Name 104 NM105 Situational e04-name Middle Middle Initial. O AN 1/25 Subscriber's Middle Name 105 NM106 Situational e06-prefix Not Used. O AN 1/10 106 NM107 Situational e07-name Suffix Not Used. O AN 1/10 107 NM108 Req e08-identification Code Qualifier Qualifier X ID 1/2 "MI" 108 NM109 Req e09-identification Code Insured Primary Id X AN 2/80 Subscriber's Member Id 109 Loop 2200D Claim Submitter Trace Number - Situational Loop is present only if the subscriber is the patient 110 TRN Segment - Claim Submitter Trace Number - Situational Segment is required if the loop is present. 111 TRN01 Req e01-trace Type Code Current Transaction Trace Number M ID 1/2 "1" 112 TRN02 Req e02-reference Id Trace Number M AN 1/30 Unique identifier assigned by Covisint 113 REF Segment - Payer Claim Identification Number - Situational Segment is provided if claim number is available 114 REF01 Req e01 - Reference Id Qualifier Payer s Claim Number M ID 2/3 "1K" 115 REF02 Req e02 - Reference Id Claim Number X AN 1/30 Payer Claim Number Page 14
Covisint Standard Interface ANSI ASI X12N 276 Claim Status Request Ref LOOP ID SEG ID REQ/OPT ELEMENT ID ELEMENT DESCRIPTION 116 AMT Segment - Claim Submitted Charges - Situational X12 Req Data Type Min/Max 117 AMT01 Req e01 - Amount Qualifier Code Code to qualify amount M ID 1/3 "T3" EXPECTED VALUE This segment will be provided since loop 2210D is not used. 118 AMT02 Req e02- Monetary Amount Billed amount M R 1/18 "0" or Amount Billed on claim 119 DPT Segment Claim Service Date - Situational 120 DPT01 Req e-01 Date/Time Qualifier claim statement period M ID 3/3 "232" 121 DPT02 Req e02 - Date Time Period Format Qualifier Range of Dates. CCYYMMDD - CCYYMMDD M ID 2/3 "RD8" This segment will be provided since loop 2210D is not used. 122 DPT03 Req e03 - Date Time Period Format CCYYMMDD - CCYYMMDD M AN 1/35 Start Date '-' End Date of Service Loop is present only if the subscriber is NOT the 123 Loop 2000E - Dependent Level - Situational patient 124 HL Hierarchical Segment - Required 125 HL01 Req e01-hierarchical ID Number 126 HL02 Req e02-hierarchical Parent ID Number 127 HL03 Req e03-hierarchical Level Number 128 HL04 Not used e04-hierarchical Child Code 129 DMG Segment - Dependent Demographic Information - Required Assigned by the sender to identify a particular data segment. M AN 1/12 "5" Identifying the number of the next highest hierarchical data segment. O AN 1/12 "4" Code identifying the characteristic of a level in a hierarchical structure. M ID 1/2 "23" Code indicating whether or not there are subordinate segments. O ID 1/1 Not Mapped. 130 DMG01 Req e01-date Format CCYYMMDD X ID 2/3 "D8" 131 DMG02 Req e02-date Time Period Dependent Date of Birth Format CCYYMMDD X AN 1/35 Patient Date of Birth 132 DMG03 Req e03-gender Code Gender O ID 1/1 "U" or "F" or "M" 133 Loop 2100E Dependent Name - Required 134 NM1 Segment - Dependent Name - Required Page 15
Covisint Standard Interface ANSI ASI X12N 276 Claim Status Request Ref LOOP ID SEG ID REQ/OPT ELEMENT ID ELEMENT DESCRIPTION X12 Req Data Type Min/Max 135 NM101 Req e01-entity Identifier Code Code identifying the individual. M ID 2/3 "QC" 136 NM102 Req e02-entity Type Qualifier Person. M ID 1/1 "1" 137 NM103 Req e03-name Last or Organization Name Last Name. O AN 1/35 Patient Last Name 138 NM104 Situational e04-name First First Name. O AN 1/25 Patient First Name 139 NM105 Situational e05-name Middle Middle Initial. O AN 1/25 Patient Middle Name EXPECTED VALUE 140 NM106 Situational e06-prefix Not Used. O AN 1/10 141 NM107 Situational e07-name Suffix Not Used. O AN 1/10 142 NM108 Situational e08-identification Code Qualifier Not Used. X ID 1/2 143 NM109 Situational e09-identification Code Not Used. X AN 2/80 144 Loop 2200E - Claim Submitter Trace Number - Required 145 TRN Segment - Claim Submitter Trace Number - Required 146 TRN01 Req e01-trace Type Code Current Transaction Trace Number M ID 1/2 "1" 147 TRN02 Req e02-reference Id Trace Number M AN 1/30 Unique identifier 148 REF Segment - Payer Claim Identification Number - Situational Segment is provided if claim number is available 149 REF01 Req e01 - Reference Id Qualifier Payer s Claim Number M ID 2/3 "1K" 150 REF02 Req e02 - Reference Id Claim Number X AN 1/30 Payer Claim Number 151 AMT Segment - Claim Submitted Charges - Situational 152 AMT01 Req e01 - Amount Qualifier Code Code to qualify amount M ID 1/3 "T3" This segment will be provided since loop 2210E is not used. 153 AMT02 Req e02- Monetary Amount Billed amount M R 1/18 "0" or Amount Billed on claim 154 DPT Segment - Claim Service Date (Situational) This segment will be provided since loop 2210E is not used. Page 16
Covisint Standard Interface ANSI ASI X12N 276 Claim Status Request Ref LOOP ID SEG ID REQ/OPT ELEMENT ID ELEMENT DESCRIPTION X12 Req Data Type Min/Max 155 DPT01 Req e-01 Date/Time Qualifier claim statement period M ID 3/3 "232" 156 DPT02 Req e02 - Date Time Period Format Qualifier Range of Dates. CCYYMMDD - CCYYMMDD M ID 2/3 "RD8" EXPECTED VALUE 157 DPT03 Req e03 - Date Time Period Format CCYYMMDD M AN 1/35 Start Date '-' End Date of Service 158 SE Segment - Transaction Set Trailer 159 SE01 Req e01-loop Identifier Code Transaction segment count. Segment count. 160 SE02 Req e02-transaction Set Control Number Must match ST02. 161 GE Segment - Group Set Trailer 162 GE01 Req e01-number of Transaction Sets Included Transaction set count. "1" 163 GE02 Req e02-group Control Number Must match GS06. 164 IEA Segment - Interchange Control Trailer 165 IEA01 Req 166 IEA02 Req e02-interchange Control Number e01-number of included functional groups Count of the functional groups. "1" Control number assigned by the interchange sender. Unique Control Number matches ST e02-transaction Set Control Number Unique Control Number matches GS e06-group Control Number Unique Control Number matches ISA e13-interchange Control Number 4.2 ANSI ASC X12N 277 Health Care Claim Status Response Transaction In response to a claim status request, a claim status response is generated by the Service Provider (payer/clearing house). Key to processing this transaction is that the sender/receiver code and control/trace numbers are matched to the original 276 transaction. It is the responsibility of the sender to send a HIPAA compliant transaction. Please refer to Technical Assumptions in this document for more detail. Page 17
5. ERROR HANDLING This error handling section describes the types of errors that can occur and the expected processing by Covisint and Service Providers (i.e. payers). This discussion outlines the most common types of errors and is not necessarily inclusive of every error that may be encountered during processing. This section is not intended to address error reporting, resolution, escalation or any other service from an operations perspective since each client and/or service provider (payer) establishes these processes or SLAs as part of their contractual agreement with Covisint. Note also, Covisint does not perform HIPAA compliance checking of the 277 transactions. Errors between Covisint and a service provider (payer) using the interface described in this Implementation Guide may fall into these areas: Synchronous Interface Service Provider fails to respond: If a Service Provider (payer) fails to respond to the synchronous request within the configured time limit, then an exception will be returned by Covisint to the end user indicating the Service Provider (payer) failed to respond. The Covisint Help Desk will apply standard support processes as mutually agreed between Covisint and the payer The amount of time that the request will wait for a response is determined by Covisint and is the same value for all payers, to ensure a consistent user experience. Transport level exception returned by Service Provider (payer) If a Service Provider (payer) returns a transport level error, (e.g. HTTPs 500) then an exception will be returned by Covisint to the end user. The Covisint Help Desk will apply standard support processes as mutually agreed between Covisint and the payer. TA1 or 997 returned by Service Provider (payer) If a Service Provider (payer) returns a TA1 or 997, then an exception will be returned by Covisint to the end user. The Covisint Help Desk will apply standard support processes as mutually agreed between Covisint and the payer. Non-compliant 277 returned by Service Provider (payer) Covisint does not perform HIPAA compliance checking on the 277 transaction. Provided the 277 response is a syntactically correct X12 transaction, Covisint will attempt to parse the transaction for display to the user Trading Partner (TP) Errors If Covisint cannot determine the sender or receiver of the claim status response, the message will fail for TP not found. The failure will be handled by Covisint s level 1 help desk. Covisint does not produce a TA1 for TP not found errors. Other Internal Processing Errors If Covisint processing determines that the 277 response is not syntactically correct or otherwise undeliverable, then Covisint may send a 997 (syntax) or TA1 (enveloping) Page 18
message asynchronously to the Service Provider (payer), according to the agreement between Covisint and the Service Provider. Asynchronous Interface Service Provider fails to respond: Covisint does not impose a time limit for receiving an asynchronous response from the Service Provider. The request will remain in a waiting state until the payer responds. Transport level exception returned by Service Provider If a Service Provider returns a transport level error, the Covisint Help Desk will apply standard support processes as mutually agreed. An exception will be returned by Covisint to the end user. TA1 or 997 returned by Service Provider If a Service Provider (payer) returns a TA1 or 997, the Covisint Help Desk will apply standard support processes as mutually agreed. An exception will be returned by Covisint to the end user. Non-compliant 277 returned by Service Provider Covisint does not perform HIPAA compliance checking on the 277 transaction. Provided the 277 response is a syntactically correct X12 transaction, Covisint will attempt to parse the transaction for display to the user. Trading Partner (TP) Errors If Covisint cannot determine the sender or receiver of the claim status response, the message will fail for TP not found. The failure will be handled by Covisint s level 1 help desk. Covisint does not produce a TA1 for TP not found errors. Other Internal Processing Errors If Covisint processing determines that the 277 response is not syntactically correct or is otherwise undeliverable, then Covisint may send a 997 (syntax) or TA1 (enveloping) message asynchronously to the Service Provider (payer), according to the agreement between Covisint and the Service Provider. In all cases, the Service Level Agreement (SLA) between Covisint and the Service Provider will determine any operational processes for responding to errors. Responses may range from no action taken, to immediate escalation for resolution. Contact your Covisint representative for information on the available options. Page 19
6. OTHER REQUIREMENTS Accuracy & Completeness When processing transaction from a Service Provider, Covisint does not inspect and/or translate any incoming data. Content is displayed as provided and should comply with specifications contained in this specification. If there are issues with data displayed, display formats and/or associated codes, it is the responsibility of the Service Provider to address these content issues. If a Service Provider should need custom mapping, this functionality is available but is not considered part of the standard implementation activities Audit Covisint only audits that transactions happened within the Covisint environment; it does not log the content of those transactions. If a data source has other business requirements to log and audit the content of transactional flow, the data source must provide that capability. Data Retention Claim status responses are retained for a configurable time period to allow the end user to review responses as needed within their normal office work flows. Each provider organization can choose how long its claim status responses are available for viewing. Page 20
Appendix A: Claim Status Portlet User Interface 1. Claim Status Request Portlet Using the Requests portlet (depicted below), a user can search for a patient and can select one or more payers for that patient to add to the list to submit for a claim status request. The workflow for submitting claim status request(s) is as follows: The user enters Patient Information and Payer Information. The user can submit the data at that time or using the add to list function the user is able to create a list of patient and payers claims to check. The list can contain claim status requests for a single patient or for multiple patients. The submit button can be used to submit a single entry without adding it to a list, or to submit the entire list at once. Lists of claim status requests will result in multiple real-time requests, each containing a single inquiry for one claim status. Submitting request(s) automatically toggles the user to the Responses view. Page 21
2. Claim Status Responses Portlet In response to claim status requests are the responses received from various payers. These responses can be viewed in the Responses portlet designed to review and manage the status and responses of claim status requests. Depicted below the responses are able to be viewed in a single consolidated list. The Responses view provides 3 major sections: search for specific response, a summary section of responses, and a drill down into specific responses for a patient. Page 22
The search section may be collapsed when not in use. The Summary section shows high-level information about recent responses and provides the ability to print the information for a specific date range. The status information indicates if the request completed successfully (C), is still waiting for a response (W), or error-ed out (E). Details section shows the specific claim status information or error information pertinent to each payer s 277 response for the patient. Page 23
Appendix B: ANSI ASC X12N 276 Health Care Claim Status Request Example ISA*00* *00* *ZZ*COVISINT_HIE *ZZ*382715520 *091217*1234*U*00401*000000037*0*P* ~ GS*HR*COVISINT_HIER*382715520*20091217*1234*37*X*004010X093A1~ ST*276*0001~ BHT*0010*13**20091217~ HL*1**20*1~ NM1*PR*2*PRIORITY HEALTH*****PI*382715520~ HL*2*1*21*1~ NM1*41*1*JOHNSON*JAMES****XX*1578515110~ HL*3*2*19*1~ NM1*1P*1*JOHNSON*JAMES****XX*1578515110~ HL*4*3*22*1~ DMG*D8*19771217*M~ NM1*QC*1*DUNWALD*EVAN****MI*765432~ TRN*1*B315000151~ REF*1K*YTUI005~ AMT*T3*500.16~ DTP*232*RD8*19961007-19961007~ SE*16*0001~ GE*1*37~ IEA*1*000000037 Page 24
Appendix C: ANSI ASC X12N 277 Health Care Claim Status Response Example ISA*00* *00* *ZZ*382715520 *ZZ*COVISINT_HIE *050623*1559*U*00401*000000005*0*P*>~ GS*HN*QAPAY1*QAPRV1*20050623*1559290*66667*X*004010X093A1~ ST*277*000066667~ BHT*0010*08*EX3*20090413**DG~ HL*1**20*1~ NM1*PR*2*PRIORITY HEALTH*****AD*382715520~ HL*2*1*21*1~ NM1*41*2*PLAN*****FI*382069753~ HL*3*2*19*0~ NM1*1P*2*JOHNSON*JAMES****SV*1578515110~ HL*4*3*22*0~ DMG*D8*19490331*U~ NM1*QC*1*DUNWALD*EVAN****MI*765432~ TRN*2*B315000151~ STC*P2>4>1P*20090415**12.10*9.10*20090501*ACH*20090425*44444~ DTP*232*RD8*20090315-20090316~ TRN*2*B315000151~ STC*A3>0*20090415**0*0~ DTP*232*RD8*20090315-20090316~ TRN*2*B315000151~ STC*P2>4>1P*20090415**12*12*20090501*ACH*20090425*44444*~ DTP*232*RD8*20090315-20090316~ SVC*AD>123456*0*0~ STC*P2>4>4R*20090415**10.98*19.18*20090501*ACH*20090425*44444*~ TRN*2*B315000151~ STC*A3>0*20090411**20*22~ DTP*232*RD8*20090315-20090316~ SVC*AD>123456*3*4~ STC*P2>4>99*20090412**0*0*20090505*ACH*20090426*44444*~ TRN*2*B315000151~ STC*A3>0*20090415**10*20~ DTP*232*RD8*20090310-20090311~ SVC*AD>123456*3.99*4.99~ STC*P2>4>13*20090413**10*10*20090501*ACH*20090425*44444*~ DTP*472*RD8*20090210-20090211~ SE*34*000066667~ GE*1*66667~ IEA*1*000000005~ Page 25