On Track with TCS Testing:
Critical Steps to the Compliance Deadline

By John Yates and Randa Upham, Principals, Phoenix Health Systems

Congratulations! April was a great month full of many accomplishments. April 14 came and you successfully implemented the requirements of the HIPAA Privacy regulations. April 15 came and you successfully filed your tax return (even taking into account all the overtime you worked leading up to the Privacy deadline). And, April 16 came and you began testing of your solutions for implementation of the Transactions and Code Sets standards (TCS), right?

Just to refresh your memory, let's look back at the sequence of events on the TCS compliance timeline. In March 2002, in the Administrative Simplification Compliance Act (ASCA), Congress authorized a one year extension (to October 16, 2003) for implementing the TCS requirements for those covered entities required to comply in 2002. Back in October 2002, everyone was rushing to file the ASCA compliance extension forms by October 15. But one very important provision of that extension request remains as blurry today as it did last fall. Section D of the ASCA compliance extension requires that you, the provider and requestor of the extension, begin "testing" not later than April 16, 2003. The problem is, "testing" was never defined in law.

For those of you in the information technology industry, this lack of definition is more than an academic discussion. Testing requires discipline, cooperation, and resources. What is the meaning of "testing" in Section D (questions 21 through 25) of the extension form? Why is this important now? Take a minute and visit the CMS web site. The first thing you will see is "The testing deadline (April 16, 2003) for electronic transactions and code sets has passed." Remember that when you filed your extension request, you certified your organization would be in "testing mode" by April 16, 2003.

There has been a significant amount of industry press lately indicating that the April deadline, as well as the general compliance deadline of October 16, 2003, may be in jeopardy. For example, the Workgroup for Electronic Data Interchange (WEDI) in their April 15 letter indicated "WEDI believes that a substantial number of covered entities are not sufficiently far along to achieve compliance with HIPAA Transactions and Code Sets (TCS) standards by the October 16, 2003 deadline as required...". Based on the Phoenix Spring 2003 Healthcare Industry HIPAA Survey, only 50% of providers were testing internally as of April 16, and only 39% of providers were testing externally with trading partners. Maybe more shocking is that only 79% of respondents of the survey reported that they expected to be able to conduct external testing by October 2003.

All that said, the regulation remains the same. Compliance with the TCS standards is required by October 16, 2003 and you are supposed to have started testing this past April. If you haven't started your testing process, where do you now begin? You begin by immediately developing a Testing Strategy and Testing Plan. The major steps to incorporate into the testing process include:

1. Assign responsibility for testing, which includes:

• Designation of the Project Manager to lead the effort, including development of the plan and managing the testing process.
• Identification of the testing team. Members should have a strong understanding of business operations and transaction processing technology.
  
  

2. Speak to your external partners, including those for your software applications, your payers and any clearinghouses.

• There are huge risks associated with the IT applications that support your TCS processing. Be sure you are in close communication with your application vendors about:
  • Delivery dates for upgrades and new products that support the TCS standard formats
  • Availability of implementation and transformation support
  • Results of any testing on new versions and supporting documentation
• Co-ordinate with Trading Partners to:
  • Complete Trading Partner registration
  • Obtain companion guides for each payer
  • Review administrative transmission procedures (obtain transmission diagrams for each partner)
  • Establish test schedules
• Be proactive with clearinghouses - require the following:
  • Use of your data for testing with the payer
  • Sequencing of transactions according to your implementation order
  • Commitment to actual implementation date
  • Support for testing activities
    
    
3. Develop a broad set of test scenarios, cases, and scripts.
• Include scripts to test transaction format to determine if field lengths, placement, etc., are in their correct places according to the Implementation Guides.
• Include scripts to test data content (data elements) to determine if all required data elements listed in the Implementation Guides are being captured and transmitted.
• Create testing files and levels for each revenue source or payer for your organization.
• Use "live data" or "live scenarios" that reflect your business operations and requirements.
• Remember, it is likely that your application vendors will be installing code and systems that are substantially re-written. Plan to do complete system testing, not just incremental testing of the new data fields.
  
  
4. Be sure that all system changes (vendors, clearinghouses, and any internal custom code requiring remediation) are scheduled and incorporated into the test plan.
5. Determine your transaction certification strategy and contact the appropriate vendors well in advance to inform them of your plan.
6. Obtain specific information from your trading partners about their testing processes and procedures. Be sure to incorporate those parameters into your test plan.
• Obtain a copy of their test plans - for both generic testing and certification on their systems.
• Obtain the plan they will actually use for your specific implementation.
• Be sure that testing with external partners includes end-to-end testing (inbound and outbound).
• Ensure that appropriate elements of Trading Partner Agreements related to transmission/creation of transactions have been considered in your testing program.
  
  
7. Make a realistic assessment of the resources needed to initiate the test plan.
• Note that testing is never easy as it requires many of your most valuable resources to work double duty. Consider a reward system to compensate your team for this extra effort.
• Consider bringing in temporary resources to fill the gaps in your currently available resources.
  
  
8. Incorporate the major elements of your Transaction Contingency Plan into your test plan.
• Contingency Planning is often included in discussions about HIPAA Security but it should be remembered that Contingency Planning is equally applicable to Transactions and Code Sets.
• Ensure that your testing schedule supports the October deadline for compliance. The schedule must include adequate time for error identification and remediation.
• Remember that solutions to identified errors will often be a mix of system remediation and business process adjustment.
  
  
9. Document everything.
• Maintain a record of your entire testing process from planning to final sign-off.
• All documentation generated from the testing program, as well as the actual test results, should be maintained in a project file and integrated into your overall HIPAA compliance documentation.

Is it too late to get started? Technically, yes. You should have already begun testing, as required under ASCA. For many covered entities, the reality is they must get started now if they have not begun the testing process. Do not wait for your vendor or clearinghouse to determine your testing approach - remember, you are the covered entity responsible for compliance and it was you who signed and certified the ASCA Compliance Extension Form back in October. Remember, it is your organization that must achieve TCS compliance in only four months...and most important, it is your organization that will lose revenues if your submitted claims cannot be paid!

John Yates, Principal, directs strategic planning and HIT consulting engagements for Phoenix Health Systems. John holds Masters degrees in Information and Telecommunication Systems, Business Law, and Business Administration, and is an adjunct professor at Johns Hopkins University Graduate School of Business/Technology. Randa Upham, M.A., Principal, is in charge of Program Development at Phoenix Health Systems, and oversees Phoenix' e-learning and other educational services.

Go to TOP