White Paper Testing Sub Workgroup Testing and Implementation From the Provider Perspective: Is Your Practice Truly Ready?

Transcription

1 WEDI Strategic National Implementation Process (SNIP) 5010 Testing Sub Workgroup White Paper 5010 Testing and Implementation From the Provider Perspective: Is Your Practice Truly Ready? April 29, 2011 Workgroup for Electronic Data Interchange Sunrise Valley Dr., Suite 100, Reston, VA (t) / (f)

2 Disclaimer This document is Copyright 2011 by The Workgroup for Electronic Data interchange (WEDI). It may be freely redistributed in its entirety provided that this copyright notice is not removed. It may not be sold for profit or used in commercial documents without the written permission of the copyright holder. This document is provided as is without any express or implied warranty. While all information in this document is believed to be correct at the time of writing, this document is for educational purposes only and does not purport to provide legal advice. If you require legal advice, you should consult with an attorney. The information provided here is for reference use only and does not constitute the rendering of legal, financial, or other professional advice or recommendations by the Workgroup for Electronic Data Interchange. The listing of an organization does not imply any sort of endorsement and the Workgroup for Electronic Data Interchange takes no responsibility for the products, tools, and Internet sites listed. The existence of a link or organizational reference in any of the following materials should not be assumed as an endorsement by the Workgroup for Electronic Data Interchange (WEDI), or any of the individual workgroups or sub-workgroups of the Strategic National Implementation Process (SNIP). This document is intended for education and awareness use. WEDI 5010 Testing Workgroup Page 2

3 Table of Contents Purpose and Scope... 5 Overview... 5 Preparing for 5010 Testing... 6 Develop test plans and test scenarios for all systems, interfaces, transactions and reports Trading Partner Testing... 7 Concept... 7 Content... 7 Connectivity... 8 Test Environments... 8 Internal... 8 Internal Payer or Clearinghouse... 8 Provider... 8 Multiple Transaction Testing... 9 Readiness Assessment... 9 Internal Readiness (level 1 compliance)... 9 Trading Partner Testing Readiness (level 2 compliance)... 9 Syntax Translation Validation Challenges Recommendations Trading Partner Requirements Administrative Agreements Multiple Submitter IDs vs IDs and Dual Submission Communications Protocols Legacy Platforms Additional Testing Requirements Testing Parameters File Size Live vs. dummy data de-identify/re-identify Percentage of clean claims WEDI 5010 Testing Workgroup Page 3

4 Number of clean files Use of third party X12N validation services (multiple phases) Challenges Recommendations Development and Use of Test Scenarios Final Rule vs. ERRATA I (A1 vs. A2) What is the ERRATA? Application of rules from 4010 to Recommendations Testing Lifecycle Testing With Your Software Vendor Assess vendor readiness Which transactions to test first What to test Testing Workflow Reporting and Feedback Plan Moving to Production Contingency planning Conclusions Acknowledgements Appendix A Definitions WEDI 5010 Testing Workgroup Page 4

5 Purpose and Scope Imagine today is 1/1/2012. You must now transmit and receive electronic administrative transactions, (claims, remits, claim status, eligibility, etc.) using the new ASC X standard adopted under HIPAA. Is your practice prepared to address any potential pitfalls? Can you live with a potential drop in reimbursement? Are there any steps that you can take now to avoid any challenges? Do you have a backup plan if all fails? This whitepaper provides information on the 5010 testing initiative and is specifically developed to address the provider s perspective. It will include terminology frequently utilized by the industry, and provide an understanding of the steps Providers must take to initiate and complete testing with trading partners. This paper will build on previous WEDI work which identified the key business changes in the 5010 transactions. This paper is not intended to provide specific test transactions, discuss different testing methods currently used, or discuss multiple transaction testing definition and the interpretation of such testing in the industry. Please keep in mind that the 5010 version supports data content for the ICD-10. Overview On January 16, 2009, the United States Department of Health and Human Services (HHS) announced final rules requiring the implementation of new versions of the transaction standards whose use is required under the Administrative Simplification provisions of the federal HIPAA law. These versions are intended to improve patient care quality, enhance claim processing, improve reporting and promote interoperability. The final compliance date is January 1, (Note: The rule setting out of this timeline also introduced a requirement for a new transaction for retail pharmacy Medicaid subrogation (NCPDP version 3.0). Small health plans have until 1/1/2013 to support this new standard, all others using the transaction have until 1/1/2012 to support. This provides lead time for industry compliance with the October 1, 2013 requirement for ICD-10 code sets used to report healthcare diagnoses and procedures. 5010/D.O. HHS Timeline Guidance: Target Date Milestone Jan 2009 Begin Level 1 activities (gap analysis, design, and development) Jan 2010 Begin internal testing for HIPAA 5010 and NCPDP D.0 Dec 2010 Achieve Level 1 compliance (covered entities have completed internal testing and can send and receive compliant transactions) Jan 2011 Begin Level 2 testing period activities (external testing with trading partners and move into production; dual 4010A/5010 processing mode) Begin initial ICD-10 compliance activities (gap analysis, design, development, and internal testing) Jan 1, /D.0 compliance date for all covered entities WEDI 5010 Testing Workgroup Page 5

6 The 5010 transactions and D.O pharmacy standards address electronic claims, electronic eligibility verification, electronic claim status, electronic referral certification and authorization, electronic remittance and more. Version D.0 of the pharmacy standards facilitate both coordination-of-benefits claims processing and Medicare Part D claims processing. Medicare and most other payers are conducting both the current 4010A1 and pharmacy standards and the new 5010/D.0 standards until Jan. 1, Those ready to use the new standards can begin testing and implementation now, and all providers have to complete implementation by Jan 1, New features of the 5010 fall into four categories: front matter changes, technical improvements, structural changes, and data content changes. The front matter changes primarily address the consistency and standardization of content presentation. The ASC X12N Technical Report Type 3 (TR3 now follow a common format with the same subsections for each transaction. The 5010 also contains substantial changes to content related to business functions, rules and their usage. Technical improvements incorporate granular changes intended for simplicity of information exchange. Improvements include ensuring that same data representation is followed across guides and replaces generic descriptions. Structural changes include data segments, data elements and composite elements that have been modified, added or deleted, or in some cases restructured transaction loops. Data content changes include business cases that have been reviewed and clarified eliminates redundancies and adds necessary data for proper implementation. These changes and modifications to current business procedures and claims processing must be considered when outlining testing initiatives. There are nine transactions which define electronic communications between covered entities in order to enroll members, check eligibility, submit claims, remit claims, check claim status, pay premiums and submit request for authorizations and referrals as well as the mandated NCPDP D.O. standards for pharmacy claims. This paper will demonstrate ways a provider will test the 5010 HIPAA transaction standards through existing testing tools, best practices and collaborations that are already broadly recognized within the healthcare industry Preparing for 5010 Testing The HIPAA 5010 implementation involves substantial business and systems changes that require a significant amount of detailed planning, analysis and development. Initial analysis should include identification of stakeholders, current operations, business and financial impacts and outlining timelines for the project, implementation, and compliance. Create a list of business processes, systems and operations currently utilized for version 4010A1. Once this is accomplished, an inventory of the business and technical components for further analysis and evaluation can be completed. Include all systems that interface with identified business systems or third party applications that will be affected by the upgrade. Project planning and design will be developed based on the results of the analysis conducted. Include development of the implementation and test plans as well as project team responsibilities; identify potential obstacles as well as risks to the organization. Depending on the size of your organization, creating a steering committee or task force may or may not be appropriate to assist in keeping the project on target and to provide the guidance and leadership to make decisions. This committee could also be beneficial in coordinating resource allocations to the project teams. Establish communication protocols with all participants in the project, internally and externally. As part of the protocols, establish a pathway for communicating critical issues and outline the procedures for WEDI 5010 Testing Workgroup Page 6

7 corrective actions. Ongoing monitoring by the Project Manager or committee will ensure completion of tasks and provide feedback. These protocols will serve as a starting point for your organization as it moves forward with ICD- 10 implementation. During the analysis process, identify stakeholders and operations that will be affected by the implementation of Health Information Systems (HIS) or Practice Management Systems (PMS), financial and other systems, could be impacted by updates for the Review all current provider edits for 4010A1 and compare to 5010 requirements and determine changes needed. After identifying impacted systems and trading partners, collect contact information to assist in expediting next steps with trading partners to obtain information regarding expectations for updates and initiating 5010 testing. Coordination of hardware or software updates will be crucial in the success of your project. Upgrades for HIS/PMS systems are usually required first, before integrated software updates may be installed. Thorough testing should be conducted after each update, so that issues can be identified quickly and resolved. Verify how the upgrades affect current systems and determine if the updates will affect associated systems. Identify whether the updates will accommodate 5010 and D.O. transactions and if it will include acknowledgement of transactions 277CA and 999. Determine if you will be able to continue support of the 4010A1 while at the same time have the capability to submit 5010 transactions. Develop test plans and test scenarios for all systems, interfaces, transactions and reports. Review data and communicate with vendors and the project teams to make sure expected results are accurate and issues are resolved. Allow sufficient time to resolve issues with your vendor and re-test. Provide staff training as you migrate and implement each system or product. Trading Partner Testing Concept The concept of trading partner testing should be designed to validate each trading partners ability to meet technical compliance and performance processing standards and measure data integrity through the exchange. This testing should include connectivity, transmission schedules, data content, transaction volume, and security. Where allowed standard acknowledgments should be used for reporting the receipt of all supported 5010 transactions. Content Trading partner testing content should include test files that will generate positive and negative results for the applicable transaction standard. The resources and budgets allocated by trading partners will have a direct impact on the testing performed. Trading partners should discuss the impact of testing strategies that they mutually agree to adopt for example the use of de-identified or identifiable patient data. It is important to note that even two submitters using the same clearinghouse may have different data content (e.g., different specialties) thus resulting in different testing outcomes. Trading partners should ascertain whether both the formatting and the data content requirements for each submitter have been met. For example, a provider submitting direct to a payer demonstrates that they can successfully transmit claims for office visits to the payer but should not automatically assume that they can correctly send ambulance claims to the payer, even though the same software is used. WEDI 5010 Testing Workgroup Page 7

8 Connectivity Connectivity requirements for trading partner testing should include the key components: o o o o o o o o Pre-ERRATA or ERRATA versions of the transaction standards (updates to the 5010 transaction standards know as ERRATA were added to the rule on October 13, 2010). Payers are implementing the updates at different times so it is necessary to confirm whether they are ready to test with ERRATA. See Page 16 for further explanation. Testing locations File naming conventions; including the testing of multiple files Sender/receiver information Internal/External Architecture connectivity Internet Intranet Cross Platform (such as mainframe to client/server connectivity) Mutually agreed upon transaction volume Expected acknowledgement/status transactions Expected turnaround on results Test Environments Internal Internal testing environments should parallel the production environment for sending and receiving transaction standards. Audit-trails and exception monitoring should be considered for each trading partners test environment. The goal of internal testing is to guarantee that the business requirements meet the functionality of what has been coded. For each transaction, this equates to how each TR3 defines minimal compliance. Internal Payer or Clearinghouse External testing will need to consist of many trading partners working with each other and each having their own set of challenges and associated risks both internally and externally. A solid communication plan will assist in mitigating risks associated with testing. It is recommended that best practice should be used for evaluating actual results against expected results with various test cases. Outbound testing should include connectivity, transmission schedules, volume, data values, and security, coordination of benefits and acknowledgment and reporting for both sending and receiving all supported 5010 transactions standards. Trading partners will need to include testing various versions of the transaction standards. Provider Healthcare providers should: Test all applicable transaction standards with their practice management systems and/or hospital information systems. Include samplings of claims for all payers that represent a significant impact to their revenue cycle performance. Consider sending specific data values that may impact their operations, (e.g., their billing provider information, unique billing scenarios, new NPI information and varying zip code information). WEDI 5010 Testing Workgroup Page 8

9 Review ancillary applications that use the inbound transaction standards to confirm that all data values are captured and displayed. Documentation of results and issues should be tracked in support of the healthcare providers readiness for production. Testing from claim submission of 837s to posting of 835s for the same claims (based on availability of payer processing). Revise per submissions. Once the provider has successfully completed testing, a single production test file submission should be followed through to adjudication to receipt and review of the remittance advice. If you are able to continue to submit 4010A1 s, continue to do so until you see the results of the 5010 production file. The results will determine your next step. Should you be unable to continue to submit 4010A1 s, you might consider delaying submitting further 5010 files until the results of the initial 5010 production file are reviewed and analyzed. If successful, the provider could then take the necessary steps to send files in production. Multiple Transaction Testing Where business processes involve the use of more than one transaction type, an attempt should be made to test the entire process. While many organizations may only be able to complete functional testing of edits, others will have the capability of testing multiple transactions to ensure paired or dependent transactions are working together correctly and that business activity will not be disrupted. Some examples of multiple transaction testing could be an eligibility response 271 that provides the expected results from the 270 inquiry; and also provides the subscriber data required on the 837 claim. Readiness Assessment Readiness should be clearly defined and agreed upon by each trading partner. Readiness must comply with the January 1, 2012 compliance date for all covered entities. Keep in mind that no trading partner can mandate production readiness prior to January 1, Early adoption between a provider and a payer that have a direct connection can be implemented upon mutual agreement. However, a clearinghouse acts as an intermediary between many partners that are at different levels of readiness. When submitting through a clearinghouse, again with a mutual agreement, a provider may opt to submit a 5010 for the early adoption ready payers and a parallel 4010A1 for the payers not ready for Internal Readiness (level 1 compliance) Analysis has been performed, requirements have been gathered and processes have been created and/or updated. The time has come to test whether activities to this point have fulfilled the goal of creating and receiving compliant 5010 transactions. Any internal issues can be addressed before exchanging files with outside entities. Providers need to consider documenting at a high level their plan for the internal readiness to share with their trading partners. Per HHS timeline guidance, Level 1 compliance should have been completed by December 31, 2010 and is a prerequisite to Level 2 compliance. Trading Partner Testing Readiness (level 2 compliance) Creation and receipt of compliant 5010 transactions have been tested internally and the time has come to test whether activities to this point have fulfilled the goal of exchanging these files with outside entities and processing WEDI 5010 Testing Workgroup Page 9

10 them successfully. Providers may submit directly to some payers and use a clearinghouse or billing agent for all other payers. Keep in mind coordination of testing will be a crucial element if you are not using a clearinghouse or billing agent and communications will be essential to identify and resolve issues identified during the Level 2 test phase. Providers should document their timelines for testing with trading partners and the results of those tests to demonstrate compliance. When testing results satisfy the requirements for readiness, clearinghouses and their trading partners may decide to move transactions to production prior to January 1, Because the number of trading partners can be high for a clearinghouse, they may choose to prioritize testing with trading partners. The number of trading partners and the number of transactions with each partner increase the overall amount of testing that could be done. Clearinghouses may also want to coordinate which transactions are tested and when Level 1 compliance must be completed before Level 2 compliance may begin. Level 2 compliance must be completed by January X12N version comparison testing (between 4010 production vs test) is a critical component. This involves comparing the current production 4010 output file to the 5010 output file and using the results to identify and correct or determine as valid any differences or issues with content, syntax, translation or validation. Syntax Syntax and Content validation are essential for checking the software commands, code and content in the software application. Content validation should be used to verify that a document conforms to the requirements of the defined structure as well as the format. Some requirements listed in the guides, such as use of an external code set, are not considered part of syntax and content validation. External code sets are lists of codes such as diagnosis codes, zip codes, etc. that are used in specified locations in the standard. Invalid external code set values that are syntactically valid should be accepted in the front end validation processing. For example, invalid external codes in claims may result in a claim rejection reported in claim status reporting or result in a claim denial. Translation Each trading partner will need to assess the translation of all applicable transaction standards inbound and outbound. Audit-trails of translations should be reviewed syntactically and for data content. Processing performance should be compared to production environment. Validation Validation should be defined by each trading partner. Validation can encompass structural compliance and business compliance at various levels. The level of compliance will drive decisions regarding additional testing or early production monitoring. Failure to understand the level of validation may result in processing delays or a negative impact to revenue cycle performance for the healthcare provider. Challenges Different readiness timeframes among trading partners and systems to include clearinghouses and host systems. Different timeframes for ERRATA implementation Issues identified during 5010 file testing. File modification and re-testing procedures must follow. WEDI 5010 Testing Workgroup Page 10

11 X12N version comparison testing may include identification and corrections of any differences or issues with content, syntax, translation or validation. Recommendations Develop test use cases and set up test applications for test scenarios Refer to the 5010 Test Scenarios document that can be accessed via the WEDI.org website Develop a tracking tool for coordinating payer testing - multiple dates, partners and transactions not only for testing but for moving into production Document test results to demonstrate compliance Communicate/collaborate internally/externally on testing requirements, issue reporting and resolution Review the 5010 Level II Readiness Spreadsheet via the WEDI.org website Trading Partner Requirements 5010 testing strategies must consider inconsistencies in EDI business requirements across multiple trading partners. For example, many EDI gateway contractors require a separate submitter ID for each payer or contractor ID supported by the gateway. Some contractors still operate on legacy platforms which are unable to support advanced file translation, while others have migrated to enterprise architecture. New state or federal legislation may also impact business or technical submission requirements. Clearinghouses must develop business rules for conducting inbound testing from providers, billing services, hospitals, labs, Practice Management Systems (PMS) and Health Information Systems (HIS) vendors and other clearinghouses, in addition to understanding the business rules for testing outbound transactions with health plans, contractors, and other intermediaries. Many of the same rules may be applicable to inbound or outbound scenarios, depending on the business requirements of the sending and receiving entities. Providers may not have systems sophisticated enough to accomplish this in their testing environment, but should keep these elements in mind if testing direct with payers. Following is a list of suggested questions that trading partners should ask when developing a 5010 test plan: Will new trading partner agreements, authorizations, enrollments, or identifiers be required before submitting 5010 test transactions? Will separate test files be required for each submitter ID maintained by the submitting entity? Will the receiving entity support parallel production 4010 and 5010 systems prior to January 1, 2012? o If so, will a separate submitter ID be required for 5010 transactions? o Will a separate electronic communications connection be required for submission to the 5010 system? How many test claims can be submitted per batch to the payer? What is an acceptable pass rate? Will the trading partners research rejected transactions and then allow submitter to re-test? What acknowledgement and reporting options/formats are available from the receiving entity? Administrative Agreements WEDI 5010 Testing Workgroup Page 11

12 Before submitting 5010 test transactions, some EDI gateway contractors are requiring trading partners to sign new EDI agreements, or trading partner authorizations. Provider enrollment agreements may also be required before a specific provider s claims may be included in test transactions. A successful testing plan will ensure that all appropriate agreements have been completed and approved prior to the transmission of test files. Multiple Submitter IDs For 4010 transactions, payer-specific submitter IDs may be required by some EDI gateway contractors. This may result in multiple submitter IDs for a single submitting entity. Trading partners that will exchange 5010 transactions must agree on a model which will incorporate testing of all applicable IDs. In some cases, contractors may accept single submissions of test files per trading partner, while others may require separate testing for each ID maintained by the submitting entity vs IDs and Dual Submission For 5010 transactions, some payers or contractors may require that trading partners obtain a new submitter ID, which will be maintained separately from 4010 IDs. Others may support a true dual submission system, which will allow a trading partner to submit transactions in both 4010 and 5010 formats from a single submission source. This strategy assumes that both the sending and receiving entities can support 4010 and 5010 formatted transactions concurrently. Migration strategies should include dual submission testing where possible, and may incorporate a phased transition from 4010 to Dual submission may add an additional layer of recurring operational cost and complexity as entities in this model may be required to support additional identifiers, communications, file submissions, tracking, etc., during the transition period. The dual submission strategy is only permitted until January 1, 2012 at which time full 5010 compliance is required. Communications Protocols Submitting and receiving entities migrating from 4010 to 5010 in a cutover manner will likely be able to reuse existing connectivity and simply begin sending or receiving transactions in the 5010 format. Some receiving entities may support dual submission over the same communication method and accept both 4010 and 5010 formatted claims during the transition period up to January 1, Some receiving entities may require a submitting entity to establish a separate connection for the submission of 5010 transactions. This scenario will require a separate routing strategy as well as separate communications credentialing for connecting to the 5010 system. Additional connectivity testing must be included in the testing strategy and may impact the project timeline of the submitting entity. Legacy Platforms Some payers continue to operate on legacy system platforms which may be unable to support advanced translation of files. Submitters may be required to develop special routing, batching, and other programming to accommodate the legacy system limitations. Each modification should be tested to mitigate the potential risk of lost data content or worse, lost files, and verify the consistent return of all respective acknowledgements. Payers operating on legacy platforms may also choose to delay testing, pending migration to enterprise systems. While this is not advised, project timelines of submitting entities should include a contingency plan for payer testing during 4Q Additional Testing Requirements WEDI 5010 Testing Workgroup Page 12

13 A single test file is often insufficient to meet a receiving entity s business requirements for approval. Multiple files containing transactions which are comprised of a typical day s submissions are often required. Some receiver s may require as few as 25 test claims, while others may require thousands to satisfy established testing protocols. While an acceptable pass rate is desired, rejected transactions should also be included to identify whether those rejections will occur at a file level or transaction level. No testing cycle is complete without testing of acknowledgements and reports that will be returned by the receiver. These transactions should also be tested for consumption at the file and transaction level. While it is assumed that most trading partners will adopt and utilize the Version , 277CA acknowledgments and the 835 Health Care Payment and Advice, special programming may be required when a trading partner chooses to send responses in a proprietary format. Some entities may also support additional workflow reporting such as the 824 Application Reporting for Insurance, 277 Health Care Claim Request for Additional Information and 277 Health Care Claim Pending Status Information. Testing Parameters File Size Initial trading partner testing may include small test files which will exhaust specific positive and negative results, specialty claims and claims for specific payer requirements. However, prior to releasing a trading partner into the production environment each trading partner should have the ability to submit their typical production volume in the test environment. Live vs. dummy data de-identify/re-identify Trading partners need to consider the use of de-identified or dummy data when performing multiple transactions testing with trading partners. Use of dummy (i.e. John Jones) versus actual live content limits many trading partners in just how far they can invoke their validation rules. Most transaction syntax can be accomplished using dummy or de-identified data, however when value added business rules are in place for trading partners those rules may not be invoked if live content is not used. This dummy or de-identified data may also prevent the trading partner from being able to run the test through all of their internal processes. Percentage of clean claims To minimize revenue cycle disruption for Providers, each trading partner should establish an agreed upon rate of acceptance of 5010 transactions. For many clearinghouses this will be based on the current trading partner production experience with 4010 claims. For example, if the current acceptance rate is in 91 percent range for 4010 then the 5010 acceptance rate should also be within that range. WEDI 5010 Testing Workgroup Page 13

14 Number of clean files After achieving the acceptance rate for clean claims, trading partners should exchange several files containing typical production claim specialty types and volume before releasing the trading partner as production ready. Use of third party X12N validation services (multiple phases) Phase 1 (third party X12N 5010 testing and certification) is recommended but may not be required by every trading partner during initial testing. Healthcare Providers should contact their trading partners to determine if this is a requirement for 5010 testing. Phase 2 (Clearinghouse testing) which may or may not include third party validates and business or payer specific rules applied within the clearinghouse environment. Phase 3 (Multiple transaction testing) where available with payers and other trading partners. Challenges Acceptance rates may vary by trading partner Real time vs. batch transactions Test environments differ by payer Methods of test file transmission networks differ (dial-up, Internet, etc.) Some trading partners may have limitations to test file sizes (unable to send production volumes within their testing platform) Trading partners may have differing definitions of what constitutes a clean claim Inconsistencies between payers Time delays for resolution of issues identified during testing Multiple transactions testing with payers will be limited unless the payer supports a highly available production mirror multiple transaction testing and certification environment. 835 transaction testing Differences in approval process and production migration requirements Recommendations Identify individual trading partner requirements as early in the testing process as possible Develop communication strategies with trading partners Agree on issue identification and resolution processes with time to re-test after programming changes Migration to production upon approval Plan for dual systems to handle 4010 and 5010 formats Monitor all transaction processes post migration to assure accuracy in: 1. Claims processing 2. Timely claim adjudication 3. Return of eligibility/benefit information 4. Accuracy in claims status inquiries responses 5. Accurate payment remittance advices and funds transfers Development and Use of Test Scenarios The scenarios listed in the associated WEDI document entitled Key Testing Scenarios Issue Brief and Spreadsheet are samples, and may not be all inclusive. The document may be accessed via the website. It WEDI 5010 Testing Workgroup Page 14

15 is important to read the front matter, understand the situational rules and TR3 notes, and build your testing scenarios for 5010 changes based on your business applications and the role you are playing in the transaction workflow. Final Rule vs. ERRATA 837I (A1 vs. A2) On October 13, 2010 HHS published a notification of maintenance changes to the Electronic Data Transaction Standards adopted under HIPAA, to all HIPAA covered entities, vendors and third party billers that the ERRATA approved for publication by X12 in July 2010 are now to be included in the implementation of Not all EDI transactions were impacted. What is the ERRATA? The Errata is the term used by ASC X12 for any corrections to the original version of the EDI transaction sets. Some changes were recently introduced in October, 2010 but not all EDI transactions were impacted. If your vendor already upgraded your practice management system, ask your vendor when the Errata changes will be installed. If they have not yet upgraded your system, make sure that your upgrade includes the latest Errata changes. Application of rules from 4010 to 5010 One of the clearinghouse functions today is to be able to parse transactions, and perform software verification of structure and data content based on transaction type. Transactions from large providers may include institutional and professional claims for multiple payers which may be at different levels of readiness. Clearinghouses may be required to parse inbound transactions into separate outbound transactions in order to support submissions to different receiving platforms. Many clearinghouses also support the receipt of non-compliant formats from providers unable to submit 4010 or 5010 transactions. Providers not using compliant Practice Management Systems (PMS) often rely on clearinghouses to convert their transactions to a HIPAA compliant format. Clearinghouses must thoroughly test with their provider partners to ensure that transactions are properly converted to the format supported by the health plan, and recoded to the format supported by the provider s PMS. Special programming may be necessary to handle added or deleted transaction codes, loops, segments and or situational rules. Similarly, clearinghouses must test the data that might be lost when a 5010 file submitted to a payer is translated to 4010 by a trading partner, and vice versa. Integration testing of inbound with outbound transactions should include: 5010 Element Changes (spreadsheet) Subscriber across transactions Billing Provider/Pay-to Loops Coordination of Benefits Claim Scenarios o Office o Home o Independent Laboratory o Inpatient WEDI 5010 Testing Workgroup Page 15

16 o o o o o Outpatient Ambulance Chiropractic DME/Oxygen Therapy Anesthesia Worker s Comp/Property & Casualty Testing all appropriate scenarios for transactions you normally exchange Transactions should also incorporate conditions that produce negative and positive outcomes as well as situational or gray areas. Testing of rejected transactions is necessary for the proper coding of parsing routines as well as identification of situations which may require additional coding of provider inbound transactions to resolve variances. Recommendations Remember that one claim may encompass multiple scenarios 1. Clearinghouse testing with payers and providers in different stages of readiness. Address possible variances between testing and production environment. Identify/consider new scenarios that could be automated when testing. An example would be how you simulate adjudication of an 835 in a testing environment, or validate the remittance advice output based on the submission of claim type and version. Status and Remittance Code Validation and Version Tracking Dual Testing Submission Workflow Testing scenarios based on content workflow > 5010 added or deleted transaction codes, Loops, segments and or situational rules. > Incorporate conditions that produce negative and positive outcomes as well as situational areas. 2. Large provider organizations may include institutional and physician claims in the same batch to multiple trading partners. Determine transactions that may be pertinent to the entire entity and those transactions that may require separate testing. 3. Payers that publish companion guides or Technical Report Type 3 documents set forth guidance for transactions in the 5010 format and include: Transaction instructions System availability Establish how trading partners shall connect to the Payers gateway Provide resource and contact information for the coordination of testing WEDI 5010 Testing Workgroup Page 16

17 Establish timelines for testing Provide information for the number and types of claims that can be submitted for testing Establish HIPAA validation levels for testing Companion guides should be provided for each type of transaction in the 5010 format and subsequent versions. Testing Lifecycle Single Clearinghouse 837: This process flow below is designed to show the typical end to end flow for an 837 transaction through acknowledgement and 835 deliveries when there is only one clearinghouse involved in the processing/routing of the claim. Acknowledgement from the clearinghouse may be in various formats depending on Submitter preference and capabilities. Single Clearinghouse 837 Provider/Billing Service Clearinghouse Payer Provider creates claim (various formats) Various formats Provider submits claim to clearinghouse Various formats Clearinghouse runs internal processes on claim 837 Clearinghouse submits claim to payer 837 Provider receives and reviews acknowledgments Various formats Clearinghouse sends acks to provider Various formats Acknowledgments processed Various formats Payer submits acks and claim status updates to clearinghouse Payer runs internal processes Provider receives and reviews remittance Various formats Clearinghouse sends 835/ remittance to provider Various formats 835 processed 835 Payer submits 835 to clearinghouse Testing With Your Software Vendor Assess vendor readiness Identify if 5010 updates are available for all impacted software and if not, identify the timeline for product updates. If the vendor is using a staggered approach for updates, identify which products will be implemented first and how associated product updates will then be implemented. Identify the timeline when you will actually be capable of WEDI 5010 Testing Workgroup Page 17

18 supporting all 5010 transaction versions. If the updates will not be completed by the January 1, 2012 compliance date, what are the contingency plans? Which transactions to test first From a provider s perspective, assuming you follow this cycle, the first transaction that you would test would be eligibility query (270) and its response (271) and then the claim (837) followed by the claim status request (276) and its response (277). The final step is the remittance advice (835). However, contact your trading partners to find out the availability of each transaction for testing. Some payers and/or vendors may be ready to test certain transactions before others, such as claims before eligibility. What to test There are many ways to make this assessment. One way is to assess your payer mix. You have your government (Medicare, Medicaid, worker s compensation and others) and commercial payers. One option is to assess your payer mix by identifying the one that generates your most revenue. Here is an illustration: Clearinghouse Health Plan A Health Plan B Health Plan C $$$$ $$$ $$ Health Plan X $ In other words, if most of your weekly revenue comes from Health Plan A, your testing emphasis should be with Health Plan A first followed by the next plan that generates the most revenue. This does not imply that you do not test with others, but testing with the one that impacts you the most financially makes sense. The top plan will also most likely cover testing scenarios that will be visible with the smallest revenue generating plan. Another approach may be to identify variation of different reimbursement and claim types that generate the most payment: 1. Institutional claims (inpatient, ambulatory) 2. Surgical 3. Dialysis 4. PPS versus non-pps 5. Psychiatric 6. Rehab 7. Hospice 8. Home Health Care 9. Anesthesia Irrespective of the approach, your goal is to minimize impact to your revenue. WEDI 5010 Testing Workgroup Page 18

19 Testing Workflow Reporting and Feedback Plan Testing should be performed on all supported 5010 transactions and test scenarios, data and results should be reviewed and communicated with all involved in data submission, acceptance or processing to make sure expected results are accurate and issues are resolved. Reporting capabilities need to be in place to record and track results that will validate testing activities, provide verification of the 5010 enhancements and serve as the platform to promote version 5010 into production. Moving to Production Once testing is complete and certified/approved between trading partners, ongoing review and monitoring of transactions must continue for all providers submitting transactions through the clearinghouse. Providers and clearinghouses will monitor: Claim processing Claim adjudication Return of requested benefit information Accurate claim status inquiries Accurate payment remittance advice Similar percentage of clean claims The system and data changes in version 5010 alone will not resolve many issues faced with version Therefore, it will be extremely necessary to continue assessing how these changes affect the business operations and looking for opportunities that will enhance operational workflow and productivity. The plan for dual submission processing is to handle transactions in both the 4010 and 5010 formats. Identify current environments and architecture Transaction migration and testing must be coordinated to manage the business and technical transition. Compliance monitoring on all transactions, both inbound and outbound must continue until all trading partner migrations and implementations are complete. Create enhanced reporting for system monitoring and transaction tracking. Coordinate with all Trading Partners on migration planning, communication planning and test planning activities. WEDI 5010 Testing Workgroup Page 19

20 Prepare a contingency plan that outlines the approach that will be taken should the 5010 Payer testing be delayed, should additional programming be necessary based on payer requirements, or should additional system upgrades be necessary. Post Implementation Review Once implemented, entities will need to perform a post implementation review and monitor the success rate of transactions for: Claim processing Claim adjudication Accurate return of requested benefit information Accurate claim status inquiries Accurate payment remittance advice and funds transfers Contingency planning Good or bad, all stakeholders must recognize that we will hit a few bumps on the road. Many health plans will establish a testing environment that will be utilized solely for 5010 testing. Others who are limited in resources and funding may opt to use an existing test environment that may not totally mimic their production environment. Consequently, the results that you may see during the 5010 testing phase may not be the same results you can expect in the production environment once you go live on Another note is that 100% testing is preferred but not always practical given a project as large and complex as It is inconceivable to expect all stakeholders to test every inch of their process. Therefore, a solid backup plan must not be optional but a must. But to establish a backup plan, you must recognize events that may be at risk. Overall, the most significant impact may be your revenue. Here are some thoughts to generate some questions: 1. What if certain claims previously accepted are now rejected or denied? 2. Can I afford a drop in revenue from the largest health plan that generates the most revenue for my office? 3. PMS system multiple updates may be necessary. Timelines may not coincide with compliance timelines. Here are some potential solutions: Payer portals for Direct Data Entry (DDE) submission of claims Clearinghouse conversions 4010 to 5010 Establish a loan during the first couple of months after go-live to sustain operations Assess if you need to augment staff (full-time, contractor, etc) in case you need to drop claims to paper or support increases in denial management Assess if health plan can grant you upfront payment WEDI 5010 Testing Workgroup Page 20

21 Conclusions We would like to caution Providers that dropping from electronic submissions to paper should not be considered as a viable option to avoid updating systems for 5010 compliance. There are many options in the industry available to Providers that should be investigated before a radical decision to drop to paper. Assess your environment for other non-electronic transactions that can be supported with these transaction standards. Providers are encouraged to contact vendors and their clearinghouse before making a decision to drop to paper. It is important to read the front matter, understand the situational rules and TR3 notes, and build your testing scenarios for 5010 changes based on your business applications and the role you are playing in the industry. Organizations will need to develop control plans for compliance auditing and monitoring. It is necessary to continue assessing how these changes affect current business operations. Acknowledgements WEDI 5010 Testing Workgroup Co-Chairs Mary Rita Hyland, The SSI Group, Inc. Nancy Sanchez-Caro, Montefiore Medical Center The co-chairs wish to express their sincerest thanks and appreciation to the members of the 5010 Testing Workgroup who articipated in the creation of this document. Appendix A Definitions 1. Claim a submission of health care data in an industry standard claim format such as ANSI 837 or any successor forms or formats used for the submission of claims. 2. Clearinghouse a public or private entity that does either of the following (Entities, including but not limited to, billing services, re-pricing companies, community health management information systems or community health information systems, and value-added networks and switches are health care clearinghouses if they perform these functions): 1) Processes or facilitates the processing of information received from another entity in a nonstandard format or containing nonstandard data content into standard data elements or a standard transaction; 2) Receives a standard transaction from another entity and processes or facilitates the processing of information into nonstandard format or nonstandard data content for a receiving entity. 3. Companion Guides - the document a Health Plan provides a trading partner (e.g., a clearinghouse or provider who submits transactions direct to a payer) that sets forth, with respect to Transactions in the WEDI 5010 Testing Workgroup Page 21

22 5010 format data specifications, system availability, how trading partner shall connect to the Health Plan s gateway, contact information and HIPAA validation levels. Companion guides documents should be provided for each type of Transaction in the 5010 format and subsequent versions. 4. ERRATA is the term used by ASC X12 for any corrections to the original version of the EDI transaction implementation guides (TR3). 5. Functional Acknowledgment an electronic receipt which informs a sender: That the receiver has successfully received a Transaction. Advises whether a transaction has been accepted or rejected by the Payer May include details on errors 6. Go-Live Date the date on which the trading partner first provides transmission of Transactions for production, not test, purposes. 7. Health Plan an entity that assumes the risk of paying for medical treatments, i.e. uninsured patient, self-insured employer, payer, or HMO. 8. Key Performance Indicator a mutually established minimal performance service level between the Clearinghouse and the Health Plan relating to how the Trading Partner supports Submitters exchanging Transactions with the Health Plan through the Clearinghouse. 9. Provider physicians and other healthcare practitioners who have been approved to offer their services to patients. 10. Testing: Acceptance Testing end users perform acceptance tests to assess the overall functionality and interoperability of an application. Balance Testing is testing the transaction for balanced field totals, record or segment counts, financial balancing of claims or remittance advice, and balancing of summary fields. Code Set Testing testing for valid Implementation Guide-specific code set values. Integrity Testing involves testing for valid segments, segment order, element attributes, testing for numeric values in numeric data elements, validation of X12 syntax and compliance with X12 rules. Internal Testing testing within the organization any system or programming changes before deploying. External Testing testing externally with trading partners. Trading partners must work with each other and have defined process steps as well as analysis to determine system interoperability prior to deploying. Functional Testing tests to assess the operability of a program against predefined requirements. These tests include black box tests, which assess the operational functionality of a feature against predefined expectations, or white box tests, which assess the functionality of a feature s code. Parallel Testing tests to compare the output of a new application against the original application. Performance Testing software release updates are tested to determine the performance of the software meets new requirements. Product Types/Types of Service Testing also referred to as Line-of-business testing, is specialized testing required by certain healthcare specialties. WEDI 5010 Testing Workgroup Page 22