HIPAA Transaction Standard Companion Guide ASC X12 005010X212A1 Health Care Claim Status Request and Response (276/277) Disclosure Statement This companion guide for real-time and batch 276/277 follows the CAQH CORE Phase I and Phase II guidelines. February 2017
This Companion Guide is prepared for use by trading partners affiliated with Kaiser Foundation Health Plan of Washington. This Companion Guide is to be used with, and not as a replacement for, the ASC X12N 5010 version of the HIPAA Transaction Technical Report Type 3 (TR3). The TR3 s for each transaction are available electronically from the WPC website at http://www.wpc-edi.com/. This Companion Guide is considered a living document, and as such, the information provided herein will be subject to change. A copy of the document and any changes to the document will be posted via the Kaiser Foundation Health Plan of Washington website located at: https:// kp.org/wa/ provider.ghc.org/open/billingandclaims/claimsprocedures/index.jhtml Kaiser Foundation Health Plan of Washington is committed to maintaining the integrity and security of health care data in accordance with applicable laws and regulations. Preface The Health Insurance Portability and Accountability Act (HIPAA) requires all health insurance payers to comply with the Electronic Data Interchange (EDI) standards for health care as established by the Department of Health and Human Services. This Companion Guide to the v5010 ASC X12N Implementation Guide (or TR3) and associated errata, adopted under HIPAA, clarifies the data content used when exchanging claim status data electronically with Kaiser Foundation Health Plan of Washington. Transmissions based on 2013 Group Health Cooperative 2
this Companion Guide, used in tandem with the ASC X12 276/277 and the ASC X12 999 TR3s, are compliant with both X12 syntax and the TR3. This Companion Guide is intended to convey information that is within the framework of the ASC X12 Implementation Guides adopted for use under HIPAA. The document further specifies the requirements to be used when preparing, submitting, receiving and processing electronic health care administrative data. The document supplements, but does not contradict, disagree, oppose, or otherwise modify the HIPAA Implementation Guide in a manner that will make its implementation by users to be out of compliance. Using this Companion Guide does not mean that a claim will be paid. 2013 Group Health Cooperative 3
1 TABLE OF CONTENTS 1.1 5 1.2 6 1.3 REFERENCES 6 1.4 6 2 GETTING 2.1 WORKING WITH OUR HEALTH 6 2.2 TRADING PARTNER 6 2.3 AND TESTING 6 3 TESTING WITH THE 4 CONNECTIVITY WITH THE 9 A. SOAP: Real-time 9 B. MIME Multipart: Real-time... 10 C. SOAP: Batch... 12 D. MIME Multipart: Batch... 13 E. HTTP Error Messages... 15 F. Envelope Errors... 15 G. Batch Response and Retrieval... 16 H. Connectivity Information to the SFTP server... 16 5 CONTACT INFORMATION EDI... 16 6 CONTROL 7 PAYER SPECIFIC BUSINESS RULES AND 8 4.1 PROCESS 4.2 4.3 7.1 SPECIFIC SERVICE... 18 7.2 AAA... 18 7.3. CORE LEVEL OF CERTIFICATION... 18 8.1...19 8.2...19 9 TRADING PARTNER 10 TRANSACTION SPECIFIC INFORMATION APPENDICES 8 PROCEDURES... 8 A. CHECKLIST... 20 B. BUSINESS...20 C. EXAMPLES... 20 D. CHANGE SUMMARY... 21 E. SFT SET UP... 21 F. LOSSARY... 21 2013 Group Health Cooperative 4
Revision History Date Version Description Author 11-18- 2013 10-24- 2014 2.0 New Release G. Schulte 2.1 Updated realtime response restrictions G. Schulte 02 03 2016 2.2 Update real time response requirements G. Schulte 02-01-2017 2.3 Update Name Reviewers Date Version Reviewers Role & Responsibility 11-27-12 & 11-28-12.1 G. Schulte Lead Integration Architect Gladys Jones Jack Hempel Sergio Angarita Pete Schneider Health Plan IT Consultant Integration Architect Integration Architect Integration Developer Approvers Date Version Approver Role & Responsibility 07-11-13 1.5 Gladys Jones Health Plan IT Consultant 11/22/2013 2.0 Gladys Jones Health Plan IT Consultant 10/22/2014 2.1 Gladys Jones Health Plan IT Consultant 02/04/2016 2.2 Gladys Jones Health Plan IT Consultant 5
1 INTRODUCTION 1.1 OVERVIEW The purpose of this document is to introduce and provide information about Kaiser Foundation Health Plan of Washington CAQH/CORE solution for submitting real time and batch 276/277 transactions. This document will cover the Phase II operating rules requirements for the claim status transaction. The 276 and 277 transactions are used in tandem: the 276 transaction is used to request the status of a health care claim(s) and the 277 to respond with the information regarding the specified claim(s). These transactions can be real-time or batch. Kaiser Foundation Health Plan of Washington supports both real-time and batch transactions; and returns detailed claim status information on the 277 Response. 1.2 SCOPE Providers, clearing houses, and other trading partners are advised to refer to the v5010 ASC X12 Implementation Guide for submitting the claim status inquiries. This companion guide should be used to clarify and find more information about the CORE requirements and rules regarding batch and real-time transactions, i.e. acknowledgments, connectivity, response time, system availability, and data content. 1.3 REFERENCES ASC X12 Version 5010A1 Implementation Guides: http://www.wpc-edi.com CAQH/CORE: http://www.caqh.org/benefits.php WSDL: http://www.w3.org/tr/wsdl SOAP: http://www.w3.org/tr/soap/ MIME Multipart: http://www.w3.org/protocols/rfc1341/7_2_multipart.html CORE XML Schema: http://www.caqh.org/soap/wsdl/corerule2.2.0.xsd 1.4 ADDITIONAL INFORMATION Kaiser Foundation Health Plan of Washington currently supports both batch and real-time transactions. Kaiser Foundation Health Plan of Washington has adopted the two envelope standards mandated in CORE Phase II. 1. HTTP MIME Multipart 2. SOAP + WSDL Kaiser Foundation Health Plan of Washington has chosen the use of X.509 certificates for authentication. The external partner that wants to connect with Kaiser Foundation Health Plan of Washington will issue a X.509 certificate signed by a known certificate authority (CA) i.e. VeriSign, etc. Once the certificate is issued, the external partner will provide Kaiser Foundation Health Plan of Washington with the Distinguished Name (DN) for Kaiser Foundation Health Plan of Washington to verify the external partner s identity when they connect to our Gateway. 6
2 GETTING STARTED 2.1 WORKING WITH OUR HEALTH PLANS Providers, billing services and clearinghouses interested in submitting 276 inquiries and receiving 277 responses for either real-time or batch to/from for Kaiser Foundation Health Plan of Washington should contact the EDI team at edisupport@ghc.org. 2.2 TRADING PARTNER REGISTRATION Trading partner registration is required in order to submit 276 requests and receive 277 responses. Please find attached in appendices the submit request form which will initiate the registration process. (Refer to Appendix F) 2.3 CERTIFICATION AND TESTING OVERVIEW Kaiser Foundation Health Plan of Washington requires submitting at least one test transaction to ensure data transfer is successful with connectivity using the certificate. The testing URLs are given below: HTTP MIME QA RealTime Test Request : https://dpgw-qa.ghc.org/rtcoremimeprocessing/service/request HTTP MIME QA Batch Test Request : https://dpgw-qa.ghc.org/btcoremimeprocessing/service/request SOAP QA RealTime Test Request Request: https://dpgw-qa.ghc.org/rtcoresoapprocessing/service/request SOAP QA Batch Test Request Request: https://dpgw-qa.ghc.org/btcoresoapprocessing/service/request WSDL: https://dpgw.ghc.org/coresoap/service/request?wsdl 3 TESTING WITH THE PAYER Listed below are steps to follow when testing: Provide the Distinguished Name for X509 Certification to Kaiser Foundation Health Plan of Washington EDI Support An EDI coordinator will be assigned to work with you on the registration and testing Create test transactions (preferably good and bad requests) based on Companion Guide/Implementation Guide specifications and submit via the testing URL, either real-time or batch or both, as necessary ( Refer to Appendix C for transaction example) Retrieve, review, and validate the appropriate response (277 or 999) Submit confirmation to determine production readiness Move to production upon consensus 7
4 CONNECTIVITY WITH THE PAYER/COMMUNICATIONS 4.1 PROCESS FLOW Process flow is layered by http process, envelope, and then business process. Only when the inbound transmission has passed the outer layers to the business process will a 999 and/or a 271 response be returned. 4.2 TRANSMISSION/Re-TRANSMISSION ADMINISTRATIVE PROCEDURES Real time 276 inquiries are limited to one status request. A response to the real-time inquiry will not exceed 20 seconds on average 90% of the time for our monthly volume. If a Real time response message is not received within the 60 second response time period, the submitter s system may send a duplicate transaction no sooner than 90 seconds after the original attempt was sent. Batch 276 inquiries are limited to 99 status requests within an ST/SE grouping. A response to the batch inquiry will be provided by 7 a.m. (PST) the following business day for batches received before 9 pm (PST) the previous day. Batch requests submitted after 9 p.m. (PST) will be available by 7 a.m. (PST) two business days following submission. The following links below provide more information on: System Maintenance: Please refer to the respective health plan page for the most up-to-date information on system availability at: https:// kp.org/wa/provider/open/billingandclaims/claimsprocedures/index.jhtml 8
System Downtime: All scheduled downtimes and the respective health plan holiday schedules will be published and emergency downtimes will be posted in the below link: https:// kp.org/wa/provider /open/billingandclaims/claimsprocedures/index.jhtml 4.3 COMMUNICATION PROTOCOL SPECIFICATIONS In compliance with Core rules, Kaiser Foundation Health Plan of Washington requires that all SOAP transactions conform to SOAP Version 1.2. The XML schema definition set forth by CORE and used by our EDI is located at: http://www.caqh.org/soap/wsdl/corerule2.2.0.xsd The WDSL definition set forth by CORE and used by our EDI is located at: http://www.caqh.org/soap/wsdl/corerule2.2.0.wsdl Connectivity Mode Transaction Request Submission to URL SOAP + WSDL HTTP + MIME Secure Web Service Secure Web Service Secure Web Service Secure Web Service Real-time Time X 12 Batch X12 Real-time Time X12 Batch X12 https://dpgw.ghc.org/rtcoresoapprocessing /service/request https://dpgw.ghc.org/btcoresoapprocessing /service/request https://dpgw.ghc.org/rtcoremimeprocessin g/service/request https://dpgw.ghc.org/btcoremimeprocessing /service/request WSDL https://dpgw.ghc.org/coresoap/service/requ est?wsdl A. SOAP: Real-time Message Content Details: Payload Type: Payload Type specifies the type of payload included within a request. Valid values are: Request X12_276_Request_005010X212 Response 9
X12_277_Response_005010X212 X12_999_Response_005010X231A1 Processing Mode: Processing Mode indicates Real-time processing mode. Valid value is RealTime Payload ID: This is an Identifier that is used to uniquely identify the request submitted. Values are Alphanumeric, may contain hyphen. Timestamp: Time and Date specifying when a message is created and sent to a receiver. Valid value follows standard Universal Time (UTC) http://www.w3.org/tr/xmlschema11-2/#datetime Sender ID: Submitter ID/Client ID Valid value is 7 characters alphanumeric as assigned by Kaiser Foundation Health Plan of Washington Receiver ID: Kaiser Foundation Health Plan of Washington s Tax ID Valid value is 11 characters alphanumeric. i.e. 910511770RT CORE Rule Version: The CORE Rule version that this envelope is using will be 2.2.0. Payload: Payload contains compliant X12 276 request data. Payload should be encrypted using BASE 64 encode. B. MIME Multipart: Real-time HTTP Headers: For MIME multipart the messages should always contain Content-Type that specifies the boundary used to separate each part of the message. Example: Content-Type: multipart/form-data; boundary=xbcy Message Content Details: Payload Type: Payload Type specifies the type of payload included within a request. Valid values are: Request X12_276_Request_005010X212 Response X12_277_Response_005010X212 X12_999_Response_005010X231A1 Processing Mode: Processing Mode indicates real-time processing mode. Valid value is RealTime 10
Payload ID: This is an Identifier used to uniquely identify the request submitted. Values are Alphanumeric, may contain hyphen. Time Stamp: Time and Date specifying when a message is created and sent to a receiver. Valid value follows standard Universal Time (UTC) http://www.w3.org/tr/xmlschema11-2/#datetime Sender ID: Submitter ID/Client ID. Valid value is 7 characters alphanumeric as assigned by Kaiser Foundation Health Plan of Washington. Receiver ID: Kaiser Foundation Health Plan of Washington s Tax ID Valid value is 11 characters alphanumeric. i.e. 910511770RT CORE Rule Version: The CORE Rule version that this envelope is using will be 2.2.0. Payload: Payload contains compliant X12 276 request data. Payload should be encrypted using BASE 64 encode. Real-time Example: --XbCY Content-Disposition: form-data; name="payloadtype" X12_276_Request_005010X212 --XbCY Content-Disposition: form-data; name="processingmode" RealTime --XbCY Content-Disposition: form-data; name="payloadid" e51d4fae-7dec-11d0-a765-00a0c91e6da6 --XbCY Content-Disposition: form-data; name="timestamp" 2007-08-30T10:20:34Z --XbCY Content-Disposition: form-data; name="senderid" HOSPIX9 --XbCY Content-Disposition: form-data; name="receiverid" 91051170RT --XbCY Content-Disposition: form-data; name="coreruleversion" 2.2.0 11
--XbCY Content-Disposition: form-data; name="payload" ISA*00* --XbCY-- *00* *ZZ C. SOAP: Batch HTTP Headers: For MTOM the messages should always contain Content-Type that specifies among others the boundary used to separate each part of the message. Example: Content-Type: multipart/related; type="application/xop+xml"; start="<rootpart@soapui.org>"; start-info="application/soap+xml"; action="batchresultsacksubmittransaction"; boundary="---- =_Part_0_27814834.1352504024823" In return, we will also send a Content-Type that specifies among others the boundary used to separate each part of the message. Example: Content-Type: multipart/related; boundary="wmbmime1boundaryurn_uuid_523f992ed9ce810e7f1352504025645"; start-info="application/soap+xml"; type="application/xop+xml"; start="<0.urn:uuid:523f992ed9ce810e7f1352504025646@ibm.com>" Message Content Details: Payload Type: Payload Type specifies the type of payload included within a request. Valid values are: Request X12_276_Request_005010X212 X12_999_RetrievalRequest_005010X231A1 X12_005010_Request_Batch_Results_277 X12_999_SubmissionRequest_005010X231A1 Response X12_BatchReceiptConfirmation X12_999_Response_005010X231A1 X12_277_Response_005010X212 X12_Response_ConfirmReceiptReceived Processing Mode: Processing Mode indicates Batch. Valid value is Batch 12
Payload ID: This is an Identifier that will be used to uniquely identify the request submitted. Values are Alphanumeric, may contain hyphen. Payload Length: Defines the length of the actual X12 payload in bytes. Timestamp: Time and Date specifying when a message is created and sent to a receiver. Valid value follows standard Universal Time (UTC). http://www.w3.org/tr/xmlschema11-2/#datetime Sender ID: Submitter ID/Client ID. Valid value is 7 characters alphanumeric as assigned by Kaiser Foundation Health Plan of Washington EDI team. Receiver ID: Kaiser Foundation Health Plan of Washington s Tax ID Valid value is 9 characters numeric. i.e. 910511770 CORE Rule Version: The CORE Rule version that this envelope is using will be 2.2.0. Checksum: An element used to allow receiving site to verify the integrity of the message that is sent. Algorithm is SHA-1, Encoding is Hex. Checksum must be computed only on the payload and not on the metadata. Payload: Payload contains compliant X12 276 request data. Payload should be encrypted using BASE 64 encode. D. MIME Multipart: Batch HTTP Headers: For MIME multipart the messages should always contain Content-Type that specifies the boundary used to separate each part of the message. Example: Content-Type=multipart/form-data; boundary=xbcy Message Content Details: Payload Type: Payload Type specifies the type of payload included within a request. Valid values are: Request X12_276_Request_005010X212 X12_999_RetrievalRequest_005010X231A1 X12_005010_Request_Batch_Results_277 X12_999_SubmissionRequest_005010X231A1 Response X12_BatchReceiptConfirmation X12_999_Response_005010X231A1 X12_277_Response_005010X212 X12_Response_ConfirmReceiptReceived 13
Processing Mode: Processing Mode indicates Batch. Valid value is Batch Payload ID: This is an Identifier that you will use to uniquely identify the request submitted. Values are Alphanumeric, may contain hyphen. Payload Length: Defines the length of the actual payload in bytes. Timestamp: Time and Date specifying when a message is created and sent to a receiver. Valid value follows standard Universal Time (UTC). http://www.w3.org/tr/xmlschema11-2/#datetime Sender ID: Submitter ID/Client ID. Valid value is 7 characters alphanumeric as assigned by Kaiser Foundation Health Plan of Washington. Receiver ID: Kaiser Foundation Health Plan of Washington s Tax ID Valid value is 9 characters numeric. i.e. 910511770 CORE Rule Version: The CORE Rule version that this envelope is using will be 2.2.0. Checksum: An element used to allow receiving site to verify the integrity of the message that is sent. Algorithm is SHA-1, Encoding is Hex. Checksum must be computed only on the payload and not on the metadata. Payload: Payload contains compliant X12 276 request data. Payload should be encrypted using BASE 64 encode. Batch Example: --XbCY Content-Disposition: form-data; name="payloadtype" X12_999_SubmissionRequest_005010X231A1 --XbCY Content-Disposition: form-data; name="processingmode" Batch --XbCY Content-Disposition: form-data; name="payloadid" f81d4fae-7dec-11d0-a765-00a0d91e6fa6 --XbCY Content-Disposition: form-data; name="payloadlength" 10240 --XbCY Content-Disposition: form-data; name="timestamp" 2007-08-30T10:20:34Z --XbCY Content-Disposition: form-data; name="senderid" 14
CLMLGC9 --XbCY Content-Disposition: form-data; name="receiverid" 910511770 --XbCY Content-Disposition: form-data; name="coreruleversion" 2.2.0 --XbCY Content-Disposition: form-data; name="checksum" 6A3FE55946 --XbCY Content-Disposition: form-data; name="payload" SVNBKjAwKiAgICAgICAgICAqMDA= --XbCY-- E. HTTP Error Messages 1. HTTP 200 OK Returned when authentication is valid and request is accepted with the real-time system. 2. HTTP 202 OK Returned when batch file submission has been accepted. 3. HTTP 400 Bad Request Returned for incorrectly formatted HTTP headers. 4. HTTP 403 Forbidden Returned when the user is unauthorized. 5. Server Errors When the real-time production system is not able to process a real-time request due to interface failures or other system unavailability, a standard 5xx series error such as HTTP 500 Internal Server Error or HTTP 503 Service Error will be returned by the application. Resubmission is recommended at a later time. F. Envelope Errors 1. Success Envelope was processed successfully. 2. <FieldName>Illegal Illegal value provided for <FieldName>. 3. <FieldName>Required The field <FieldName> is required but was not provided. 4. Version Mismatch The version of the envelope sent is not acceptable to the receiver. If the SOAP version is not valid at the receiver, a SOAP fault is returned with this fault code. 15
5. Checksum Mismatched The checksum value computed on the recipient did not match the value that was sent in the envelope. G. Batch Response and Retrieval All batch requests for claim sataus and batch results acknowledgment will be received by establishing a HTTP connection using CORE rules. The trading partners must submit a request for available responses. Kaiser Foundation Health Plan of Washington provides a list of 277/999 files available for pick up. Kaiser Foundation Health Plan of Washington uses an SFTP server where the files are available for pick up. To connect to this server, the Trading Partner must request an account. All our trading partners as of December 2012 already have an account to connect to this server. For future partners, a form is available online and in Appendix E to request access to the server. The user ID assigned to log into this server is the user ID that has to be sent in the Sender ID field when submitting requests real-time or batch through the HTTP standard connection. H. Connectivity Information to the SFTP server Server name: sft3.ghc.org Port: 22 Folder PROD: my_inboxes/mercator/ Folder TEST: my_test_inboxes/mercator/ Maximum number of real-time and batch transactions per minute per client Real time: 5 Batch: 1 Maximum size of Batch files: Maximum size of a file sent as an attachment to the HTTP request will be 1 MB 5 CONTACT INFORMATION EDI CUSTOMER SERVICE For questions regarding Kaiser Foundation Health Plan of Washington 276/277 real-time and batch transmission, or this guide, please contact: EDI Support Group Monday Friday, 8:00 AM 4:00 PM PST Ph: (206) 901-6700 Email: edisupport@ghc.org For specific questions regarding Subscriber/Plan information, please go the web sites: https:// kp.org/wa/provider /open/billingandclaims/claimsprocedures/index.jhtml 6 CONTROL SEGMENTS/ENVELOPES 16
ISA-IEA SEGMENT: Loop ID Segment Type Element Identifier Element Name Attribute Value Header ISA ISA01 Authorization Information Qualifier ID 0 ISA02 Authorization Information AN Security Information ISA03 Qualifier ID 0 ISA04 Security Information AN ISA05 Interchange ID Qualifier ID ZZ ISA06 Interchange Sender ID AN ISA07 Interchange ID Qualifier ID ZZ ISA08(BATCH) Interchange Receiver ID AN 910511770 ISA08 (REALTIME) Interchange Receiver ID AN 910511770RT ISA09 Interchange Date DT ISA10 Interchange Time TM ISA11 Repetition Separator ^ Interchange Control ISA12 Version Number ID 0501 Interchange Control ISA13 Number N0 ISA14 Acknowledgement Requested ID 0 Usage Indicator ISA15 T-Test, P-Production ID T/P Component Element ISA16 Separator AN Loop ID Segment Type Trailer IEA IEA01 Element Identifier Element Name Attribute Value Number of Included Functional Groups Interchange Control IEA02 must match Interchange Control GS-GE SEGMENT: Segment Type Element Identifier Element Name Attribute Value Loop ID Header GS01 Functional Identifier Code ID HS GS02 Application Sender Code AN GS03 Application Receiver Code AN 91051177 GS04 Date DT GS05 Time TM GS06 Group Control Number N0 GS07 Responsible Agency Code ID X 17
GS08 Version Identifier Code AN 005010X212 Segment Type Element Identifier Element Name Attribute Value Loop ID Trailer GE GE01 Number of Transaction Sets Included GE02 Group Control Number ST-SE: Segment Element Loop ID Type Identifier Element Name Attribute Value Header ST ST01 Transaction Set Identifier Code ID 276 ST02 Transaction Set Control Number AN 1 ST03 Implementation Convention Reference AN 005010 X212 Segment Element Loop ID Type Identifier Element Name Attribute Value Trailer SE01 Number of Included Segments SE02 Transaction Set Control Number One ISA/IEA may contain more than one Functional Group (GS/GE). The functional group must be an claim status transaction type (005010X212). 7 PAYER SPECIFIC BUSINESS RULES AND LIMITATIONS 7.1 SPECIFIC SERVICE CODES Kaiser Foundation Health Plan of Washington EDI follows the Washington Best Practices guidelines for the Service codes. For more information please, refer to the link below: http://www.onehealthport.com/worksmart/bproverview.php 7.2 AAA CODES Not Applicable 7.3. CORE LEVEL OF CERTIFICATION At this time Kaiser Foundation Health Plan of Washington has passed testing for CORE levels 1 and 2 certification. 18
8 ACKNOWLEDGEMENTS 8.1 REAL-TIME Following responses can be expected from Kaiser Foundation Health Plan of Washington EDI for a real-time 276 transaction: 8.2 BATCH 277 response transaction indicating the requested member s coverage or benefits (or) 999 acknowledgement (for a 276 Reject) if the 276 transaction contains HIPAA compliancy errors Following responses can be expected from Kaiser Foundation Health Plan of Washington EDI for a batch 276 transaction: 277 response transaction will be available the following day indicating the requested member s coverage or benefits 999 acknowledgement within an hour if the 276 transaction contains HIPAA compliancy errors 9 TRADING PARTNER AGREEMENTS Trading Partner agreement is not required for claim status inquiries but trading partner registration is mandatory. 10 TRANSACTION SPECIFIC INFORMATION Kaiser Foundation Health Plan of Washington EDI follows the standard information in the ASC X12N 276/277(005010X212) Health Care Claim Status Inquiry and Response Implementation Guide. 2013 Kaiser Foundation Health Plan of Washington 19
A. IMPLEMENTATION CHECKLIST Provide the Distinguished Name for X509 Certification to Kaiser Foundation Health Plan of Washington An EDI coordinator will be assigned to work with you on the registration and testing Create test transactions (preferably good and bad requests) based on Companion Guide/Implementation Guide specifications and submit via the testing link, either real-time or batch or both, as necessary ( Refer to Appendices C for transaction example) Retrieve, review, and validate the appropriate response (277 or 999) Submit confirmation to determine production readiness Move to production upon consensus B. BUSINESS SCENARIOS NA C. TRANSMISSION EXAMPLES Kaiser Foundation Health Plan of Washington Health Real Time Transmission Example Sample 276 Transaction ISA*00* *00* *ZZ*YOUR ID *ZZ*910511770RT *100301*1347*!*00501*010060701*1*T*: GS*HR*YOUR ID *910511770RT *20121212*1347*10060701*X*005010X212 ST*276*010060701*005010X212 BHT*0010*13*RAM276TEST*20121212*1425 HL*1**20*1 NM1*PR*2* KAISER FOUNDATION HEALTH PLAN OF WASHINGTON *****PI*98111 HL*2*1*21*1 NM1*41*2*ABC PROVIDER SERVICES*****46*123456789 HL*3*2*19*1 NM1*1P*2* ABC PROVIDER SERVICES*****XX*188877666 HL*4*3*22*0 DMG*D8*19670203*M NM1*IL*1*CLAIMTEST*MIKE****MI*02020040 TRN*1*1220201200 REF*1K*1219015002004 AMT*T3*200.00 DTP*472*RD8*20120315-20120317 SE*16*010060701 GE*1*10060701 IEA*1*010060701 20
Sample 277 Transaction ISA*00* *00* *ZZ*9810511770RT *ZZ*YOUR ID *121228*1145*^*00501*000000001*0*T*: GS*HN*9810511770*YOUR ID*20121228*114513*1*X*005010X212 ST*277*000000001*005010X212 BHT*0010*08*010060701*20121228*114513*DG HL*1**20*1 NM1*PR*2* KAISER FOUNDATION HEALTH PLAN OF WASHINGTON *****PI*98111 HL*2*1*21*1 NM1*41*2* ABC PROVIDER SERVICES*****46*123456789 HL*3*2*19*1 NM1*1P*2* ABC PROVIDER SERVICES*****XX*188877666 HL*4*3*22*0 NM1*IL*1*CLAIMTEST*MIKE****MI*02020040 TRN*2*1220201200 STC*F1:65*20120904**200*0*20120904 REF*1K*1219015002004 REF*BLT*131 DTP*472*RD8*20120315-20120317 SE*16*000000001 GE*1*1 IEA*1*000000001 D. CHANGE SUMMARY This is the first companion guide for claim status from Kaiser Foundation Health Plan of Washington for CORE. E. SFT Setup See our web site for the current form F. Glossary ACRONYM ASC X12N CA CAQH CORE DN EDI HIPAA HTTP MIME MTOM SFTP SHA-1 SOAP TR3 Accredited Standards Committee Certificate Authority Council for Affordable and Quality Healthcare Committee on Operating Rules for Information Exchange Distinguished Name Electronic Data Interchange Health Insurance Portability and Accountability Act Hypertext Transfer Protocol Message Transmission Optimization Mechanism Multipurpose Internet Mail Extensions Secure File Transfer Protocol Secure Hash Algorithm Simple Object Access Protocol Technical Reports 21
WPC WSDL XML Washington Publishing Company Web Service Definition Language Extensible Markup Language 22
23