User Manual. HIPAA Transactions System Integration for Channel Partner Vendor. Version 15.2 May 2015

Transcription

1 User Manual HIPAA Transactions System Integration for Channel Partner Vendor Version 15.2 May 2015

2 Trademarks and Copyrights Optum HIPAA Transactions System Integration Document Channel Partner Vendor User Manual Published May This document is protected by copyright law and international treaties. Unauthorized reproduction or distribution of this document, or any portion of it, may result in severe civil and criminal penalties, and will be prosecuted to the maximum extent possible under the law. Copyright 2015 Optum. All rights reserved. Optum, Inc Technology Drive Eden Prairie, MN

3 Contents Integration overview 4 Implementation process 6 HIPAA code lists 7 HTTPS file transfer specifications 8 ANSI 837P X222A1 format 11 ANSI 837I X223A2 format 12 ANSI TA1/277CA responses 13 Optum/payer text reports RSE XML integration 14 HTTP-MIME file submission specifications for real-time transactions 15 Webservice interface for real-time transactions 17 ANSI 270/271 Eligibility Benefit Inquiry and Response 19 ANSI 276/277 Claim Status Request and Response 22 ANSI 278 Referrals and Authorizations 24 ANSI 835 Electronic Remittance Advice 26 Troubleshooting 29 Version Change Log 30 Appendix A: Advanced clinical editing users 31 Advanced clinical editing 31 ANSI method 31 ANSI (non-advanced clinical editing) 31 Editing only (advanced clinical editing) 32 Editing with routing (advanced clinical editing) 32 Notes about historical editing and duplicate claims: 33 Appendix B: RSE XML integration 34 Client request schema 34 Client response schema 39 XML load-id requests (Step 1: Get the load IDs) 45 Report load query (last_days, read_flag) 45 XML claim load requests (Step 2: Get the data) 47 Claim load query (load_id) 47

4 Integration overview Optum uses HTTPS file transfers for the exchange of health care transactions between Optum and their trading partners. This requires that the trading partner post a request to a designated URL address and receive an immediate response to the request. For real-time transactions, there also is a CAQH webservice interface available. This document provides examples to guide software developers on how to integrate Optum transaction processing capabilities within an existing application. The following diagram illustrates the available transactions and the potential responses from each type of request Optum, Inc. 4

5 Integration overview HIPAA Transactions System Integration for Channel Partner- Vendor 15.2 User Manual 2015 Optum, Inc. 5

6 Implementation process This is the required process for each of the ASC X12 transaction requests to be submitted. This process does not apply to the 835 transaction set. For 835 transactions, see the ANSI 835 Electronic Remittance Advice section. To implement to Optum via HTTPS: 1. Complete and sign the contract for the designated Optum services. When the contract is processed you will receive your username, password, and organization ID. 2. Review the HIPAA Transactions System Integration Documentation. Once you can create a valid ASC X12 file (837P, 837I, 270, 276 or 278) and are ready to start testing contact Optum at: VendorTestFile@optum.com. 3. While the ASC X12 transaction is being tested you may test your HTTPS communication process. It is important that the transaction indicate Test. To send a test transaction you must have the USAGE set as TEST in the HTTPS request body and the ISA15 segment should have a T for Test. 837P and 837I transactions identified appropriately as Test will not be forwarded to payers. 4. Once your transactions have been validated and you are able to make a successful HTTPS request and you and your clients are prepared to move into production status, change the usage to PRODUCTION in the HTTPS request body and the ISA15 segment to P for Production Optum, Inc. 6

7 HIPAA code lists This is the required process for each of the ASC X12 transaction requests to be submitted. This process does not apply to the 835 transaction set. For 835 transactions, see the ANSI 835 Electronic Remittance Advice section. Code lists for the following can be found on the WPC website at: Provider Taxonomy Codes Claims Adjustment Reason Codes Claim Status Codes Claim Status Category Codes Health Care Services Decision Reason Codes Health Care Service Type Codes Remittance Advice Remark Codes Insurance Business Process Application Error Codes 2015 Optum, Inc. 7

8 HTTPS file transfer specifications Optum s HTTPS server is available to receive requests at: Adapter Optum expects the HTTPS request body to follow a strict but simple format. There are two portions of the HTTPS request: the header and the body. The header consists of a number of parameters or name-value pairs each on its own line. The parameters may be specified in any order, but they must all exist. Note that the actual values of the parameters will depend upon the type of transaction being submitted. It is not necessary that the Body Length parameter be accurate. The header must be followed by one (1) blank line and then the payload body. See the following example Optum, Inc. 8

9 HTTPS file transfer specifications HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual After executing a POST to the above URL, a 277CA response will be returned. Following is a sample HTTPS response. In the HTTPS response you will note there is no status populated. The status field populates only if there is an HTTPS error or a 999 is being returned because of invalid data Optum, Inc. 9

10 HTTPS file transfer specifications HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual Like the request, there is a series of name-value pairs, each on its own line, followed by a blank line and then the body of the response Optum, Inc. 10

11 ANSI 837P X222A1 format Optum currently accepts errata version X222A1. Please review the Optum Payers List for the required Payer ID when submitting claims. This can be found at: Specifications for the 837P X12 transaction can be found at: Optum, Inc. 11

12 ANSI 837I X223A2 format Optum currently accepts errata version X223A2. Please review the Optum Payers List for the required Payer ID when submitting claims. This can be found at: Specifications for the 837I X12 transaction can be found at: Optum, Inc. 12

13 ANSI TA1/277CA responses In the event the 837P or 837I file fails for a syntactical interchange validation Optum will return a TA1 response and the entire claim file will reject. All other files will be validated using the Optum HIPAA validations and will result in a 277CA response. In the event you do not receive a TA1 or 277CA response, it is possible that the X12 837P or 837I file is not able to be parsed. Please review the structural accuracy of the file. After review, if the file appears to be structurally accurate, contact Optum at VendorTestFile@optum.com and an Optum Business Analyst will respond. Specifications for the 277CA transaction can be found at: Optum, Inc. 13

14 Optum/payer text reports RSE XML integration Claim text reports will be available once your organization begins submitting production claims but will not be available for test file submissions. As a claim goes through its EDI lifecycle, reporting will be added and made available for retrieval. The initial report will be available within the first two hours after submission. Note: If your organization has opted in for Level 1 reports, that report will be the first response report available. Additional reporting will include feedback based on Optum validations and Optum payer validations. Optum s HTTPS server is available to receive requests at: Adapter In the Optum database, claim reports are loaded at certain times during the day. Each load is assigned a unique load-id. The process of retrieving reports via the XML request/response should include the following steps. 1. Find the load-ids by using the Report Load Query. This will return your load-ids for the last 30 days (as an example) that are unread. Note that at the present time, all load-ids for the last 30 days will show as unread. Load Types returned from this request may include: Level One LEVEL2-ENS CLAIM ACK REPORT Summary Claim Status/Ack Reports Announcement 2. Keep the unread load-ids in your system and, one at a time, request the information contained under each load-id using the Claim Load Query. Once the report content has been received, the load-id can be shown as read on your side, and the next load-id data can be requested. Refer to Appendix B RSE XML integration for schema definitions and XML request/response examples Optum, Inc. 14

15 HTTP-MIME file submission specifications for realtime transactions This transaction was designed to be CORE compliant which requires more information due to the CORE envelope. Optum s HTTPS server is available to receive HTTP-MIME requests at: dapter 2015 Optum, Inc. 15

16 HTTP-MIME file submission specifications for real-time transactions HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual 2015 Optum, Inc. 16

17 Webservice interface for real-time transactions This transaction was designed to be CORE compliant which requires more information due to the CORE envelope. Optum s Webservice interface is available to receive requests at: The CORE WSDL being used by Optum, can be obtained at: Following is an example of a SOAP message that could be submitted to Optum: Following is an example of a Webservice response from Optum: 2015 Optum, Inc. 17

18 Webservice interface for real-time transactions HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual 2015 Optum, Inc. 18

19 ANSI 270/271 Eligibility Benefit Inquiry and Response Optum accepts version X092A1 and 5010 version X279A1. When submitting the 270 Eligibility Benefit Inquiry and Response, you will need to consult the Optum Eligibility Payers List for the required payer ID. This can be found at: Specifications for the 270/271 transactions can be found at: Following is a sample 270 request. Following is a sample 271 response Optum, Inc. 19

20 ANSI 270/271 Eligibility Benefit Inquiry and Response HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual Optum performs minimal HIPAA X12 validation on the 270 request transaction prior to submission into the payer s system for processing. It is possible that the payer will respond with a TA1 or 999 in the event the request transaction fails the payer s validation. Consult the Optum Companion Guide for payer-specific information at Following is a sample TA1. Following is a sample Optum, Inc. 20

21 ANSI 270/271 Eligibility Benefit Inquiry and Response HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual 2015 Optum, Inc. 21

22 ANSI 276/277 Claim Status Request and Response Optum accepts version X093A1 and version X212. When submitting a 276 Claim Status Request and Response you will need to consult the Optum Claim Status Payers List for the required payer ID. This can be found at: Specifications for the 276/277 transactions can be found at: Following is a sample 276 request. Following is a sample 277 response Optum, Inc. 22

23 ANSI 276/277 Claim Status Request and Response HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual Optum performs minimal HIPAA X12 validation on the 276 request transaction prior to submission into the payer s system for processing. It is possible that the payer will respond with a TA1 or 999 in the event the request transaction fails the payer s validation. Consult the Optum Companion Guide for payer-specific information at Following is a sample TA1. Following is a sample Optum, Inc. 23

24 ANSI 278 Referrals and Authorizations Optum accepts version X217. When submitting the 278 Referral and Authorization transactions you will need to consult the Optum Referrals/Authorizations Payers List for the payer ID required. You can find this at: Specifications for the 278 transaction can be found at: Following is a sample 278 request. Following is a sample 278 response Optum, Inc. 24

25 ANSI 278 Referrals and Authorizations HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual 2015 Optum, Inc. 25

26 ANSI 835 Electronic Remittance Advice This section outlines how to implement the 835. To implement the 835: 1. Sign the contract to receive 835 transactions. 2. Identify which payers you wish to receive the 835 transaction from. The available payers can be found on the Optum website: 3. If the payer requires enrollment, locate the forms at the ERA Manager portal on the Optum website: 4. Complete the enrollment process as specified by the payer. Once Optum starts receiving files from the payer with your provider information, files will be posted. Optum s HTTPS server is available to receive requests at: Adapter This is the code you will use to request the ERA from Optum through HTTPS. You will need to insert the appropriate username, password, and organization ID; these values are unique for each client. Following is a sample 835 request Optum, Inc. 26

27 ANSI 835 Electronic Remittance Advice HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual Following is a sample 835 response Optum, Inc. 27

28 ANSI 835 Electronic Remittance Advice HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual 2015 Optum, Inc. 28

29 Troubleshooting If you are sending 837P transactions and are getting the 277CA back but are not getting any text reports, verify that the HTTPS Usage and the ISA segment are set to production and not to test. With the 837P you should receive a TA1, 999 or 277CA immediately. If you do not, please contact Optum. If you send an 837P transaction that is marked test, you will get a 277CA back but the claims will not be saved or processed through to the payer Optum, Inc. 29

30 Version Change Log Version Release Date Changes 4.3 April 13, 2015 Review and update of overall document 4.2 February 2, 2012 Update for inclusion of ANSI version September 15, 2011 Name Change from Ingenix to OptumInsight 4.0 June 15, 2011 Update of Advanced Clinical Editing information 3.9 January 13, 2011 Update of Advanced Clinical Editing information 3.8 December 10, 2011 Add the CORE specific interface information 3.7 November 22, 2010 Update of Advanced Clinical Editing information 3.6 August 9, 2010 Inclusion of Advanced Clinical Editing information (Appendix A) 3.5 November 16, 2009 Inclusion of 837I transmission 3.4 September 9, 2009 Name Change from ENS to OptumInsight 3.3 August 1, 2009 Corrected documentation of testing procedures 2015 Optum, Inc. 30

31 Appendix A: Advanced clinical editing users Advanced clinical editing Advanced Clinical Editing is an add-on service to our existing claims submission platform. Advanced Clinical Editing provides claim editing ability beyond what is typically offered. Advanced Clinical Editing provides a front-end edit and review capability that enables you to pre-screen your claims for billing and coding errors and avoids the delays associated with incorrect coding. As Advanced Clinical Editing is an add-on service, you must first contract with Optum for the use of this service. Once you have contracted for the service, you will be provided training materials and the method for sending your 837P claims through the Advanced Clinical Editing service. For Advanced Clinical Editing (ACE), Optum offers an ANSI method that requires that you submit X12 and receive back a 277CA. Depending on the Message Format used, the user can either have claims edited by ACE and have clean claims sent on to the payers or bypass ACE or have the claims edited for HIPAA and ACE compliance. One of the benefits of Advanced Clinical Editing is you are able to send your claims using the same URL mentioned earlier in this document regardless of submission method. Adapter ANSI method Optum can route your claims based on the Message Format and Message Type you include in the Header of your transmission. The message format for non-advanced Clinical Editing submissions is: X12 The message format for ANSI Advanced Clinical Editing submissions is: ACE X12 The message type should be one of the following: ANSI (non-advanced clinical editing) This is the message type you are currently using. When you want to bypass all Advanced Clinical Editing edits, send your claims with the ANSI message type. The Optum system validations only will be returned. Note that you are not allowed to bypass the Optum system validations. Sample Header Request: Version: 0.2 Username: Username 2015 Optum, Inc. 31

32 Appendix A: Advanced clinical editing users HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual Password: Password Organization: Organization ID Message Format: X12 Message Type: ANSI Usage: PRODUCTION Body Length: 1174 Editing only (advanced clinical editing) This message type will allow you to check or recheck your claims without routing them to the payers. The EDITING ONLY message type will send your claims through the normal Optum system validations and Advanced Clinical Editing edits and those claims will not be routed to their respective payers. You will receive the normal Optum system validations along with any Advanced Clinical Editing edits via your 277CA. Sample Header Request: Version: 0.2 Username: Username Password: Password Organization: Organization ID Message Format: ACE X12 Message Type: EDITING ONLY Usage: PRODUCTION Body Length: 1174 Editing with routing (advanced clinical editing) This message type will allow you to send your claims through the normal Optum system validations and the Advanced Clinical Editing edits. All clean claims will be routed on to the payers. Any claims that have Optum system validations or Advanced Clinical Editing edits will not go on to the payer. The validation and/or edits will be provided back to you via your 277CA. Sample Header Request: Version: 0.2 Username: Username Password: Password Organization: Organization ID Message Format: ACE X12 Message Type: EDITING WITH ROUTING Usage: PRODUCTION Body Length: Optum, Inc. 32

33 Appendix A: Advanced clinical editing users HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual Notes about historical editing and duplicate claims: Advanced Clinical Editing provides the ability to edit claims based on claims already in the system. When you begin to send claims to Advanced Clinical Editing, they are stored so that they can be used later for the purposes of ensuring a duplicate claim is not sent as well as duplicate procedures are not billed. For instance, a claim for a yearly physical can be submitted and a few days later, the same claim is submitted. Advanced Clinical Editing will provide an edit stating the claim is a duplicate. Another example; a claim for a yearly physical can be submitted and months later (within the same calendar year), another claim is submitted for the same patient for a yearly physical. Advanced Clinical Editing will provide an edit stating the procedure should not be billed as the patient has already had their yearly physical. Due to this capability, it is important that new claims submitted have a unique Claim ID sent in the REF*D9. If a corrected claim is re-submitted, the same Claim ID must be used. If these suggestions are not followed, the user will experience one or more of the following: duplicate claim edits or overwriting of the most current version of the previous claim Optum, Inc. 33

34 Appendix B: RSE XML integration The XSD files included in this section define what the XML messages into and out of Optum are allowed to look like. The files contain checks in place to ensure that the messages coming into and going out of Optum conform to the schemas. Client request schema <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" <xs:element name="request"> <xs:annotation> <xs:documentation>root element for requests</xs:documentation> </xs:annotation> <xs:complextype> <xs:sequence> <xs:element ref="transaction-set" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="transaction-set"> <xs:complextype> <xs:choice> <xs:element ref="report-load"> <xs:annotation> <xs:documentation>used to query for report loads</xs:documentation> </xs:annotation> </xs:element> 2015 Optum, Inc. 34

35 Appendix B: RSE XML integration HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual <xs:element ref="claim-load"> <xs:annotation> <xs:documentation>used when querying for claim loads</xs:documentation> </xs:annotation> </xs:element> </xs:choice> <xs:attribute name="type" use="required"> <xs:simpletype> <xs:restriction base="xs:nmtoken"> <xs:enumeration value="report-load-query" /> <xs:enumeration value="claim-report-query" /> </xs:restriction> </xs:simpletype> </xs:attribute> </xs:complextype> </xs:element> <xs:element name="report-load"> <xs:complextype> <xs:sequence> <xs:element name="criteria" type="report-criteria" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="claim-load"> <xs:complextype> <xs:sequence> 2015 Optum, Inc. 35

36 Appendix B: RSE XML integration HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual <xs:element name="criteria" type="claim-criteria" /> </xs:sequence> </xs:complextype> </xs:element> <xs:complextype name="claim-criteria"> <xs:choice> <xs:element maxoccurs="unbounded" name="load-id" type="xs:long" /> <xs:element name="claim-details" type="claim-details-criteria" /> <xs:element name="summary-details" type="summary-details-criteria" /> </xs:choice> </xs:complextype> <xs:complextype name="report-criteria"> <xs:sequence> <xs:choice> <xs:element name="date" type="load-date"> <xs:annotation> <xs:documentation>date range to load for</xs:documentation> </xs:annotation> </xs:element> <xs:element name="load-id" type="xs:long" /> </xs:choice> <xs:element minoccurs="0" name="read" type="xs:boolean" /> </xs:sequence> </xs:complextype> <xs:complextype name="claim-details-criteria"> <xs:choice> 2015 Optum, Inc. 36

37 Appendix B: RSE XML integration HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual <xs:element maxoccurs="unbounded" name="claim-object-id" type="xs:string" /> <xs:sequence> <xs:element minoccurs="0" name="date" type="load-date"> <xs:annotation> <xs:documentation>optional date information for bounding results</xs:documentation> </xs:annotation> </xs:element> <xs:element minoccurs="0" name="ect-number" type="xs:string" /> <xs:element minoccurs="0" name="service-end-date" type="xs:date" /> <xs:element minoccurs="0" name="insured-id" type="xs:string" /> <xs:element minoccurs="0" name="service-start-date" type="xs:date" /> <xs:element minoccurs="0" name="patient-last-name" type="xs:string" /> <xs:element minoccurs="0" name="patient-first-name" type="xs:string" /> <xs:element minoccurs="0" name="patient-account" type="xs:string" /> </xs:sequence> </xs:choice> </xs:complextype> <xs:complextype name="summary-details-criteria"> <xs:choice> <xs:element maxoccurs="unbounded" name="summary-id" type="xs:string" /> <xs:choice> <xs:sequence> <xs:element name="date" type="load-date"> 2015 Optum, Inc. 37

38 Appendix B: RSE XML integration HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual <xs:annotation> <xs:documentation>optional date information for bounding results</xs:documentation> </xs:annotation> </xs:element> <xs:element minoccurs="0" name="report-name" type="xs:string" /> </xs:sequence> <xs:element name="report-name" type="xs:string" /> </xs:choice> </xs:choice> </xs:complextype> <xs:complextype name="load-date"> <xs:choice> <xs:element name="last-days"> <xs:simpletype> <xs:restriction base="xs:nmtoken"> <xs:enumeration value="30" /> <xs:enumeration value="60" /> <xs:enumeration value="0" /> <xs:enumeration value="90" /> </xs:restriction> </xs:simpletype> </xs:element> <xs:choice> <xs:sequence> <xs:element name="start-date" type="xs:date" /> <xs:element minoccurs="0" name="end-date" type="xs:date" /> 2015 Optum, Inc. 38

39 Appendix B: RSE XML integration HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual </xs:sequence> <xs:element name="end-date" type="xs:date" /> </xs:choice> </xs:choice> </xs:complextype> </xs:schema> Client response schema <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" <xs:element name="response"> <xs:annotation> <xs:documentation>root element for results</xs:documentation> </xs:annotation> <xs:complextype> <xs:choice> <xs:element ref="transaction-set" /> </xs:choice> </xs:complextype> </xs:element> <xs:element name="transaction-set"> <xs:complextype> <xs:choice> <xs:element ref="report-load" /> <xs:element ref="claim-load" /> </xs:choice> <xs:attribute name="type" use="required"> 2015 Optum, Inc. 39

40 Appendix B: RSE XML integration HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual <xs:simpletype> <xs:restriction base="xs:nmtoken"> <xs:enumeration value="report-load-response" /> <xs:enumeration value="claim-report-response" /> </xs:restriction> </xs:simpletype> </xs:attribute> </xs:complextype> </xs:element> <xs:element name="report-load"> <xs:complextype> <xs:sequence> <xs:element minoccurs="0" maxoccurs="unbounded" name="load" type="report-load-type" /> <xs:element minoccurs="0" ref="errors" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="claim-load"> <xs:complextype> <xs:sequence> <xs:choice> <xs:element minoccurs="0" maxoccurs="unbounded" name="load" type="load-result-type" /> </xs:choice> <xs:element minoccurs="0" ref="errors" /> </xs:sequence> </xs:complextype> 2015 Optum, Inc. 40

41 Appendix B: RSE XML integration HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual </xs:element> <xs:complextype name="report-load-type"> <xs:sequence> <xs:element name="load-id" type="xs:string" /> <xs:element name="load-name" type="xs:string" /> <xs:element name="load-type" type="xs:string" /> <xs:element name="timestamp" type="xs:datetime" /> <xs:element name="organization-id" type="xs:string" /> <xs:element name="read" type="xs:boolean" /> </xs:sequence> </xs:complextype> <xs:complextype name="load-result-type"> <xs:choice> <xs:element name="claim-detail" type="claim-load-type" /> <xs:element name="summary" type="summary-load-type" /> <xs:element name="announcement" type="announcement-load-type" /> <xs:element name="level-one" type="level-one-load-type" /> </xs:choice> </xs:complextype> <xs:complextype name="claim-load-type"> <xs:complexcontent mixed="false"> <xs:extension base="base-load-type"> <xs:sequence> <xs:element name="claim-obj-id" type="xs:string" /> <xs:element name="claim-id" type="xs:string" /> <xs:element name="claim-value" type="xs:string" /> 2015 Optum, Inc. 41

42 Appendix B: RSE XML integration HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual <xs:element minoccurs="0" name="service-start-date" type="xs:date" /> <xs:element minoccurs="0" name="service-end-date" type="xs:date" /> <xs:element name="insured-id" type="xs:string" /> <xs:element name="insured-last-name" type="xs:string" /> <xs:element name="insured-first-name" type="xs:string" /> <xs:element name="patient-last-name" type="xs:string" /> <xs:element name="patient-first-name" type="xs:string" /> <xs:element name="patient-account-number" type="xs:string" /> <xs:element name="ect-number" type="xs:string" /> <xs:element name="trace-number" type="xs:string" /> <xs:element minoccurs="0" maxoccurs="unbounded" name="status" type="xs:string" /> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="summary-load-type"> <xs:complexcontent mixed="false"> <xs:extension base="base-load-type"> <xs:sequence> <xs:element name="summary-id" type="xs:string" /> <xs:element minoccurs="0" name="submitted-count" type="xs:int" /> <xs:element minoccurs="0" name="total-claim-charge" type="xs:string" /> <xs:element minoccurs="0" name="claim-accepted-count" type="xs:int" /> <xs:element minoccurs="0" name="claim-rejected-count" type="xs:int" /> 2015 Optum, Inc. 42

43 Appendix B: RSE XML integration HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual <xs:element minoccurs="0" name="claim-accepted-charges" type="xs:string" /> <xs:element minoccurs="0" name="claim-rejected-charges" type="xs:string" /> <xs:element minoccurs="0" name="claim-accepted-percent" type="xs:string" /> <xs:element minoccurs="0" name="claim-rejected-percent" type="xs:string" /> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="announcement-load-type"> <xs:sequence> <xs:element name="load-id" type="xs:string" /> <xs:element name="creation-date" type="xs:datetime" /> <xs:element name="title" type="xs:string" /> <xs:element name="content" type="xs:string" /> </xs:sequence> </xs:complextype> <xs:complextype name="level-one-load-type"> <xs:sequence> <xs:element name="load-id" type="xs:string" /> <xs:element name="creation-time" type="xs:datetime" /> <xs:element name="organization-id" type="xs:string" /> <xs:element name="provider-tax-id" type="xs:string" /> <xs:element name="claim-count" type="xs:string" /> <xs:element name="claim-value" type="xs:string" /> 2015 Optum, Inc. 43

44 Appendix B: RSE XML integration HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual <xs:element name="system-id" type="xs:string" /> </xs:sequence> </xs:complextype> <xs:complextype name="base-load-type"> <xs:sequence> <xs:element name="load-id" type="xs:string" /> <xs:element name="file-name" type="xs:string" /> <xs:element minoccurs="0" name="report-generated" type="xs:datetime" /> <xs:element name="report-load-timestamp" type="xs:datetime" /> <xs:element minoccurs="0" name="report-processed" type="xs:datetime" /> <xs:element minoccurs="0" name="report-received" type="xs:datetime" /> <xs:element minoccurs="0" name="provider-sub-id" type="xs:string" /> <xs:element minoccurs="0" name="provider-tax-id" type="xs:string" /> <xs:element minoccurs="0" name="provider-first-name" type="xs:string" /> <xs:element minoccurs="0" name="provider-last-name" type="xs:string" /> <xs:element minoccurs="0" name="payer-name" type="xs:string" /> <xs:element name="organization-id" type="xs:string" /> <xs:element name="payer-id" type="xs:string" /> <xs:element name="header1" type="xs:string" /> <xs:element name="header2" type="xs:string" /> <xs:element minoccurs="0" name="header3" type="xs:string" /> </xs:sequence> </xs:complextype> <xs:element name="errors"> 2015 Optum, Inc. 44

45 Appendix B: RSE XML integration HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual <xs:complextype> <xs:sequence> <xs:element maxoccurs="unbounded" ref="error" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="error"> <xs:complextype> <xs:sequence> <xs:element name="code" type="xs:string" /> <xs:element name="message" type="xs:string" /> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> XML load-id requests (Step 1: Get the load IDs) Report load query (last_days, read_flag) Request message <?xml version="1.0" encoding="utf-8"?> <request> <transaction-set type="report-load-query"> <report-load> <criteria> <date> <last-days> </last-days> 2015 Optum, Inc. 45

46 Appendix B: RSE XML integration HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual </date> <read> </read> </criteria> </report-load> </transaction-set> </request Notes/Comments: <last-days> element can only have a value of 0, 30, 60, and 90 value for <read> tag should be either true or false query is valid for the user organization only Response message <?xml version="1.0" encoding="utf-8"?> <response> <transaction-set type="report-load-response"> <report-load> <load> <load-id> </load-id> <load-name> </load-name> <load-type> </load-type> <timestamp> </timestamp> <organization-id> </organization-id> <read> </read> </load> <errors> <error> <code> </code> <message> </message> </error> 2015 Optum, Inc. 46

47 Appendix B: RSE XML integration HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual </errors> </report-load> </transaction-set> </response> Response notes/comments: <timestamp> element will have complete date plus hours, minutes and seconds along with time zone designator; ex T00:00:00-07:00 <load> will repeat for each loads value for <read> tag will have either true or false <errors> tag will be present only if the back-end (Optum) reports any error <error> tag will repeat for each error reported by the back-end XML claim load requests (Step 2: Get the data) Claim load query (load_id) Request message <?xml version="1.0" encoding="utf-8"?> <request> <transaction-set type="claim-report-query"> <claim-load> <criteria> <load-id>101</load-id> <load-id>203</load-id> </criteria> </claim-load> </transaction-set> </request> Request notes/comments: value for <load-id> should be numeric- ex Optum, Inc. 47

48 Appendix B: RSE XML integration HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual query is valid for the user organization only There are three types of responses, Announcements, Summary reports and Claim detail reports. All three types are shown below. Response message (for announcements) <?xml version="1.0" encoding="utf-8"?> <response> <transaction-set type="claim-report-response"> <claim-load> <load> <announcement> <load-id>203</load-id> <creation-date>...</creation-date> <title>announcement 3 Title</title> <content>announcement 3 Content</content> </announcement> </load> <errors> <error> <code> </code> <message> </message> </error> </errors> </claim-load> </transaction-set> </response> Response message (for summary reports) <?xml version="1.0" encoding="utf-8"?> 2015 Optum, Inc. 48

49 Appendix B: RSE XML integration HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual <response> <transaction-set type="claim-report-response"> <claim-load> <load> <summary> <load-id>101</load-id> <file-name>testdata FILE2</file-name> <report-generated>...</report-generated> <report-load-timestamp>...</report-load-timestamp> <report-processed>...</report-processed> <report-received>...</report-received> <provider-sub-id /> <provider-tax-id>...</provider-tax-id> <provider-first-name>...</provider-first-name> <provider-last-name>...</provider-last-name> <payer-name>uhc</payer-name> <organization-id>testwinh</organization-id> <payer-id>t1xed1</payer-id> <header1 /> <header2 /> <summary-id>201</summary-id> <submitted-count>22</submitted-count> <total-claim-charge>1125</total-claim-charge> <claim-accepted-count>1</claim-accepted-count> <claim-rejected-count>21</claim-rejected-count> <claim-accepted-charges>25</claim-accepted-charges> <claim-rejected-charges>...</claim-rejected-charges> 2015 Optum, Inc. 49

50 Appendix B: RSE XML integration HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual <claim-accepted-percent>4 </claim-accepted-percent> <claim-rejected-percent>...</claim-rejected-percent> </summary> </load> <errors> <error> <code> </code> <message> </message> </error> </errors> </claim-load> </transaction-set> </response> Response message (for claim detail reporting) <?xml version="1.0" encoding="utf-8"?> <response> <transaction-set type="claim-report-response"> <claim-load> <load> <claim-detail> <load-id>110</load-id> <file-name>testdata FILE1</file-name> <report-generated> t00:00:00-07:00</report- generated> <report-load-timestamp> t00:00:00-07:00</report-loadtimestamp> <report-processed> t00:00:00-07:00</report-processed> <report-received> t00:00:00-06:00</report-received> 2015 Optum, Inc. 50

51 Appendix B: RSE XML integration HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual <provider-sub-id /> <provider-tax-id> </provider-tax-id> <provider-first-name>provider1</provider-first-name> <provider-last-name>testdata</provider-last-name> <payer-name>united Healthcare</payer-name> <organization-id>testwinh</organization-id> <payer-id>uhc</payer-id> <header1>california BLUE SHIELD</header1> <header2>claim ACKNOWLEDGEMENT REPORT</header2> <claim-obj-id>210</claim-obj-id> <claim-id>1210</claim-id> <claim-value>25</claim-value> <service-start-date> :00</service-start-date> <service-end-date> :00</service-end-date> <insured-id> a</insured-id> <insured-last-name>testdata PLUMBER</insured-last-name> <insured-first-name>joe</insured-first-name> <patient-last-name>testdata PLUMBER</patient-last-name> <patient-first-name>jill</patient-first-name> <patient-account-number>nhc4829</patient-account-number> <ect-number> a000001</ect-number> <trace-number> </trace-number> <status>claim accepted for processing, forwarded to payer</status> </claim-detail> </load> <errors> <error> 2015 Optum, Inc. 51

52 Appendix B: RSE XML integration HIPAA Transactions System Integration for Channel Partner-Vendor 15.2 User Manual <code> </code> <message> </message> </error> </errors> </claim-load> </transaction-set> </response> Response Notes/Comments: <timestamp> element will have complete date plus hours, minutes and seconds along with time zone designator; ex T00:00:00-07:00 <load> will repeat for each loads value for <read> tag will have either true or false <errors> tag will be present only if the back-end (Optum) reports any error <error> tag will repeat for each error reported by the back-end 2015 Optum, Inc. 52