Early Intervention Indiana First Steps Indiana First Steps HIPAA Testing Plan

Transcription

1 Testing and Certifying HIPAA Compliance with Transaction Sets Contingency Testing Plan... 2 Testing Description... 2 Testing Procedures for Providers/Payees... 3 Testing Protocols... 4 Six Plus One Levels of Entity Internal Testing... 4 Three Levels of Inter-transaction Testing... 4 Business-to-Business Testing... 5 Transaction Compliance and Certification... 6 Testing versus Certification Testing... 6 Certification... 6 Recommendations... 7 Issues... 7 Appendix A - HIPAA Transaction Testing Matrix... 8 Appendix B WEDI/SNIP HIPAA Transaction Business Test Cases Appendix C References

2 Contingency Testing Plan Testing Description The HIPAA testing process will be as follows: Claims and RA: Early Intervention Indiana First Steps When a provider/payee submits the TPA electing to exchange information electronically, the system will be set up with indicators. The first file to be tested will be the 837P Claims submission file. The providers will upload files using the new File Distribution Website. This website will process the file through the BizTalk HIPAA Accelerator for structural compliance. This is an interactive process and the submitter will receive real-time results. There is limited information sent to the submitter about the failure. Once a file has been passed, the file will be forwarded to a HIPAA analyst that will compare it to the First Steps companion guide for data content compliance. This second testing will take two to three days to turnaround the results. The Testing is deemed complete once the submitter has successfully sent three files that pass system edits. At that time, the Provider/Payee will be activated to begin sending in 837P claims files electronically on or after October 16, Once the 837P has passed testing, the provider can begin testing RA (HIPAA 835 transactions). While the Provider/payee is in testing status, they will receive the HIPAA 835 file and paper Explanation of Payments. It is the responsibility of the Provider/Payee to notify Covansys when they have completed their testing. At that time, Covansys will update their status to Live and the paper Explanation of Payments will cease. Authorization Testing is an independent process that is not associated with the Claims processing. It will follow the same process. While the Provider/payee is in testing status, they will receive the HIPAA 278 file and paper Authorizations. It is the responsibility of the Provider/Payee to notify Covansys when they have completed their testing. At that time, Covansys will update their status to Live and the paper Authorizations will cease. Providers will be given a three-month window to complete testing. The system will automatically revert the election to paper if the testing is not complete in the allowed time frame. 2

3 Testing Procedures for Providers/Payees Early Intervention Indiana First Steps 1. The first step in beginning the testing procedure for HIPAA is to complete the Trading Partner Agreement (TPA) and submit it to Covansys. All Payees are required to submit a TPA. This TPA is located on the EIKids website. This document serves as the election form for sending and receiving electronic files. 2. The Provider/Payee must complete a secondary Certification form. This form is located in the Provider Billing Manual. The name of the Form is: CERTIFICATION STATEMENT FOR PROVIDERS SUBMITTING CLAIMS BY MEANS OTHER THAN STANDARD PAPER. This attestation page is required to be on file for all First Steps Providers. If this form has been completed in the past, please note that it is required that a new Certification form be completed. 3. Providers/Payees should then review the First Steps Companion guides for required and situational segments. All files must comply with the companion guides. 4. Providers/Payees should create files that contain a variety of services. This will increase the success factor in testing. 5. The next step in the process is to Covansys. A HIPAA specific has been established for EDI questions and inquiries. The address is inedi@pdainc.com. Covansys will contact the Provider/Payee to make arrangements to begin testing. 6. A new secured website has been established for the upload of transaction files. It is made available once the required documentation is received by Covansys. The Provider/Payee will log into the Service Matrix and the link is available in the Edit Matrix page once Covansys has received all of required information. 7. The Provider/Payee will then upload test files using this new site. Once uploaded, the file will be structurally tested using BizTalk. It will either pass or fail. Limited information about the failure will be reported to the Submitter. 8. This process will be changing in the near future. Covansys is partnering with a firm that specializing in HIPAA transaction testing. Once established, the providers/payees will be able to perform self-testing on file structure, data content and companion guide requirements. Covansys anticipates having this new testing site in place by October 16,

4 Testing Protocols The WEDI SNIP Transaction Testing Sub-Work Group 1 has identified three distinct steps in the process of testing and certifying HIPAA compliance with transaction sets: 1) During development of an EDI implementation, a HIPAA covered entity should test its own EDI implementation. This is best accomplished using special purpose EDI tools such as syntax validators. 2) Once a HIPAA covered entity has determined that its transactions are compliant, it can go through a third party evaluation of compliance, which will result in a certification of compliance for the specific functionality that was tested. 3) EDI trading partners must test interoperability, which will include loop and element size limitations, connectivity, security, data integrity, and stress testing. Rigorous self-testing of each trading partner (1) and third party certification (2) are designed to reduce or eliminate the need for transaction compliance testing between each pair of trading partners (3). Six Plus One Levels of Entity Internal Testing WEDI SNIP identifies six levels of testing for HIPAA compliance: 1) Integrity testing (X12 syntax) 2) Requirement testing (implementation guide syntax, including intra-segment usage and compliance with non-medical code sets) 3) Balancing (financial totals) 4) Situation testing (IG semantics, including inter-segment usage) 5) External code set (compliance with medical code sets) 6) Product types or lines of service (IG semantics associated with specific services, such as ambulance, chiropractic, home health, DME) An additional seventh level of testing has been identified 7) Trading Partner Specific edits - (Edits that are First Steps specific as identified in the implementation guides and payer specific) The above six levels address intra-transaction usage only. The leading vendors of automated tools for testing intra-transaction usage are Claredi and Foresight. EDIFECS is a new player in this arena. Three Levels of Inter-transaction Testing Inter-transaction usage is critically important to HIPAA compliance, as it is what makes the data exchange meaningful at a business level. For example, if a real-time request or inquiry is submitted and a response generated, the content of the response is dependent on the content of the request. For example, certain data must be returned on the response only if it was submitted on the request. Even more complex is the situation where the content of a response is dependent on the processing of a request. For example, the content of an electronic remittance advice should be based on the information that was used in the process of adjudicating a claim: this information may have been submitted on the claim, or it may have been submitted from an alternate source such as a precertification. There are no automated tools for testing inter-transaction usage. There are three levels of testing in addition to the seven previously mentioned that need to be addressed for a complete transaction-testing plan. They are: 4

5 8) Request Value Echoed in Response (The testing for data that was submitted in a Request transaction that must be included in the associated Response transaction.) 9) Request Value Altered in Response (The testing for data that was submitted in a Request transaction that was altered and included in the associated Response transaction.) 10) Generated Data Included in Response (Testing for the inclusion of data in a Response transaction that was used in the processing of a Request transaction.) HIPAA does not mandate how a covered entity achieves compliance; it merely requires that it do so. Likewise, it does not state how compliance by an entity will be proved or disproved. Thus it is up to each covered entity to determine how it wishes to achieve compliance and whether / how it wishes to demonstrate compliance. Business-to-Business Testing Business-to Business Testing as identified by WEDI SNIP should include the following testing types. This testing should be done after the entity internal testing is successful. The following testing is the types of testing that should be done with transactions exchanged between testing trading partners. 1. Load/capacity/Volume 2. Transmission Integrity 3. Maximum Field Lengths 4. Output Checking that paper and or electronic output can be created as appropriate. For example, some providers want paper remittance advices, while others want an electronic 835 transaction. 5. Security testing of certain security-related values that exist between trading partners. 5

6 Transaction Compliance and Certification The amount of work that could be required in order to complete HIPAA testing between First Steps and the providers with which it does business could be very large. First Steps currently has claim submission/payment relationships with many providers. WEDI recommends the use of third party HIPAA certifiers for health plans and health care providers to reduce the amount of one-to-one testing that would be required. Covansys is currently working on a partnership with a firm that specializes in HIPAA Certification. Given that live production data may well be used for HIPAA certification testing. This data should be subject to HIPAA security and privacy requirements to eliminate the possibility that patient identifiable information be exposed. Data integrity must be tested in a round trip scenario. This will assure that data is not dropped, truncated, changed or otherwise altered during any of the processing steps. Round trip scenarios can be generated in-house or with trading partners. Testing versus Certification. Testing Testing for the purpose of this document is broken down into two categories: Development Testing and Business-to-Business Testing. Development testing consists of HIPAA remediated processes as they are developed by HIPAA covered entities or their business partners. This testing will occur at the module, intra-application, interapplication and internal end-to-end systems levels. Regression testing will need to be performed as well to assure that processes that were working correctly prior to HIPAA compliance alterations continue to function properly. End-to-end testing can occur between two cooperating trading partners but this type of testing would be accomplished more efficiently by using HIPAA syntax validators. Business-to-Business testing covers such issues as trading partner loop and element size limitations, telecommunications connectivity, security, data integrity, round trip-integrity, stress testing, etc. This type of testing must be performed between two trading partners. Certification Certification plays a transitional role in-between Development and Business-to-Business. Once a covered entity has assured itself that it has met the criteria for HIPAA compliance, the trading partner can go through a third-party evaluation of compliance. The third party evaluator, after applying it own set of tests for compliance for each transaction, will issue a Certification of Compliance. This Certification of Compliance acts as a public disclosure or audit of the tested functionality. To date, this certification has been for a given healthcare entity with specific identification of each of the transactions for which certification testing has been successfully completed. The goal of Certification testing is to reduce the amount of Transaction Compliance testing that will be required between trading partners. This will allow the trading partners to go directly into Business-to- Business testing. Since there has been no interoperability testing of HIPAA Third party certification systems there is no guarantee of interoperability for trading partners certified by different third party certification services. 6

7 Recommendations 1. First Steps should have trading partners test at least to levels 1 and 2 before starting Business-to- Business testing. Requiring testing through Level 1 through 6 will greatly reduce the intratransaction testing required so the inter-transaction testing can be expedited. 2. In order to facilitate HIPAA transactions, Covansys is partnering with a HIPAA Specialty firm that will allow for all 7 levels of testing to be achieved. 3. Business-to-business and inter-transaction testing will be extensive. Providers should set up a list of all the services it provides for test data to be submitted for testing. This list should be used as a base for the identification of business-to-business transaction beta sites. Issues 1. No HIPAA Transaction Certification Service certification process is in place. Trading partners with certifications from different certification services may not be interoperable. a. Covansys is currently negotiating to establish an automated Self Testing Web Community that providers can use without charge to complete testing against First Steps Companion guides. Covansys anticipates that the Web Communities will be in place by October 16, b. The contingency plan for testing has been enacted. This plan will allow providers to begin the structural level 1 and level 2 tests. 7

8 Appendix A - HIPAA Transaction Testing Matrix Testing Level Description Testing Scope 1 Level 1: Integrity Testing Testing for valid segments, segment order, element attributes, numeric values in numeric data elements, validation of X12 syntax, and compliance with X12 rules. Level 2: Requirement Testing Level 3: Balancing Level 4: Situation testing Level 5: External Code Set testing Testing for HIPAA implementation-guide-specific syntax requirements, such as repeat counts, used and not used codes, elements and segments, required or intra-segment situational data elements. Testing for non-medical code sets as laid out in the implementation guide. Values noted in the implementation guide via an X12 code list or table. Testing the transaction for balanced field totals, financial balancing of claims or remittance advice, and balancing of summary fields, if appropriate The testing of specific inter segment situations described in the HIPAA implementation guides, such that: If A occurs then B must be populated. This is considered to include the validation of situational fields given values or situations present elsewhere in the file. Example: if the claim is for an accident, the accident date must be present. Testing for valid implementation-guide-specific code set values. This level of testing will not only validate the code sets but also make sure the usage is appropriate for any particular transaction. Validates external code sets and tables such as CPT, ICD9, CDT, NDC, status codes, adjustment reason codes, and their appropriate use for the transaction. 8

9 Testing Level Description Testing Scope 1 Level 6: Product Types or Line of Services: The testing is required to ensure that the segments / records of data that differ based on certain healthcare services are properly created and processed into claims data formats. For example, home health, durable medical equipment, psychiatry, and other specialized services have specific requirements in the implementation guide that must be tested before putting the transaction in production. Level 7: Entity Specific Edits Level 8: Request Value Echo in Response 2 Level 9: Request Value Altered in Response 2 Level 10: Generated data included in Response 2 The testing of edits specific to a covered entity for inbound and outbound transactions. The testing for data that was submitted in a Request transaction that must be included in the associated Response transaction. The testing for data that was submitted in a Request transaction that was altered and included in the associated Response transaction. Alterations may occur due to processing or correction of request data. Testing for the inclusion of data in a Response transaction that was used in the processing of a Request transaction (whether it was submitted in the Request or not) Inter-transaction/ Interoperability Testing Inter-transaction/ Interoperability Testing Inter-transaction/ Interoperability Testing Notes: 1. This column indicates the scope of the testing. Possible values are Entity Self-Testing, Trading Partner Self-Testing, and Inter-transaction/Interoperability Testing. 2. These levels were developed for the purpose of including the specified testing types in this document. 9

10 Appendix B WEDI/SNIP HIPAA Transaction Business Test Cases There are 156 business test cases identified in the WEDI SNIP Business Test Case table found on the Claredi web site. For the purpose of brevity they have not been listed here. These business test cases can be found at under the heading WEDI/SNIP Business Scenarios. These files may be used as a base for Aetna Internal testing and trading partner self-testing. Appendix C References 1. Transaction Compliance and Certification A White-Paper Describing the Recommended Solutions Associated with Compliance Certification of the HIPAA Transactions, Draft Version 2, October 11, 2001, 14 pages Business-to-Business Transaction Set Testing A White-Paper Describing the Recommended Solutions Associated with Transaction Set Testing between Business Partners, Draft Version 2, December 17, 2001, 17 pages. 10