1310 G Street, N.W. Washington, D.C. 20005 202.626.4780 Fax 202.626.4833 |
TESTIMONY
Before the
NATIONAL COMMITTEE ON VITAL AND HEALTH STATISTICS
SUBCOMMITTEE ON STANDARDS AND SECURITY
On
Accredited Standards Committee X12 Version 005010 and National Council
for Prescription Drug Programs Version D.0. Implementation
Presented by:
Dwight Law, IT Director – Application Services
Blue Shield of California
On behalf of the Blue Cross and Blue Shield Association
July 31, 2007
TESTIMONY
Opening Statement
Good morning. My name is Dwight Law and I am the IT Director for Application Services for Blue Shield of California. Blue Shield of California (BSCA) is a not-for-profit health plan covering 3.2 million members in California. I am testifying on behalf of the Blue Cross and Blue Shield Association (BCBSA). The Blue Cross and Blue Shield Association is comprised of 39 independent, community-based and locally operated Blue Cross and Blue Shield (BCBS) companies that collectively provide health care coverage to more than 98 million Americans.
On behalf of the Blue Cross and Blue Shield Association, I would like to thank you for the opportunity to offer our comments on the subject of adoption and implementation of the Accredited Standards Committee X12 version 005010 (ANSI 005010 or simply 005010) standard transaction suite, as anticipated as the next HIPAA EDI transaction rule and the National Council for Prescription Drug Programs version D.0. My testimony – based on the experiences of other Blue Cross and Blue Shield Plans (“Plans”) as well as my own company – will address 005010 from the perspectives of background information, and the importance of an appropriate, efficient implementation adoption period.
I would like to acknowledge the outstanding work NCPDP has done to establish a standard that is flexible and allows plans and pharmacy benefit managers to decide how to use the business information they have contained within the layouts and fields created. However, since a majority of the Blues health plans rely on business associates to manage their pharmacy programs, my testimony will focus on 005010 and the four critical elements that need to be considered when preparing the rule.
Main Points
- First, keep in mind that HIPAA must be put in the context of where we are as an industry and what challenges we can expect in the next few years. Health plans have many initiatives that require additional staff and considerable funding. Competing with HIPAA are Self Service projects, Consumer Directed Products and Legacy System replacements. For instance, BSCA’s IT systems are undergoing a major overhaul to replace our core legacy systems. The window for implementing these changes is short as the workforce knowledgeable about how to transition process and procedures to these new systems is nearing retirement. Our society/IT has to react to the impact the retiring “Baby Boomers” will have on implementing technology in the next three to five years. Health care, never a leading edge industry, is more acutely sensitive to these demographic changes. In addition to these projects, there are a wave of interoperability initiatives making its way through the Health Information Technology Standards Panel (HITSP) and the Department of Health and Human Services (HHS).
- Second, implementing the 005010 transactions is a “big deal” – not a simple update – that will demand at least a two-year time frame.
- Third, in implementing 005010, we need to incorporate “lessons learned” from 004010A1, namely the need for pilot testing and adequate time for rollout.
- Finally, version 005010 must be fully implemented before beginning to implement the system and business process changes resulting from the adoption of the ICD-10 code set. Any overlap would be disastrous for efficient adoption and ultimately result in delays and implementation issues for both rules.
The Broader Context
Many BCBS Plans are in the process of upgrading or replacing multiple legacy systems. My Plan, BSCA, is in the process of revamping our aging, COBOL and assembler based, circa 1970’s core systems. This project is expected to cost half a billion dollars and will take us into the next decade. This three to five year multi-phase uplift in our technology includes upgrading Internet capabilities by adding more self-service functions – an especially important consideration in light of the growing trend to consumerism and the development of new consumer-directed health products – and a business process redesign that will enable our system to be quicker and more flexible in implementing new products and services.
In addition, like many other BCBS Plans, ours has been harnessing information technology to improve the quality of care, specifically by identifying patients whose treatment is inconsistent with Clinical Practice Guidelines. To improve compliance with evidence-based clinical practice guidelines related to management of chronic diseases, we undertook an intervention which employed: 1) monthly computerized analysis of diverse but integrated medical and pharmacy claims data, using the patient as the unit of analysis; and 2) messages mailed to physicians regarding specific opportunities to improve quality of care in specific patients.
Finally, most health care organizations – payers and providers alike — lack significant staff dedicated to compliance or do not have IT or business reengineering resources in reserve capable of implementing multiple regulations as well as health care quality and operations needs. Strategic work – designed to benefit member care – could be hindered by implementing multiple rules simultaneously. The alternate is incorporating a consultant workforce; adding significant costs, which impacts administrative simplification and the financial savings HIPAA was designed to provide.
The Challenges of Implementing 005010
As an “upgrade,” it might seem that the transition to 005010 would be less complicated than the original adoption of the version 004010A1 transactions. However, to put the 005010 upgrade in perspective, the implementation of version 004010A1 turned out to be much more lengthy and complicated, and in some ways much less successful, than was originally envisioned. Similarly 834 usages are not at the level originally anticipated. Below highlights a chronology of important events.
- After CMS adopted the initial HIPAA transaction standards (version 004010) by final rule in August 2000, so many significant change requests were submitted to the Designated Standards Maintenance Organizations that CMS had to publish a “Modification Rule” in February 2003 to adopt modified transaction standards (version 004010A1).
- Pilot testing would have identified many issues ahead of time, and thus would have helped avoid the extensions and delays that plagued HIPAA. Because pilot testing was skipped, Congress had to extend the HIPAA compliance date by one year (from October 2002 to October 2003), and then CMS had to permit contingency operations (allowing providers to submit e.g. non-HIPAA compliant 837 transactions) through October 1, 2005.
- Medicare only ended the contingency period for non-compliant electronic remittance advices under the HIPAA transaction and code sets (TCS) regulation on October 1, 2006. And Medicare still has a contingency plan in place for the 270/271 transactions.
- With the exception of the 837 claims transaction, the other electronic HIPAA transactions –especially the 200-series real time transactions – are not in high use by providers. When Congress passed HIPAA Administrative Simplification, providers not currently conducting electronic data interchange (EDI) were not required to move to EDI for their health care transactions. The original view was that because standardized electronic data interchange implementation would save providers time and money, providers would gravitate to the use of EDI to reap the benefits of administrative simplification. However, there have been unanticipated impediments such as the reluctance by IT system vendors to build the range of necessary software for the non-revenue-related HIPAA transactions (such as the eligibility transactions 270/271 and claim status notification 276/277).[1]
As a major upgrade, implementing 005010 will force Plans to go through all the phases of a major systems implementation: We will need time to complete systems and process analysis, application coding, conduct internal testing, training, and – of the utmost importance – conduct external testing with our trading partners.
Testing, especially with trading partners, was underestimated for 004010A1. Experience with 004010A1 has shown that testing and rollout to the Provider community, Submitters, Software Vendors and Clearinghouses is a key and lengthy component of implementation. For many entities, testing cannot be done until the entities’ vendors have done their testing and rollout. During the transition period, there will also be a need to support both 004010A1 and 005010 transactions. Based on experience with the original implementation of 004010 and then the subsequent 004010A1, this is a multi-year endeavor.
In addition to systems impacts, implementing 005010 will force plans and providers to evaluate and perhaps change many of their business processes. For example, we know that the 5010 has made significant changes in the 835 Claims Payment/Remittance transaction. This may impact not only payers’ workflows but also the provider’s accounts receivable processes. Also, consider that when the 004010 was implemented, HIPAA edits in the front-end and back-end payment systems were modified. With 005010, many of the edits will need to be revised. Therefore, a full business analysis of the data flow must be conducted – by payers and providers – to ensure that process workflows (e.g. front-end claims submissions; backend claims processing; and financial, medical and operations procedures) that require alteration are identified and properly incorporated into the implementation project plan. This not only adds additional requirements to the project, but also additional resources – human, time, and financial.
Moreover, Plans need time to determine the impact on Plans’ systems (not just transition but also new data element issues) and business associates (e.g. Medicare Crossover Claims, Blue Exchange, Federal Employees Program (FEP), and InterPlan Processing).
Given the history of 004010, and the extensive phases we will have to go through for 005010, and given all the other changes that are impacting health plans, we cannot see fully implementing 005010 in less than two years from the time a final rule is published and 005010 is adopted.
In addition, the Provider community has a number of other initiatives to address, such as interoperable Electronic Health Records (EHR). These projects also need to be considered in order to determine providers’ ability to also implement 005010 at the same time.
From a cost standpoint, it is hard to think about 005010 without also considering the transition to ICD-10, because one of the major reasons for instituting 005010 is to accept ICD-10-CM and ICD-10-PCS codes. We expect that moving to 005010 and then to ICD-10 will cost twice as much as the move to 004010A1. This is due to potential system overhaul needs to meet 005010 requirements and prepare for ICD-10, as well as other pending transactions such as Claims Attachments. These heavier costs entail complete system and business process reengineering, hardware upgrades, system applications modifications or new version upgrades and staff training. Bottom line: if the industry does not have adequate time to do 005010 right, not only will the costs of implementing 005010 be higher than they would otherwise be, the costs of implementing ICD-10 too will be considerably higher.
Two Major Lessons Learned from 004010A1
As the industry is learning with Claims Attachments – and as the 004010A1 experience shows – significant pilot testing is essential to ensure an appropriate and efficient implementation. Without adequate testing in advance of the rule implementation date, the industry could realize significant system issues. This translates to delays, implementation inefficiencies and, ultimately, contingencies.
Pilot testing helps to identify issues with the rule and related implementation guides prior to a majority rollout. Even a limited pilot, consisting of select transaction sets, could help payers, providers and clearinghouses adjust systems and workflows earlier in the process to help ensure cleaner claims processing and payment flows.
If conducted concurrently with the final rule development process it would also help to streamline the adoption process. Identifying business process and technical issues earlier in the transaction implementation lifecycle could mitigate the rework that ultimately resulted in the issuance of the 004010A1.
To do otherwise results in history repeating itself – hundreds of changes for the next standard format, contingencies and no administrative simplification. If the cornerstone of HIPAA is to help ensure administrative simplification for electronic standards, the baseline is to ensure that the transactions are implemented correctly and efficiently. Pilot testing will help make this difference.
In addition to pilot testing, it is imperative that the rule offer a realistic rollout time to avoid the need for contingency operations or extending compliance dates. The 004010A1 implementation resulted in an extension, then contingency. If timed appropriately, 005010 could be adopted in the timeline established by the final rule.
We recommend no less than the two year timeline provided for in the initial final HIPAA rule. This time is essential – especially if 1) pilot testing is incorporated into the final rule; and 2) the industry wants to implement without delays or contingencies.
No Overlap with ICD-10
Because of the magnitude of changes from version 004010A1 to version 005010, the Workgroup for Electronic Data Interchange (WEDI) previously stated that “This upgrade is too significant to be done in conjunction with ICD-10-CM and ICD-10-PCS conversion. . . Implementing the next version of the HIPAA Implementation Guides transaction standard (005010) should occur first.”
Two major issues underlie the need to implement 005010 before beginning ICD-10 systems changes:
- Cost and resource constraints—it will be costly to build systems and develop business processes to accept and process claims/transactions with 004010A1/ICD-9, 005010/ICD-9, and 005010/ICD-10.
- System design constraints—a basic tenet of systems design is implement and test one major systems change at a time. To reduce overall complexity, it is critical that the version 005010 transaction standards are stable before payers and providers begin analyzing and testing other significant changes. It will be very difficult to fully identify ICD-10 requirements until stakeholders can finalize the business process and system changes associated with implementing 005010.
Cost and Resource Constraints
- During the transition to 005010, plans will need to operate dual processing systems: one to process 004010A1 transactions for day-to-day operations, and one to process 005010 transactions for analysis and testing purposes.
- If plans simultaneously have to transition to ICD-10, then for some period they would have to handle 004010A1 transactions with ICD-9 for day-to-day operations, 005010 transactions with ICD-10, and 005010 transactions with ICD-9 (because not all providers will be ready to test ICD-10 at the same time). It will be very cumbersome to build systems and develop business processes to accept and process claims/transactions with 004010A1/ICD-9, 005010/ICD-9, and 005010/ICD-10. This creates substantial support challenges, which would be exacerbated by simultaneously layering the implementation of ICD-10 on top of 005010.
No companies in the industry possess a significant pool of staff dedicated to compliance and doubling previous efforts will stop much strategic work.
Moreover, doing 005010 and ICD-10 together creates exponential difficulty of doing either correctly. Companies only have a limited capacity for large change and even less capacity if the change is complex. It would require dual systems squared – dual for 004010A1/005010 and dual for ICD 9/ICD 10. Knowing when one is finished and how to transition oneself and one’s trading partners and providers/payers is too large a task for the industry to absorb at the same time.
System Design Constraints
Managing and limiting complexity and promoting clarity is fundamental to developing large software systems. Doing both ICD-10 and 005010 together would significantly increase complexity. Attempting to accomplish all of the complex programming and testing activities during the same timeframe would add unacceptable levels of complexity, risk and expense.
Consider the following example, just one small sample of the additional complexities created by overlapping 005010 and ICD-10. Suppose during claims adjudication of an ICD-9 claim, that an issue related to the procedure code or diagnosis code causes the claim to be stopped for manual research/intervention. If the 005010 version was fully implemented, three additional process steps might suffice; if 005010 and ICD-10 implementation were to overlap, then five process steps might be needed (a two-thirds increase in administrative effort).
It is critical that the version 005010 transaction standards are stable before payers and providers begin analyzing and testing other significant changes. Since ICD-10 is dependent on 005010, effective analysis and design could be impacted if done simeoultaneously. Ensuring that we have converted to 005010 and it mirrors the processing of 004010A1 allows us to validate that we have the infrastructure necessary and solid on which to base the significant business change of ICD- 10.
Finally, doing both ICD-10 and 005010 together would significantly increase testing complexity. Extensive 005010 testing will have to be done with all trading partners. This will involve coordinating 005010 deployments and monitoring interactions across the testing environments of multiple partners, which is both politically and technically unwieldy. If version 005010 and ICD-10 implementations were to overlap, and testing revealed issues in any of the dozens of internal systems and applications affected by 005010 and ICD-10, it would be extremely difficult to determine the source of the issue: preparation/implementation of 005010, or preparation/implementation of ICD-10. Attempting to accomplish all of these activities during the same timeframe would add unacceptable levels of complexity, risk and expense. Debugging becomes exponentially more complex, when multiple versions of multiple applications are simultaneously introduced as the testable object.
Conclusion
In conclusion, the primary concern of BCBS companies is to allow sufficient time for implementation, adoption, and stabilization of the 005010 standard transaction suite, for the following reasons:
- To avoid derailing the current phase of extensive IT system changes underway in many Plans;
- To allow adequate time to complete all the phases of implementing a large systems change, especially the finalization of vendor rollout and external testing with trading partners;
- To incorporate pilot testing and build in realistic rollout times to avoid costly and confusing contingency periods and delays, and
- To complete the implementation of the 005010 transactions suite prior to beginning the implementation of the ICD-10 coding structure.
I thank the subcommittee for the opportunity to discuss the 005010 implementation project and look forward to answering any questions you may have.
[1] National Committee on Vital and Health Statistics Letter to Secretary Leavitt. (June 22, 2006).