[This Transcript Is Unedited]
Wilbur Cohen Building
330 Independence Avenue, S.W.
Washington, D.C.
MR. REYNOLDS: I'd like to welcome you to the Standards and Security Subcommittee of the NCVHS, the National Committee on Vital and Health Statistics. I am Harry Reynolds, co-chair, along with Jeff Blair. The NCVHS serves as a statutory public advisory body to the Secretary of Health and Human Services.
Over the rest of today, we will be hearing testimony on the HIPAA transaction revisions version 5010. Our hearings are recorded and available on the Internet.
I will now begin introductions. I ask members of the subcommittee to mention any conflicts of interest they may have.
I will mention today, I don't believe it is a conflict of interest, but our company is a member of the Blue Cross Association, and the Association will be testifying today. Since CAQH Corps was mentioned yesterday even though it was just mentioned, I am also chair of that.
DR. BLAIR: I'm Jeff Blair from Loveless Clinic Foundation, co-chair of the subcommittee. I am not aware of any conflicts of interest.
MR. STEINDEL: Steve Steindel, Centers for Disease Control and Prevention, staff to the subcommittee and liaison to the full committee.
MS. GABEL: I'm Annette Gabel with MEDCO Health Solutions.
MR. LAW: I'm Dwight Law with Blue Shield of California.
MS. STAHLECKER: Chris Stahlecker with the Centers for Medicare and Medicaid Services.
DR. COHN: Simon Cohn. I am the Associate Executive Director with Kaiser Permanente. I am chair of the committee and a member of the subcommittee. I have no conflicts of interest.
DR. WARREN: Judy Warren, University of Kansas School of Nursing, member of the committee, member of the subcommittee, no conflicts.
MS. BUENNING: Denise Benning, CMS, lead staff to the subcommittee.
(Whereupon, the remainder of the introductions were performed.)
Agenda Item: 5010/D.0 Plans/Payor/PBM Panel
MR. REYNOLDS: Before we get started today, the committee would again like to thank everybody that set the stage yesterday for us. That was very rich and complete testimony about the status of 5010.
Today we will be hearing from a number of panels. The first one is the Plans/Payor/PBM panel. I am just going to go in order on the agenda if that is okay with all of you that are presenting. So, Dwight Law representing the Blue Cross Association.
MR. LAW: Thank you very much. Good morning. My name is Dwight Law, and I am an IT director for application services for Blue Shield of California. Blue Shield of California is a not-for-profit health plan covering 3.2 million members in California.
I am testifying on behalf of the Blue Cross Blue Shield Association. The Blue Cross Blue Shield Association is comprised of 39 independent community based and locally operated Blue Cross Blue Shield companies that collectively provide health care coverage to more than 98 million Americans.
On behalf of the Blue Cross 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 5010, standard transaction suite as anticipated as the next HIPAA ETI transaction rule, and the National Council for Prescription Drug Programs version D.0.
My testimony, based on the experience of other Blue Cross Blue Shield plans as well as my own company, will address 5010 from the perspective 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 the pharmacy program, my testimony will focus on 5010 and the four critical elements that need to be considered when preparing the rule.
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, Blue Shield of California is underlying a major overhaul to replace our core legacy systems. The window for implementing these changes is short, as a work force knowledgeable about how to transition processes 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 are a wave of interoperability initiatives making its way through the Health Information Technology Standards Panel and the Department of Health and Human Services.
Second, implementing 5010 transactions is a big deal, not a simple update, that will demand at least a two-year time frame.
Third, in implementing 5010, we need to incorporate lessons learned from 4010A1, the need for pilot testing and adequate time for rollout.
Finally, version 5010 must be fully implemented before beginning to implement the system and business process changes resulting from the adoption of an ICD-10 code set. Any overlap will be disastrous for efficient adoption and ultimately result in delays and implementation issues for both roles.
Many Blue Cross Blue Shield plans are in a process of upgrading or replacing multiple legacy systems. My plan, Blue Shield of California, is revamping our aging COBOL assembler based circa 1970 core systems. Legacy modernization is expected to cost a half 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 redesigned that will enable our systems to be quicker and more flexible in implementing new products and services.
In spite of these technological challenges, Blue Shield of California like many other Blue Cross Blue Shield plans, 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, Blue Shield of California undertook an intervention which employed monthly computerized analysis of diverse but integrated medical and pharmacy claims data using the patient as a unit of analysis and messages mailed to physicians regarding specific opportunities to improve quality of care in specific patients.
Finally, most health care organizations, payors and providers alike lack sufficient IT staff or business engineering resources to implement all state and federal regulations as well as health care quality initiatives, new products and operational needs. The demand on IT resources simply exceeds our ability to implement our projects in the queue. Strategic work designed to benefit member care could be hindered by implementing multiple rules simultaneously. The alternative is utilizing a consultative work force, adding significant cost which impacts administrative simplification and the financial savings HIPAA was designed to provide.
As an upgrade, it might seem that the transition to 5010 will be less complicated than the original adoption of the version 4010A1 transactions. However, to put the 5010 upgrade in perspective, the implementation of version 4010A1 turned out to be much more lengthy and complicated in some ways, much less successful than was originally envisioned.
Below highlights a chronology of important events. After CMS adopted the initial HIPAA transaction standards by final rule in August of 2000, so many significant change requests were submitted to designed standards maintenance organizations that CMS had to publish a modification rule in February 2003 to adopt modified transaction standards. Pilot testing would have identified many issues ahead of time and thus would have helped avoid the extension and delays that plagued HIPAA. Because pilot testing was skipped, Congress had to extend that HIPAA compliance date by one year from October 2002 to October 2003, and then CMS had to permit contingency operations through October 1, 2005.
Medicare only ended the contingency period for noncompliant electronic remittance advices under the HIPAA transaction and code set regulation on October 1, 2006. Medicare has a contingency plan in place for the 270-271 transaction.
As you well know, with the exception of the 837 claims transaction, the other electronic HIPAA transaction, especially the 200 series real times, are not in high use by providers.
As a major upgrade, implementing 5010 will force plans to go through all the phases of a major system implementation. We will need time to complete systems and process analysis, application coding, conduct internal testing and training and of the utmost importance, conduct external testing with our trading partners.
Testing especially with trading partners was underestimated for 4010A1. Experience has shown that testing rollout to the provider communities, 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 those 4010A1 and 5010 transactions. Based on experience with the original implementation of 4010 and then the subsequent 4010A1, this is a multi-year endeavor.
In addition to system impacts, implementing 5010 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 transactions. This may impact not only payors' work flow, but also providers of accounts receivable processes. Also consider that when the 4010A1 was implemented, HIPAA edits to the front end and back end payment systems were modified. With 5010, many of the edits will need to be revised, therefore a full business analysis of data flow must be conducted by payors and providers to insure that process work flows, front end claims submission, back end claims processing, financial, medical and operation procedures, that require alteration or identified and properly incorporated entity 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 transactions but also new data elements and business associates.
Given the history of 4010 and the extensive phases we go through for 5010, and given all the other changes that are impacting health plans, we cannot see fully implementing 5010 in less than two years from the time a final rule is published and 5010 is adopted. In addition, the provider community has a number of other initiatives to address such as inoperable health records. These projects also need to be considered in order to determine provider ability to implement 5010 at the same time.
From a cost standpoint, it is hard to think about 5010 without also considering the transition to ICD-10, because one of the major reasons for instituting 5010 is to accept ICD-10CM and ICD-10 PCS codes. We expect that moving to 5010 and then to ICD-10 will cost twice as much as the move to 4010A1. This is due to potential system overhauls needed to meet 5010 requirements and prepare for ICD-10, as well as other pending transactions such as claims attachment. These heavier costs entail complex system and business process re-engineering, hardware upgrades, system applications modifications of new version upgrades and staff training. Bottom line: If the industry does not have adequate time to do 5010 right, not only will the costs of implementing 5010 be higher than would otherwise be, the costs of implementing ICD-10 will be considerably higher.
As the industry is learning with claims attachments, as the 4010A1 experience shows, significant pilot testing is essential to insure an appropriate and efficient implementation and without adequate testing in advance of the rule implementation date, the industry could realize a significant system issue. This translates to delays, implementation inefficiencies, and ultimately contingencies.
Pilot testing has to identify issues with the rule related implementation guides prior to a majority rollout. Even a limited pilot consisting of select transaction sets could help payors, providers and clearinghouses adjust systems and work flows earlier in the process to help insure cleaner claims processing and payment flows. If conducted concurrently with final rule development process, it would help to streamline the adoption process. Identifying business process and technical issues earlier in the transaction implementation life cycle can mitigate the rework that ultimately resulted in the issuance of 4010A1. To do otherwise results in history repeating itself, hundreds of changes for the next standard format, contingency and no administrative simplification.
If the cornerstone of HIPAA is to help insure administrative simplification for electronic standards, the baseline is to insure that the transactions are implemented correctly and efficiently. Pilot testing will help make this difference.
In addition to pilot testing, it is imperative the rule offer a realistic rollout time to go into need for contingency operations or extending the compliance date. The 4010A1 implementation resulted in an extension, then contingency. If timed appropriately, 5010 could be extended and the time lines established by the final rule.
We recommend no less than the two-year time line provided for the additional final HIPAA rule, that this time is essential, especially if pilot testing is incorporated into the final rule and the industry wants to implement without delays or contingency.
Two major issues underlie the need to implement 5010 before beginning ICD-10 system changes, cost and resource constraints. It would be costly to build system and develop business processes to accept and process claims transaction with 4010A1 ICD-9, 5010 ICD-9 and 5010 ICD-10. System designs constraints, a basic tenet of system designs to implement and test one major system change at a time. to reduce overall complexity, it is critical that the version 5010 transaction standard are stable before payors and providers begin analyzing the testing other significant changes. It will be difficult to fully identify ICD-10 requirements until stakeholders can finalize the business process and system changes associated with implementing 5010.
It is critical that the version 5010 transaction standard are stable before payors and providers begin analyzing and testing other significant changes. Since ICD-10 is dependent on 5010, effective analysis and design could be impacted if done simultaneously. Insuring that we have converted to 5010, and it mirrors the processing of 4010A1 and allows us to validate that we have the infrastructure necessary and solid on which to base the significant business change of ICD-10.
In conclusion, the primary concern of Blue Cross Blue Shield Association companies is to allow sufficient time for implementation, adoption and stabilization of the 5010 standard transaction suite, for the following reasons: To avoid derailing the current phase of extensive IT system changes underway in many of our plans; to allow adequate time to complete all the phases of implementing a large system 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 5010 transaction suite prior to beginning the implementation of the ICD-10 coding structure.
I thank the subcommittee for the opportunity to discuss the 5010 implementation project, and look forward to answering any questions you might have.
MR. REYNOLDS: Thank you. We will hold all our questions until we get to the full panel. Chris Stahlecker from CMS.
MS. STAHLECKER: Thank you very much. I am very pleased to be here and address the subcommittee to the National Committee on Vital and Health Statistics, the Subcommittee on Standards and Security. I am Chris Stahlecker, and I am with the Centers for Medicare and Medicaid Services in the Office of Information Services. I am with the business applications and management group, and my division is the Division of Medicare Billing Procedures, formerly known as the Division of Data Interchange Standards.
Today I would like to share a few insights about our Medicare fee for service program and how we have been successful with implementing HIPAA 1, and where we are with starting our approach to HIPAA 2, and then try to address some of the comments that the committee had forwarded.
In the Medicare program we have over 43 million beneficiaries. We have over 1.2 million providers enrolled in the Medicare program. This results in over one billion claims being processed on an annual basis.
Let me just say right at the get-go here that I am speaking for the Medicare fee for service program, and these are metrics based on our fiscal year 2007 annualized numbers, so we have forecasts until the end of the fiscal year.
We have 99.6 percent of our institutional claims coming in in the 837 institutional format. On the professional side, which does include both carrier and DME contractors, we have 94.5 percent of the 935 million carrier claims coming in in the 837 professional format. The remainder of our claims are coming in on paper. It is helpful that we have an additional federal regulation called the Administrative Simplification Compliance Act that gave Medicare fee for service the opportunity to deny payment on paper submitted claims for a large majority of our providers.
Since we started to enforce ASCA, we have seen a steady decline in the number of paper claims submitted. We measured the market forces before we started to enforce ASCA, and our paper claims were declining on average about one and a half million per year. After we started to enforce ASCA, which started in our fiscal year '05, which is about April of 2005, we had an announcement, and we saw a dramatic decrease in the number of paper claims being submitted. It was a drop of about three and a half million. So the market forces are taking it down about one and a half million a year, with ASCA enforcement it dropped three and half. Of course, that increased our electronic claims. We think this is a windfall to the industry, because if the provider electronically, they would likely bill other payors electronically as well.
We are approaching our target of two million. We are currently averaging about 3.7 million paper claims. That is annualized for the year.
Back to the electronic view, we are looking at our crossover programs. Most of our Medicare beneficiaries do have supplemental insurance. Over 570 million crossover claims are generated. We have about a 99 percent compliant rate with the 837 institutional and professionals. We do have some fallout, but not much. Once we implement the eligibility -- this is all based on eligibility based crossover; when we implement our claim based crossover, we expect that target to approach 650 million claims annually.
The eligibility inquiry side, we have over 160 million eligibility inquiries processed in the 270-271 transactions. That is about one third of the transactions that we currently are exchanging. A large number of our eligibility inquiries are exchanged by direct data entry, telephone IBR. We do have some additional transition work to do.
We have made a significant infrastructure enhancement to our beneficiary data repositories and we are now in the process of lining up data content from some of our legacy systems into our standard transaction, so that our users are not preferring to take a different avenue such as DDE or phone.
On the claims data side, we have over 16 million claims data inquiries in the 276-277 compliance format. That is our only exchange, other than DDE, IBR and phones. So we do have that contingency as well.
We have over 67 million remittances that are produced annually, and 57.9 percent of them are in the 835 and the institutional side, 34 percent on the carrier side, and the 60.3 remittances that are submitted are in the complaint 835. The remainder of our remittances are in the paper remittance format, so we do see that as a cost savings opportunity for the program to continue to convert to the electronic standard remittance advice.
Now that we are starting to approach HIPAA 2, I would like to share a little bit about what we have done so far. We heard yesterday a little bit about the technical changes versus the business changes. We started our approach by analyzing the technical changes. We have done some preliminary analysis and a side by side comparison of the current 4010A1 and the D.0 version of the standards -- not the D.0, the 5.1 version of NCPDP, the side by side comparison to the proposed standard. We have prepared some documentation highlighting the differences and the variances. We have even gone so far as to prepare a draft file layout that we would introduce to our shared system. That is about as far as we could get, because we do now need to face the business need, the changes to our use of the data changes that are being made evident to us in the new transaction.
We have reflected on how we have done our analysis for HIPAA 1. That was essentially to make sure that our core adjudication systems could continue to process. We did a gap and wrap approach. Even with our coordination of benefits we built a store and forward repository for the data elements that were not necessaRY to be introduced into our core adjudication systems. But today, now that we start to begin to do that same analysis with a new version of the standards or the proposed version of the standards, we are integrating our business units to help us make decisions about what data should be brought into the systems and how that data may be used.
We are forming teams to understand the potential scope of change if we do want to make a major overhaul to our systems and bring in this additional data. We are developing internal CMS cross component teams. We are including our shared system maintainers. We have our Medicare administrative contractors, our fiscal intermediaries and our carriers. We are even including our enterprise data centers, because we need significant change. We need a real understanding of what will operate in our enterprise data center versus what is going to still remain operating at the contractor's data center of choice.
On some of these next slides, we wanted to share some of the questions that we have started to ask ourselves. Should Medicare use any of these additional pieces of data that would be available for adjudication, medical reviews, fraud detection and other purposes? We don't want to just look at the data that is required in our core systems. We want to make an intelligent decision about our future with some strategic planning about the programs that are about to unfold, and which data we might need to bring in now, and if we should continue to retain the store forward approach or bring all the data that is submitted in these new transactions into our core systems.
Today we have the situation that our 43 Medicare contractors select their won translators. We need to decide if we want to switch to a shared consumer off the shelf product or update a current translator solution. If we do want to go down the approach of the COPS product, when will the new version of the standards be available in those COPS products? We need to converge on our implementation planning. Should the system interfaces that we will be defining these file layouts from the new standards into our shared systems, should we reconfigure them to be X12 or NCPDP based file layouts or continue to have them look a little bit like the paper claim layout, the old UB-92 layout.
We also want to address where the new data -- if we decide to bring it in, where it should be retained, how long it should be retained. Should it be made available for direct interacted inquiry, should it be available for our claims examiner to look at, for example, claims attachment data; how many shared system quarterly releases are going to be required to implement the full functionality of all of these new transactions. We have a limited number of hours, and when we have major changes such as NPI, we need to define the scope of change per release and have components move forward through our implementation process, how are we going to address carving our and divvying up the pieces of work around 5010 so that our shared systems can have their regular quarterly release schedules, and when will our systems be ready to support testing with trading partners.
With resource planning, questions we are asking ourselves. We need to establish this project's priority. That alone is going to be difficult, given the plate of work that is in front of Medicare fee for service, but then maintaining this priority over the multi-year implementation effort is going to be even more difficult. As you know, with the financial planning for Medicare, our budget cycle is two years in advance, and although we have requested funding we are a little unsure if we requested the amount, and we don't know when it is going to be approved or if the full amount that we have requested will be approved.
We also are thinking about how we address limiting change to our current ETI during this transition, the 4010A1 and 5.1.1. versions. We need to address bringing our COB trading partners up on the same implementation and cutover schedule, or what other accommodations we might need to address for them. We want to think about whether or not the first time transactions -- and we heard yesterday that there are several that are being proposed for consideration in HIPAA 2, and if they are adopted or promoted as a first time transaction such as claims attachments or standard error reporting -- we heard them called acknowledgements yesterday -- will they be implemented on the same time frame as the HIPAA 2 transactions.
I want to talk a little bit about the project plan. We do have a project plan. It is very tentative at this point, which is why we are reticent to put it up here and in your handout materials, but we do know that the standards are not yet selected. They are nominated, of course, and we believe that we know the scope of change that these new transactions reflect. We were suggesting to ourselves that if they should be promoted in 2000 and the NPRI recommending these transactions came out in 2008 and the final rule came out in 2009, what an implementation time line might look like. We did think that given appropriate testing we would be in a position to tentatively target 2010. But for a full transition for the marketplace to transition, we would need probably a year to conduct that transition making the transactions available in the 2011 time frame.
We wholeheartedly support earlier testimony regarding staging the use of ICD-10 codes as a secondary effort after the transactions have been fully implemented. So we would like to see having the 5010 D.0 implementation with the termination of the current transactions that would cause the entire industry to be ready to implement ICD-10. So we would suggest that as an approach. We don't want to lose the sense of urgency and the interest in getting to ICD-10, but we do want to have an opportunity as was previously stated for the ICD-10 and D.0 versions to stabilize before we bite off trying to implement ICD-10.
The issues that were identified by the subcommittee for particular input today were what the business benefits of HIPAA 2 really were. We do perceive that the standards have become more standard. We heard yesterday how the implementation guides have given more user friendliness and more stability to how they are interpreted.
We have a couple of examples here, the 270-271, the required search and match criteria and the 837. We have an increased number of investigational device exemption numbers for demonstration projects that will help the Medicare program. The 835, we recognize the URL for identifying where a particular plan's medical policy may be located as a significant improvement.
While these all are improvements, we do want to also mention that the maintenance to the 4010A1 transactions continue. One example is this present on admission indicator that is desperately needed. We have had to modify the current 4010A1 transactions to accommodate that. We have taken an approach that will take an unspecified segment, and we have given definition to that. Although that has been approved through a data maintenance approach in the X12 body, we recognize that the 5010 version will have a different approach. So that will cause the Medicare program and others who use this to need to make two implementations, will have to make two changes to accommodate that need, because of the very different way they will be accommodated in the two versions of the transaction.
What are some of the lessons learned from HIPAA 1? I think we have heard we were changing the tires while we were changing the car. There was no infrastructure -- I don't say there was no infrastructure, but a large majority was new as we embraced HIPAA 1, with discovery.
Considerations for HIPAA 2 that are driving us to step back and make some observations is that the Medicare fee for service program is undergoing a major realignment as we implement our Medicare administrative contractors.
We are unsettling and realigning the provider to contractor to data center relationships. That needs to be stable in and of itself. We do intend to complete that transition prior to HIPAA 2 testing. So we are trying to look at our calendar time opportunity and see how we might dovetail the strategic implementations.
Also for lessons learned on HIPAA 1, I think we have heard this over and over again, that the early adopters were the pilot group. The HIPAA 1 transaction, we have to recognize, were not pretested by the industry, and that did cause the addenda to be necessary, and it was not issued until February of 2003 because of the difficulties we were having with implementing those first suite of transactions.
So we offer some considerations here. This is just a consideration. We would suggest that as the standards development organizations are promoting the work product that there be some requirement before they could be considered to be eligible for adoption as a national standard, that they have completed some level of testing.
We think that that could be accommodated through a certification process. We are not trying to belabor the good work that the standards development organizations are doing, but we do need to recognize that it is like writing a computer program and only doing a desk check in implementing that into production. That is the equivalent of what we have done with our HIPAA 1 implementation. So we would strongly suggest that the transactions are tested and it is part of the HIPAA transaction process that the transactions must be certified by the FDO and that users of these, those that claim to have become HIPAA compliant are able to undergo a certification. We would suggest that the ANSE standards -- ANSE does allow a two-year address standard as a trial use time frame, and perhaps that might be overlapped with what the FDOs could publish as a certification process. But we do need some time to have stabilization, rather than to deploy across the country standards that have not yet been tested.
We think that some of the key components that are missing in HIPAA 1 were the standard error reporting, also called acknowledgements. We believe that standardized trading partner identification is also necessary, and we would like to see secure transaction exchange using the Internet as part of what is defined in terms of the world of HIPAA 2.
We understand that there is a little bit of an overlap with these identification of key components in some of the other national efforts, the national health information network and the health information exchange, but we would like to suggest that there be some strategic thinking applied so that some of the pilots and the recommendations coming out from the Office of the National Coordinator have room for the HIPAA transaction.
I know that we don't want to rip out the infrastructure that has been built, but we don't want to turn a blind eye to the need for having it converge. We would like to see some opportunity for that so that we don't approach this crossroad and become divergent.
We have many of our personal health records and electronic health records and HIE initiatives in this fast tracking, but we have not seen the overlap discussed yet for how the HIPAA transactions will be blended in. We believe that that is necessary for the provider community to avoid building separate connectivity capabilities.
The question was asked, is the vendor a covered entity. We would suggest that we do not want to consider the vendor to be a covered entity, but we do want to recognize that the vendors may become a community in and of themselves. As we spoke about certifications, we believe the vendor deliverable should also undergo a certification. We would like to have a distinct category -- as we have covered entities for provider, payor and clearinghouse, we would like to have a distinct category created for vendors with specific performance criteria indicated in order to achieve the HIPAA certification.
We would suggest that the performance criteria for vendors would be beyond just claiming that they can conduct HIPAA compliance standard transactions. We would like to think that there is a deployment schedule, and not names based, but perhaps percent of market share and geographic location identified for how a vendor would deploy in a set time frame their upgrades for 5010 and D.0. We would also suggest that vendors in order to be certified would be required to support current and new versions of the HIPAA standards.
Just as in the Medicare fee for service program, I can tell you we are still getting requests for waivers for some of our implemented transactions, because the provider is saying their vendor has disappointed them. They promised to have the product implemented and they failed to deliver, and now they are shopping for new hardware to support the new products that they had to select. So the problem still does exist.
Should there be an overall industry implementation plan? We learned through WIDI flip that the term plan is ambiguous and is open to many interpretations. We would support the term road map. We would like to see a targeted end date for the current standards, so that the industry could converge again and be ready for ICD-10. We can't emphasize enough that we believe that the standards, the implementation guides, need industry testing. It doesn't do anyone any good to have one line of business such as Medicare fee for service do its pilot testing all by itself, because it can only uncover a certain set of issues with the transactions. We would suggest that it needs to be industry testing. We would also like to again reiterate that we believe it should happen as early in the process as possible, perhaps even before the DSMO transactions for redo.
Again, I would take questions, but we will hold them until the end. Thank you very much.
MR. REYNOLDS: Chris, thank you, very comprehensive. I don't see Susan Mateja from the State of Delaware Medicaid, so we will move on to Annette Gabel from MEDCO.
MS. GABEL: Good morning. My name is Annette Gabel. I am the Executive Director of Industry Standard Compliance for MEDCO Health Solutions.
For those of you that aren't familiar with MEDCO Health, we manage prescription drug benefit programs. In 2006, MEDCO managed more than 553 million prescriptions, including 89 million dispensed at our mail order facilities. MEDCO serves approximately eight million Medicare eligible members through its commercial business and Medicare Part D. At year end 2006, MEDCO served more than 1.3 million Medicare Part D members.
MEDCO also has a specialty pharmacy division. This time around for HIPAA we will have some new challenges because the specialty pharmacies fill their claims through the 837. I am providing this information as background so that you will understand the information that I am presenting, and how am I an expert in some of the history part of this information.
I led MEDCO's HIPAA transaction standards project in 2000. MEDCO has been conducting HIPAA compliance transactions both for NCPDP and the X12 standard since 2002. MEDCO has created a HIPAA charter for the next version of the NCPDP and X12 transactions. MEDCO is currently funded for 2007. We started to create business requirements, and we hope to begin analysis on the transaction standards this year. We did that because of the House and Senate bills that were introduced in late 2006. Understanding that those bills are no longer viable, we still had the expectation that we could be required to implement the transaction standards by 2010.
As far as why we think we need the new transaction standards, we are currently experiencing a number of challenges with the Medicare Part D program, with Medicaid, with new products that are coming to market, and with new benefit designs that are being demanded by our clients.
I know that testimony has been provided on the current process of bringing standards forward for HIPAA. There is concern that unless we modify how transaction standards become part of the HIPAA standards, we will continue to have issues with the standard not supporting our current and future business needs, as we are seeing that benefit designs continue to increase in complexity.
It concerns me when some requests for formats that are being introduced in the standards development organizations are being asked not to be put forward for HIPAA transactions. The reason that people are concerned about that is because they feel that they will need to modify the standards to accommodate their business needs, and if they become HIPAA standards it will take too long to allow those modifications to occur.
HIPAA came along, and we are now required to use those standards. I believe that the industry that is using those standards wants the ability to have them updated so that we can accommodate the things that we need to do today.
In the current standards, and I am speaking specifically about NCPDP 5.1 and the back standard 1.1 representing the pharmacy side of the industry, I will touch a little bit on the 5010, but since our experience is mostly with the pharmacy transactions, what we have seen is that in the 5.1 claim response, in order to get the information that we need back to the pharmacies, especially for some of the generic drug programs as well as the Medicare Part D programs, because we don't have the fields and the segments that we need, we are putting a lot of the information in the free text fields. We have a free text field that goes back on the 5.1 claim response, and we are forced to put information in there, and because of that we have issues where important messages are not reaching pharmacies, or the pharmacies are having difficulty understanding the message because we have to use so many abbreviations.
NCPDP continues to put out guidance to support new requirements, so we have created -- and I believe either Margaret or Lynn spoke yesterday about the FAQ that we have for the version 5.1 standard. We put out guidance to support new requirements that come to us to tell people how to use some of the standards and the fields and segments more creatively, but because it is just guidance it can't be mandated, which causes less standardization in the industry because you have payors requiring different uses of the fields, because there is really no teeth in the information that NCPDP is putting out that provides guidance on how to possibly use these fields and segments.
We have had a big influx of COB because of the Medicare Part D program. Our current processing needs cannot be accommodated. So we need new fields and new values in order to accommodate the requirements that we have for coordination of benefits.
On the Medicaid segregation side, we have seen since the last round of HIPAA transaction standards an increase in requirements for processing Medicaid segregation. The current back standard does not support the industry needs.
On the X12 side, the 835 5010 has additional enhancements that the 4010A1 does not have. So from the pharmacy side of the world, we were required to use the 835 standards, but unfortunately none of the pharmacy side of the industry participated in the creation of the 835 4010, so it doesn't accommodate our needs.
For the 834 enrollment standard, because of the requirements that have since come about because of the Medicare Part D program, we don't have the fields that we need in the 834 transaction to accommodate the reporting information for the Medicare Part D.
These are just some examples of what cannot be accommodated today. There are many more.
We talked yesterday about education. I strongly agree that in order to make this a smooth implementation, we have to be proactive in our education. What I saw last time that worked, but it obviously has to start earlier, is communication from CMS in the form of e-mail blasts, HIPAA listserves, a dedicated HIPAA website and the posting of questions and answers. We have seen some of this with the NPI regulation, so we are definitely moving in the right direction, but with the last HIPAA transaction standards we did not start early enough.
Also from the WIDI and NCPDP standpoints, we have created -- last time with WIDI a little bit after the fact, we created listserves. We also created white papers, and on NCPDP's side we did also create white papers. I think we have done a better job at creating the things that we need for NPI, and maybe it was because we learned so much from the first set of HIPAA transaction standards. But I think more information that we can have available early will help the industry get ready.
I also believe that when the NPRM comes out, it should indicate what resources will be available for education, and it should provide instructions on how people can participate. WIDI and NCPDP should collaborate on white papers as they did for NPI. I think that putting that information together and publishing it and getting it out to the industry is very effective.
Some of the things that we talked about yesterday, and I added this to my testimony, I agree that right now the industry is very busy with NPI. Hopefully when the in-test file is available in August as has been promised, the angst in the industry will subside, and attention can be given to transaction standards. But the reality is, most companies wait for the NPRM, and that was indicated by the survey results yesterday. So when we listened to the survey results yesterday and they said what is going to have you move towards the next transaction standards, the majority of responses said, when they are mandated. So unfortunately the NPRM seems to drive industry to start being concerned about the transaction standards.
As far as the standards implementation approach, yesterday we talked about time lines. I already have thought about time lines. Working with CMS so closely in the past few years on both the NPI and Medicare Part D, one of the things that I learned is that CMS likes for the industry to collaborate and come to them with suggestions, especially when the industry goes as a unified front.
So what I would suggest is that in the NPRM, it should indicate that both WIDI and NCPDP will have SNP committees that will create time lines for the industry to follow for transaction standards. This may include an approach for implementation of standards, for example, enrollment may be first followed by eligibility and claims, but the NPRM must contain an end date that all standards must be adopted by.
The regulation must allow production pilot testing of the new standards so the industry is not in a turnkey situation, where the old standard is in place one day and the next day the entire industry must be on the new standard. If we don't plan that approach, there could be a significant impact to all of health care.
What I would suggest is that we also include a reporting entity. The industry would be required to communicate their readiness for each stage of the time lines, and the time lines that I have outlined are internal testing, external testing, industry testing and production pilot testing. All of these time lines should occur before the end date of when the transaction standards must be used in production.
We should also include penalties. I think if CMS put into the NPRM that there would be penalties imposed if the industry did not meet the published time lines, we would see more compliant use of the standards.
As far as lessons learned, for NPI and HIPAA transaction standards, we do not reach the audiences that lag behind. Others were not concerned with time lines and did not plan accordingly. So again, communication from CMS and industry groups early and often is very important.
Vendors who should have been concerned about losing business were not prepared early enough in passing their clients who were covered entities. The regulation should consider what other entities should be include as covered. CMS should hold their software vendors in cases where they outsource work accountable, so the industry is not impacted by CMS meeting their time lines. We felt a lot of that was the NPI regulations.
CMS' decisions should be more timely. They should include time lines in the NPRM that they should follow when their responses are needed or situations have to be addressed, and of course they should be required to adhere to those time lines.
We need to put teeth into the regulation. CMS must stay on target. We need to include as I said earlier compliance dates for them and their vendors, and we need to publish time lines for CMS' responsiveness.
We have experienced a delay with the transaction standards in 2002. We are now experiencing a delay with the NPI implementation. Contingency periods are very expensive and are usually not budgeted by the entities that are involved in reaching compliance for these transaction standards.
This time around there are many more standards going into this round of HIPAA. We must learn from our previous mistakes. Otherwise this implementation will be very expensive and will have extreme impacts on the health care industry.
Thank you.
MR. REYNOLDS: Thanks to all of you. We appreciate your testimony, and we also appreciate everybody staying right on your 20 minutes. So you may get the gold star from the panel already.
I'd like to open it now for questions. I know that Jeff and Steve have questions, Simon, Judy. Jeffrey, please.
DR. BLAIR: Thanks. Very helpful testimony. Chris, you pointed out the need for testing. I'm sorry, the last presenter from MEDCO? Annette, you laid out four levels of testing. You started with eternal testing, external testing. The third area was industry testing and then the fourth you said was pilot testing.
I found that helpful. You were saying all that should occur before the adoption date. So my thinking is, and I don't know if you necessarily have answers off the top of your heads right now, but I think those are constructive suggestions. If we were to adopt them, I think the next questions that come up would be, how does the industry -- and Chris, you mentioned some of the vendors that did not move quickly enough or were not able to support health care providers and payors, so that was one of the weak links. So I am wondering if we were to go forward with this, whether we focus on how do we get the vendors to respond more quickly to provide the capability to go to a multi-phase testing plan, in other words, not waiting until the mandated date.
The second is, you pointed out that this testing is expensive, and what ideas you might have for the industry to fund this pre-adoption testing activity.
So those are the two questions I have, how do we fund the pre-adoption testing activities, and number two, do you have any suggestions for mechanisms to reach out to the industry to provide more effective education on what these requirements are, so that they can begin to act and implement more quickly.
MS. STAHLECKER: This is Chris Stahlecker speaking, Jeff. There are a couple of thoughts that we had. One was to separate the testing of the standards themselves from the testing of a covered entity's implementation of those standards.
So what I was trying to convey is that the work product itself needs to be validated prior to the industry being asked to implement those same standards. If we could separate them, we could almost begin to consider the testing that a covered entity would be doing as user acceptance testing of the standard. It would still be pilot testing of their implementation of that standard, but the standard itself would have already been validated.
I hope I am making some sense.
DR. BLAIR: Yes.
MS. STAHLECKER: So we would suggest that those two aspects of testing need to be separated. We would like to think that the testing of the standard itself could be embraced by the standards development organizations. Funding for that might be blended into the certification process, where agents that could credential the standards would be able to charge a fee for the privilege of conducting tests. The standards development organizations would likely need to be expanded a bit to require use cases that would then be made available to the certifying agents. When any covered entity even after the vendor -- we would like to think vendors and software suppliers would be one of the first to want to become certified, but eventually all stakeholders may want to use that same set of use cases to run through their implementation as a validation of their interpretation of their implementation.
So we see it almost as two steps. I hope I hit the topic. Maybe Annette would like to add on.
MS. GABEL: Yes. Actually from the NCPDP perspective, we have a little bit of experience in this already. One of the things that we did with the last set of HIPAA transaction standards was, we had created similar to the WIDI SNP, NCPDP had a SNP, and we created industry testing. So we had the processors and usually chain pharmacies. Some software vendors participate in an industry test, where we created as a group claim transactions for testing purposes. We involved a vendor who conducted the transactions, so was situated as the middleman in between the processors and the pharmacies.
So we created test eligibility, test claims, and we initiated those transactions so that the testing occurred prior to the production date. So as that testing was happening, there were some things that came up that required to go in and modify some of the information that we had in the test plan, and it helped us get a better understanding of what we would see once the claims were in production.
So I think it is very important that we do have that. When I speak about that, that is really the external testing in what I was presenting. The pilot testing, which I think I explained a little bit, but I just want to go into a little more detail on that.
The way I view, and I believe a lot of others in the industry, the way we view HIPAA transaction standards right now is that we are required to comply with the current transaction standards until the new transaction standards are in place. So without CMS allowing us to do production pilot testing, meaning, don't be in a test environment, you need to be in your production system to conduct some of those new transaction standards, if not all, before the compliance date, we would be in a situation where we would be doing these external tests.
They wouldn't be millions of transactions as you conduct today every day, they would be a subset, probably hundreds of transactions that you would be doing in a test environment. So you don't really get the full impact of being able to test in a production environment with the number of claims that you are processing on a daily basis.
I think that is important to be able to do that. Otherwise, let's say May 1, 2010 you are required to move to the new HIPAA transaction standards; all of a sudden the whole health care industry has to process these new transaction standards in their production system without any idea of what that impact will be.
DR. BLAIR: Thank you.
MR. STEINDEL: I would like to echo Jeff's initial comments. I thank the panel for some very thoughtful insights on this process. It adds a lot to what we heard yesterday, and I think will help in the subcommittee's formation of opinions on this issue.
I would like to start off by picking up on a comment from this set of discussions on testing. As many people are aware, I am involved with HITSPE and CCHIT, so I have been involved with the certification discussions. At the CCHIT level, which is at systems, we are starting to realize at the CCHIT level that we have to go to lower level certification to make it work. We are starting to realize at the HITSPE level that we have to have pretesting of the standards before they go into play.
I just got off a phone call conversation last week between CDC and NIST. As people are aware, CDC has a public health information network. We realized there needs to be subsystems testing, so we are starting to develop the idea of federally sponsored test sites for these purposes.
So I think industry is starting to coalesce on this idea of, we can't just field test or paper test standards, that we do actually have to provide sites. So I am hoping that we will move in that direction.
My first question for the panel is kind of a general question. But because of what I have heard from Blue Cross Blue Shield and CMS, this is mostly directed to Annette and MEDCO. We heard yesterday about mandates. The comment that you made that the NPRM is needed because it will force the industry to start moving, our experience has been that the NPRM doesn't force anyone to move anywhere. It seems to be that the final rule is what does it.
I'd like your comments on that statement. The reason I am addressing it mostly to you is because what I have heard from Blue Cross Blue Shield and from CMS, they are already starting to plan. They will continue to plan regardless of the NPRM. It may influence their thinking, but they have started.
Is the NPRM enough? I think that is my question.
MS. GABEL: I think it would be great if everyone started planning. As I said during my presentation, MEDCO has already started planning as well, so we are already working on the transaction standards. But I think from an industry perspective, looking at the industry, a lot of companies will not allow you to budget for transaction standards until there is something from the government that says they are going to be required on a certain date.
So if the NPRM comes out and in the NPRM there is a proposed date, you now have the backing that you need to go to senior management and say, here is the end date. It is going to take us two years, whatever the amount of time is for your organization to get there. We need to start working now.
I think until that happens, there are a lot of companies that won't fund the project. That is my personal opinion.
MR. STEINDEL: Do the other two concur with that idea?
MS. STAHLECKER: Yes, about the budgets, for sure. In the absence of testing, the NPRM will open up the standards for an industry-wide desk review. So the comments that come back from the NPRM are a good indicator of how problematic the industry perceives the transactions to be.
MR. LAW: I would simply echo the comments that have been made.
MR. STEINDEL: I have some specific questions for each one of the presenters. The first one is to you. You made the point about, 5010 is needed before ICD-10 can be approached. I started this questioning a little bit yesterday; it is just a thought process. What if we could introduce ICD-10 into the present transaction sets without major perturbation, so we keep 4010? Does that change your thoughts about 5010 needing to go in place first?
MR. LAW: First I would like to know what that will look like, because it will be hard to get your head around something that really is not out there. But I think the key point about the testimony is that, the time it will take just to go ahead and move to 5010.
So to answer your question, I would like to add on that the state of the industry is not where it was in 2003. We had some transactions that we were working towards. What is different about today? Why would it be more difficult just to do the standard testing, regardless of whether it is a 5010 or a 4010, different version?
A couple of things have changed. One of the things that we have to realize is that we have the same set of characters that were involved in 4010 in terms of clearinghouses, but what we have is, about 15 to 20 percent of the business that we do is with direct connections. So that is different than what we had in 2003. That will require more testing, because we have more trading partners. It is not a number that we had in 2003 comparing to the same number that we have in 2007.
So I just want to make sure that that is one of the reasons why. There is a triangle that all IT people go through. There are people, processes and technology. This is just about technology, but the other component to that is the processes that have to be changed and the people that have to be affected by it.
Another thing that we look at. We know that we have business associate agreements, and some of this may require us to examine and look at, do we need to change some of the business associate agreements in order to go to a different version.
I don't know your experience, but mine is, when you have to get legal involved, which would be required, it again adds on a certain level of complexity and time. So those are elements that I think we need to consider.
The final point I would add is, if we look at the 835s in 2003, how many trading partners did we have for that? We were really a small number. Now it is one of our most popular or most utilized transactions. What does that mean? Again, significant involvement with the trading partner in testing.
So while you could say that you could go to some other version, less than a 5010, my comment would be, it still requires the basic elements of testing people in packs and processes.
I hope that answers the question.
MR. STEINDEL: Thank you. That was a good clarification. I appreciate it.
Chris, my question to you. We heard from Dwight that they are starting to redo their 1970 systems regardless of 5010. What I heard in your talk is, in introducing 5010 if I can translate it maybe inappropriately, but it is to redo your 1970 systems as well. Would you do this if 5010 was not put into place? MS. STAHLECKER: We do have some legacy issues that we need to deal with, yes, that is a certainty. However, we would like to use real business drivers, real data business needs to help us determine the scope of change that we want to make to our systems and when we would apply that change.
So it is a little premature to ask us that question, because we are still forming our teams, and we are just now introducing our business owners into looking at the data content in these transactions. I can come back and speak to that at a later date, but right now we are waiting to have more of our business owners drive that.
MR. STEINDEL: Thank you. If we just decided, let's bag 5010 and just say the NCPDP transactions seem to be a good consensus from what we hear from the pharmaceutical industry, if we just said, let's move forward with the new versions of the NCPDP transactions, would that solve most of your problems? Or would you still need 5010?
MS. GABEL: It would solve most of our problems but not all, because we do use the 834, and we did add fields to the 834 enrolment for Med D. So we would need at least that transaction to move forward.
Some of the PBMs use the 270-271 as well when we are conducting electronic prescriptions. So there are some -- not all the transactions in the 5010 are used by the PBMs, but there are some that are used. So I would say yes, the majority, but it wouldn't help us completely.
MR. STEINDEL: Thank you.
DR. COHN: Like the others, I want to thank the testifiers for what has been some very useful discussions. Some of this begins to take on a flavor of phase two of lessons learned from HIPAA, so I want to thank you all.
I have a couple of questions. Christine, I wanted to start with you. I am reflecting back on the many years we have all worked together on implementation of HIPAA. Christine had a previous life before CMS which we won't reference specifically.
But I was reminded as you were testifying, and correct me if I'm wrong, that you were part of the claims attachment pilots. I am reminded of the letter we sent out a couple of years ago about the issue about pilot testing of new transactions. Could I ask you to wear a different hat and reflect on how that all worked when you tried to do it? Was it helpful? Did it help move the industry forward? Just help guide us.
MS. STAHLECKER: I can say, I wish I was able to have participated in the complete pilot test. However, the funding that came to the contractors that had planned on pilot testing was absorbed by Y2K.
So at that time, although we did come to the committee and we were prepared to test, and we had selected our vendor, and we had the software and we trained on the software and we were ready to start testing, the completion of that test at that time was delayed. It was reintroduced and was part of the second test, although I was not part of that.
I know folks who did work on that project, and I have been at HL7 and listened to the success stories, and some of the issues that they had uncovered. So pilot testing does still play a very important part when the standards have not yet been completely developed, if you will. It is unit testing of the standards development product.
They did discover that dialup will not work for claims attachment. It would need to be a more robust method of communicating that standard. They did find some issues with MIME protocol. I won't get into some of that because I'm sure it has been presented here before, but I do want to emphasize that pilot testing of the standards development work product is crucial before we start to roll it out.
DR. COHN: So your comment is that it may not be quite the same for any sort of testing of this version, but it would probably be similar sort of testing, at least on some basis.
MS. STAHLECKER: We were trying to suggest earlier in the testimony that the industry stakeholders would be incented to participate in a test of the standards development work product in order to be able to become certified. The certification would be almost a business requirement in order to sell product in the marketplace, in order to have a provider want to implement the new HIPAA version if you will with a mandated deadline. The provider business problem becomes, how do I select the vendor product to put my business on, my 99 percent electronic claims submission process to Medicare? How do I select a product? It would be nice if that product could be certified as HIPAA compliant.
So backing into that, the vendor would need some certification credentialing criteria. That might be to participate in this industry based test.
DR. COHN: Just to follow up, because maybe I'm getting confused, it sounded like you were talking about a test that would be handled more in the SDO level as a phase one activity. Am I mistaken about that, Christine?
MS. STAHLECKER: No, you are exactly correct. But I would make sure we are communicating on the phase one term. As the standards development groups promote or are ready to promote new standards, before they could advance that out that there would be a certification requirement, it is not just a documentation exercise. It should be proven in the industry.
We could call upon some of the associations and the groups that would participation in this industry test, that the culmination of that would be a certifying agent or agents, and they would be allowed to participate with any of the standards development organizations.
I'm not trying to suggest the standards development organizations pay a fee, I'm not trying to suggest that, but that the credentialing be robust enough to make it be an incentivizer to the vendors to achieve that credential and be willing to pay a fee for whatever working documents, if that be use cases, if that be an ability to exchange one vendor's test with another vendor's test, could that be an ability to use some of the transaction validating tools, but they would be willing to subsidize that in some fashion in order to achieve that certification.
DR. COHN: I think I have followed up enough on this one, but there is a slightly different topic I just wanted to reflect on for a minute. This has to do with the products of standards organizations. We have heard something about streamlining and getting more involvement by the business community earlier in the process, but I am struck when I look at two very sophisticated organizations, both of whom I know have very substantial involvement in at least one of the organizations we are talking about, X12.
Yet, I am sensing that there is a disconnect about the product that has come out. If you think about it, with that much involvement, one would think it would be the best of all worlds that you would be knowledgeable about the improvements. You would have helped provide input into them. You would be being supportive of all of the new functionality that is coming out, and of course you would support it because your people would be involved.
Yet, I'm not exactly hearing that. Is it just early in the morning from California, or can you comment?
MS. STAHLECKER: I'd like to comment. We would like the standards to go forward. However, we would like them to be tested before they are scheduled and mandated to go forward with deadlines.
We would like to have them tested before we begin to embark upon implementing them. However, in the absence of that, if they go forward and they are nominated as new standards within Medicare fee for service, we will test them. But we just need to recognize that they have not yet been industry tested.
So it is like the life cycle, data processing 101. When you discover change early, it is less costly to fix that problem. When you discover it in user acceptance testing, which is what happens when we deploy these standards out to all the stakeholders to implement, we are discovering problems at the very last stages of implementation. That is the most costly place to identify a change that is needed.
So we are just suggesting data processing 101 be applied here, and we bring the testing back to the earliest point of opportunity which we believe is when the standards development organization is ready to promote their work product out. We would like to see some activity there to test these new promoted standards.
MR. LAW: I come to think about a product like Microsoft. We all have the -- we know we can go from 95 to 97 to XP and Vista. The reality of it is, they dominate the market and so therefore they can do that.
So when we talk about our product. When we talk about the X12, when we talk about the changes that are required, they are not upgrades, they are implementations, because we don't have that kind of software that we can put on a laptop and click and it gets automatically uploaded and things change. It requires again to kick the tires before we go into production.
I think that is what Christine really is talking about. If you look at NPI as an example, and this is certainly bigger than NPI, I need to make that clear, in terms of going to 5010, but if you look at NPI, all of a sudden on a certain date -- and we try to get it early on and start it in 2007, in April for my particular plan, but that is at the end of the process. It is right before implementation.
So there were some issues that came up and we had programmers and developers going around and make all these changes. How great would it have been if we would have had the advantage, because it is pretty much clear that if we would have had the advantage of having a subset which again is what I am interpreting from our comments, to have tested it in a production environment and with a certain number of trading partners and providers, et cetera, how much richer, how much smoother would that implementation have been. I think that is what we are all agreeing upon.
DR. WARREN: I think it is interesting that so far my three colleagues have all hit the same questions I have. But as I was listening to your answers, I keep thinking back. We have had a request to streamline the adoption process. Yet, what I am hearing is that we need to add another step. So we need now to test the standard and certify it, which takes a certain amount of time.
Then we keep coming back to this pilot testing, and we keep coming back to the original statement of, nobody does anything until it has a mandate. There is a date out there, and we always miss the mandated date because no one has done the pilot testing, and no one will do the pilot testing until there is a mandated date.
So it seems we have this chicken and egg. What I am wondering is, would it be helpful or would it just create ore chaos in the system if we mandated a time line for the pilot testing? Everybody is shaking their heads, for those who are not present. But do you have any recommendations for how we might do that?
MS. GABEL: I have suggested that there be mandates for specific time lines. So when the NPRM comes out, it mandates time lines for internal testing, external testing, as well as production pilot testing. That all has to happen before the end date.
DR. WARREN: Dwight, before you answer me, you had also mentioned that it would take you two years to implement. So would that include the pilot testing, that two-year time frame?
MR. LAW: Yes, it would have to be in front of the two years, as I think about it, yes. The reason for that is, you want to take advantage of what the results are.
So if you do the pilot testing and you are in fact finding some changes, as I would imagine you would, you want to make sure that you had the breadth of time to implement those things, so the rest of the industry doesn't go down the same path.
Really, what Annette was saying, it goes back to Christine's 101. You want to have deliverables there. What we have had is one deliverable, so we have that mandate, and everything has to be done there. I think what we are suggesting is the phases that Annette has talked about gives you more control in terms of milestones and more accomplishments, more successes, so that when you go for implementation it is smoother, it has been tested, and the results can be achieved in actually a smaller time period, because you have found out what are the things that need to be improved, and you have done that up front, not while the industry altogether is making the change.
MS. STAHLECKER: I would agree with those comments, and also add on that one of the missing components from what we heard yesterday was the return on investment or cost estimates for doing this implementation. If we did have some testers, we would be able to measure and see the benefits, and perhaps even conduct a benchmark.
DR. WARREN: One last question for Christine. You mentioned in your presentation, when you were talking about your project plan, that one slide that had plan on it, that what you really wanted was a version of ICD-10 that was stable. Could you talk a bit about what you mean by stable?
MS. STAHLECKER: I think I meant to say 5010. We would like to have the transaction implemented, and I apologize if I mis-spoke.
DR. WARREN: Good, because I heard ICD-10.
MS. STAHLECKER: We would like to have the transactions implemented and stable before we start to introduce processing ICD-10.
MR. REYNOLDS: Many people that implemented HIPAA put up websites. One of our esteemed colleagues from the past was the father of a lot of this through Claredi and other things, where everybody could create a transaction and send it to a website. The website would validate the in. Every player in the industry could send either in or out. There was some kind of a process. The website was set up on implementation guides and everything. The website was not parochial in any way. In other words, anybody that could create the transaction could send it. Somebody owned the website and so on.
The hardest part of some of this testing is getting somebody in the middle ready, but these websites were that middle capability. If you took those entities that were set up in many, many places and in many, many ways by many, many entities, and you made that somewhat singular so that there was a standard implementation guide going back to the SDOs, there was a standard implementation guide, standard approach, this is what you do in the fields, this is what you do. If you send in this claim, this is the remittance you should get back and so on.
Then to play off of Steve's comments, add in something like CCHIT which would say, if you did certain things on that, then you would have a certified system, whoever you might be, just thinking, not recommending.
When you talk about streamlining and pilot testing, everybody says everybody has to get ready. But if you go back to the way it was actually done in many places, that process was exactly what I think is being heard. So I would love your comments on whether or not you see that as maybe a way to go about this.
MS. STAHLECKER: I do see that as a definite possibility. Yes, I agree that that is how the testing was conducted for HIPAA 1, and that did give each covered entity an opportunity to be ready themselves, and test independently from trying to exchange with a trading partner. So each covered entity could do the equivalent of unit testing.
The unfortunate part is many uncovered discrepancies in the transactions in the early time. I don't want to belabor that point. But if we had that kind of capability, where there were an opportunity to exchange test transactions with something you refer to as a website, we don't know that those vendors are going to step up to that challenge again or what might be put in place to encourage them to step up to that.
Jeff had asked questions about fees and how we might deploy something. Perhaps if the certification were a requirement, then there would be interest in paying a fee to do that test.
MR. LAW: What I recall from that time period is that while that was out there, the certification came at a point in time, and what the problem was, many times change occurred afterwards. So while that process did work to build the Claredi and say you were certified on a particular date, guess what? The development still required changes. So it kind of like invalidated that initial certification.
Certainly there are ways to do that. I think that again, you have to have vendors incented or have a return for them to get involved in doing those kind of things. But it is absolutely one way to looking at things.
I would just caution, because I remember looking at the dates out there for some of the vendors and some of the trading partners, and knowing that those dates were given early and they didn't subsequently make changes to their system and go back and get recertified.
MS. GABEL: I think that involving an entity or entities in doing that type of testing is very valuable. I think we are talking about Claredi, because they did the --
MR. REYNOLDS: No, I was just using an example. I am not directing anything anywhere.
MS. GABEL: I know. I'm just saying, they were the ones in the past that did it. One of the things that they did to get people involved is to say that they would put your name on their website to say that you certified your transactions. But there was not a lot of people that were involved in that certification.
It wasn't mandated, it was voluntary. So if you wanted to do it, you did it. But again, if you put something in the regulation that requires that, then you will get more compliance.
MR. REYNOLDS: That was where I was headed. I was using it as an example to start the discussion. Jeffrey, you have got the last question.
DR. BLAIR: Dwight, you helped educate us as you listed all of the different considerations that have to be made that could require either resources or time, that needed to be considered in these factors in the transaction from 4010 to 5010.
I understood all of them, but there was one I didn't quite understand, so help me with this. You indicated that you might have to renegotiate or add business associate agreements as you move from 4010 to 5010. Since the data elements are essentially the same, I didn't quite understand why you need to do that. So could you help me understand that?
MR. LAW: Sure. One of the things that I hope I said is that we may have to do this. I was involved -- in a previous life I was the director for the PMO for Majors Health Care Company in Southern California. So for those who guessed it, I'll talk offline and confirm it.
I was involved in the negotiations for some of the business associate agreements. Some of them were very, very specific, to the extent that we called out specific translations, specific fields, et cetera. So what I am concerned about is, because of the specificity involved there, if we go to a new release and we are asking different testing to occur or different changes to be made, that we have to revisit those documents.
Now, instead of looking in 2003 where there was a subset, now there are more of those documents. If we have to revisit those documents and we have to get legal involved, that takes a time frame.
But certainly, I do not know, not being a lawyer, that it will be required. All I am suggesting is that we will have to spend some time to look at and examine to determine whether or not we have to make those changes.
MR. REYNOLDS: Thank you to all of you, well done. We are using this clock up here. I don't know what your watch says, but I know what that one says. So if we could come back at 11 o'clock, we'll take a ten-minute break since we are running a little bit behind. Thank you.
(Brief recess.)
Agenda Item: Vendor/Clearinghouse Panel
MR. REYNOLDS: Our next panel is on the vendors and clearinghouses. We will hear first from Bing Herald from HBMA and then Miriam Paramore from Integra Professional Services, Margaret Weiker from EDS and Linda Campbell from Smith Premier. If you could keep your comments brisk, that would be good, since we have a large panel. That would be great.
With that, Bing, please.
MR. HERALD: Mr. Chairman and members of the National Committee on Vital and Health Statistics Standards and Security Subcommittee, I am Bing Herald, immediate past president of the Health Care Billing and Management Association, HBMA. We represent the more than 600 companies in our association who do trading partner medical billing on behalf of mostly physician practices, but also some other ancillary, what could be determined as Part B services.
In addition to my responsibilities as immediate past president of HBMA, I am also president and owner of Medical Business Service, a large medical billing company based in Coral Gables, Florida. We are one of the largest privately owned billing services for hospital based physician practices in the country.
With me today is Mr. Richard Uthrie. Richard is a senior vice president and chief technology officer of ArborMed Corporation. ArborMed operates in 39 states. They are also a medical billing company. They work directly with all Medicare and Medicaid Blue Cross Blue Shield plans in their service states, for all ANSE 4010A1 claims processing, as well as interfacing with over ten major clearinghouses. I asked Richard to be here with me this morning to assist with any technical questions that may be beyond my pay grade.
Just a note. Both Richard and I, although we look very young, we have been in this industry for 30-plus years. Richard and I were vying to be the first sender of electronic claims to Blue Cross Blue Shield of Florida. I don't think it was a competition of any kind, but our company ended up as sender number one for submitting claims in the country.
HBMA is the only tarde association representing trading partner medical billing companies, Mr. Chairman. Our members process medical billing and other claims processing services integral to the health care delivery system. Upon recent member surveys, we estimate that HBMA's member companies submit more than 100 million claims a year for revenues exceeding $15 billion.
Although a large percentage of billing companies work for the hospital based specialties, billing companies can be found working for physicians in virtually every specialty as well as for home health and DME providers.
In preparing for today's testimony we were asked to focus on three core questions related to the move to the 5010 standards. One is work flow, then training, and system changes. Before getting into the specifics of our testimony, I want to say at the outset that HBMA has been a strong supporter of the move to electronic transactions in the health care environment. We support the original HIPAA legislation and worked with third party payors, government and commercial, to develop workable systems. Like so many others, we are frustrated by some of the lack of progress.
Billing companies find it ironic that nearly every aspect of our business can be handled electronically. Our companies can order supplies, we can order and pay for and track their movement electronically, our customers can pay us electronically, our staff and employees have their paychecks deposited electronically, and all of those standards seem to exist and flow probably without hearings like this, because commercial business and business needs tend to drive those requirements, and they end up just happening.
Virtually the only area that we cannot conduct seamless efficient transaction processes is in our core business function. As we have in the past and must ask again why, why has it taken ten years to develop the infrastructure necessary to move medicines along and higher education along into this century.
When the 4010 standards were announced several years ago, they were initially greeted by the industry with great fanfare. Finally we would be creating a uniform platform for health care claims 837, 835, 276-77, 278. I believe we heard about the pharmacy standard transactions a few minutes ago. These visionary standards were supposed to eliminate the numerous claim forms of the individual third party payors. Gone would be the NSF, which was the national standard format, and in cynical water cooler discussions became the national similar format, the national sometimes format in the ways payors ask for information and transmitted advices to physician.
Unfortunately, our euphoria over the adoption of the 4010 standard was short lived, and a new term entered our lexicon, companion guides. Soon, every third party payor including Medicare contractors announced the development of companion guides to the 837 and 4010A1.
The different ways third party payors wanted you to organize the information on the 835 were as numerous as there were companies. For example, the 4010A1 set the standard of 50 line items per claim, but a companion guide from any commercial payor in the country could, and some of them limited you to six lines per claim. There are hundreds more examples of these non-standard requirements that billing services are required to deal with. At one point, it was estimated that there were more than 1200 companion guides published by the various third party payors. As Yogi Berra would say, it is deja vu all over again.
So as we look toward moving the adoption of the 5010 standards, the first question we were asked by our members is, will this eliminate the need for companion guides. Unfortunately, our assessment thus far leads us to conclude that while 5010 will eliminate the necessity for many companion guides and precludes payors from issuing new guides, nor does it eliminate the need of some plans to want to continue them. This conclusion is important because it leads directly to the questions you have asked us to address.
One, system changes. Since 4010A1 became mandatory in 2003, billing companies, medical software companies and the clearinghouse industry have all worked hard to develop software and processes that would take standard information and properly format that for the specific demands of individual payors. Basically we would develop patches in the system to accommodate the various 4010A1 companion guides in order to quote-unquote make it work.
I'm sure all the members of the subcommittee are familiar with the old saw, if it ain't broke, don't fix it. But our system was broken when 4010 first came out. We have largely fixed the problems it created. Billing companies, software vendors and clearinghouses have spent millions of dollars to try to achieve some of the efficiencies that were promised by HIPAA. The patches are working. The staffs have learned the nuances of individual companies, and from an electronic standpoint we believe the system is functioning.
There is no question that adoption of the 5010 will result in system changes. In all likelihood, the electronic patches and work-arounds we put in place will not work with the new standard, and may cause systems to crash. Billing companies and physicians will incur costs for these systems, both direct and indirect.
To speak to the direct, the cost of purchasing the software necessary to meet the 5010 format standards do not have any firm pricing data at this time. However, based on preliminary discussions with some vendors, we believe the software development costs could be minimal when mapping the format changes from 4010A1 to 5010.
The same software vendors tell us that their costs will be significant, but they will likely have to absorb these costs as an expense of doing business. So while there will likely be some direct costs, we do not believe that this will have major impact.
The indirect costs. There will be glitches in the system. As we heard from the previous panel, in the more than 30 years we have been working in medical billing, we have yet to see a software or system change that goes over without a hitch. Problems are inevitable, and this means added costs are inevitable. As a business, you hope to keep those costs at a minimum, but you have to presume that there will be some costs involved with the system changes. When I as a business person consider a system change, I look at what can I expect in return for what I spend on that investment. Will it make me more efficient? Will it make business for our members' overhead go down? Will it make our staff more productive?
I mentioned earlier that virtually every other type of electronic transaction we can conduct can be done efficiently, and results come in at either lower costs or competitive advantage in the marketplace. We don't do these things because the government tells us to do them; we do them because they make business sense.
Billing companies, software vendors and clearinghouses want the more efficient transaction processing. Third party payors, whether government or commercial, have little incentive, we believe, to make the system work more smoothly or at least, there are some cross purposes that could be identified. Now you ask us to react to new standards which we believe will seriously disrupt our business operations with little or no improvement and efficiency to show for this investment. That is really our members' biggest objection.
So to the question, will adoption of the 5010 standards force our members to make system changes? The answer is yes, and these systems will be expensive from a training perspective.
The subcommittee also asked us to address the issue of training. Billing companies spend a considerable amount of money on employee training. This is due to the constantly changing nature of the business as well as to employee turnover. Billing companies and HBMA members alone represent almost 30,000 FTEs or jobs in this country. All of those folks will touch electronic commerce in some fashion, because that is the nature of the business, is to get health care encounters paid for in an efficient manner.
Work flow topics. With the patches and work-arounds we have instituted in our business, we have made the current system work, as I stated previously. We are able to submit claims in a timely fashion, get paid on those claims in a timely fashion, and do this at a reasonable cost. However, as a billing company we believe that for some period of time, transition to the 5010 will cause work flow disruptions. Billing staff will be populating fields not previously captured on the claim form or claims format, and this will lead to decreasing staff productivity. New information will have to be captured on the claims, which will also reduce employee productivity for no added payment or benefit or efficiency.
Billing companies often rely upon others to provide the information that gets populated into our claims, especially in tertiary care markets like hospital based specialties. With additional fields to complete, staff will have to ask for additional information. If past is prologue, collecting that information will take time and cause delays in submission of these claims.
If as the 5010 field suggests CMS will be requiring more information for claim payment, then CMS must enforce the chain of data population of the fields. For example, it is not uncommon for a hospital to collect admit data but fail to provide that data to a tertiary care provider like a radiologist. The radiologist has no access to the data, there is a whole interruption of data flow, and having to go capture information to populate a claim when it really has nothing to do with the eventual value or remittance on a claim just seems to be a little silly.
In addition, we anticipate serious problems in getting paid in a timely fashion by adding all this burdensome data with no benefit to the system. An example of a recent change in work flow that has caused consternation and delays in the whole system is the Pecos implementation or the provider enrollment chain and ownership system, which is the whole credentialing process. I had a whole elaboration on that, but I think everybody knows what that is about. It is in my testimony if you would like to see that.
The rollout of that system was supposed to be efficient. It is so messed up today that we have providers waiting six to ten months and sometimes to a year, waiting to get their credentialing accomplished. It is our understanding that that is going to go online. Bill Rogers with the physician regulatory improvement team announced to us a couple of months ago that it is going to go online. It is supposed to be this fall. We will anticipate there may be a delay in that, but we are very excited about having that come online.
We have providers now, to a large degree Medicare beneficiaries, that may be going unserviced by these very significant delays, and we don't want to see that happen as a result of transaction standard changes. Our cynical evaluation of that was, we were told about the dissemination notice for making the NPI a public use file back in November. We were told that the dissemination would be soon. In February we were told it would be very soon. In June it was announced as imminent, and it is still not out today. So the industry gets a little cynical about the deadlines and the mandates that have been placed out into our environment.
Mr. Chairman, billing companies and physicians will be asked to invest thousands of dollars and hundreds of person hours in a system that will slow down payments and complicate the system. Again we must ask, for what return?
The rollout of these changes in which numerous entities are involved should be restructured. We are using the metaphor of a relay race. With NPI, what should have been a relay was a sprint to a common finish line for everyone involved. The evidence of the folly of this approach, we have seen reports that upwards of 90 percent of physicians have their NPI, but fewer than 40 percent of claims are being processed using it.
Much as articulated by the payor panel we just heard, of the 5010 we recommend the rollout be structured with health plans being required to adopt the 5010 standard by a time certain prior to moving to the next phase in the rollout. There should be adequate testing.
The rest of my part of this testimony is redundant, so I am going to cut that, but it is readable in the testimony.
What the billing and provider community -- the providers themselves would like to be the anchor in the net relay race if at all possible, because we are the ones that have to deal with the largest impact if things get screwed up prior to us taking it on.
The reality is, Mr. Chairman, there are still other interim steps that have to be taken before we reach our desired goal as a fully automated efficient claims and payment system. Adoption of the 5010 is a stopping point along the way, but it is a stopping point that we believe frankly is unnecessary.
There is nothing in 5010 that is going to make the lives of our billing service members easier. What in 5010 will make us more efficient? What in 5010 will allow us to reduce our costs or our overhead? It is a transitional set of standards that will still have to be replaced by future iterations, so we still ask why. Adopting 5010 won't get us to the finish line any faster. It won't accelerate any savings providers might realize as a result of improved efficiency. Its adoption will raise costs, slow down work flow, make it more expensive for health care to be delivered. Please do not allow everyone to keep dropping the proverbial baton.
On behalf of the billing community, we appreciate this opportunity to testify today. We are happy to answer any questions.
MR. REYNOLDS: Thank you, well done. It is the first time we have been beseeched in awhile, but we will go with that. Miriam.
MS. PARAMORE: Good morning. Harry, I think I can help you with some briskness. I'll defer to some testimony from yesterday.
My name is Mariam Paramore. I am Vice President of Integra Professional Services. Our organization is a billing company that also provides IT infrastructure to physicians, offers an ASP Internet access environment, and also acts as a clearinghouse in some cases. So we are a vendor and have been an HBMA vendor in the past.
Today my primary role in speaking to you is as the chair of the HEMS Affect Financial Systems Steering Committee. Some of you may know that Affect merged with HEMS last year and now has the standing of a steering committee inside of HEMS.
As an aside, I can also put on two other hats that I have heard in the last day or two may be relevant. One is as the board chair of the Louisville Health Information Exchange, that is trying to focus on how to exchange financial and clinical data in our RIO in our community, and the other is in the Kentucky statewide HIT adoption committee, where we are struggling with broadband access in rural Kentucky, and less than ten percent adoption of EMR and a whole lot of paper still going on in the practice management world.
Thank you for the opportunity to be here. I am click us through these slides. Again, today my role is as the chair of the HEMS Affect Financial Systems Steering Committee, whose members are primarily health care clearinghouses but also vendors and other transaction processing companies, and also as a HEMS board of directors member.
We are going to talk about three things from a real world impressions point of view. One, the NCPDP standard 5010 and then deadline dates we have carved out as the specialty focus of our comments. Look how brisk this is, Harry. We are not even going to comment on NCPDP. I don't think anybody could be faster. It is not relevant to the majority of our membership at this time, so we will move on to the 5010.
I think that Don Bechtel and others have done an outstanding job of articulating all of the details of how and why 5010 is an improvement over 4010A1 from a data content and perhaps format and processing perspective, so I am going to skip through and be very brisk, and show that we have articulated some of the highlights by transaction type.
We agree that 5010 is an improvement over the 4010A1 format. Here are some of those highlights. As Bing said, there is a way to pick up a little bit of time.
To sum that up, we do see it as an improvement. We can go back to Don's comments or some of these if you would like in the question and answer time frame.
I would like to use the rest of my time to discuss this issue of deadline dates and our real world impressions on what we have learned from HIPAA 1, and some ideas we have had for moving forward at this time. I think we all know that everyone waits until the last minute. I think that we understand that by statute no one has to be any readier than anybody else. So what we are talking about when we say last minute is all industry stakeholders for all transaction types do on the same day. That has been discussed widely as to why there are some flaws in that logic.
We got some recommendations. Like my Dad used to always tell me, don't bring me a problem, bring me a solution. So we are going to make a suggestion in just a minute.
We see three key issues with the two-year deadline process. We don't think there is enough time in that process. When I say vendor, I use that term very broadly. That is to include clearinghouses and vendors of software and other switches and transaction processing organizations, so that is a broad term.
We do not feel the two-year deadline gives the entire industry in the vendor sense time to analyze the changes, do the coding, test it and then implement the changes. Chris did a good job of talking about the life cycle 101, and we agree with some of those comments.
We also feel that it does not allow enough time for the vendors to then deploy changes to their massive customer base. Even if a vendor isn't ready, our experience has been that especially the small provider community may not buy the upgrade, download the upgrade, load it, have it working in their office or any version thereof, even if the vendor could say they were quote-unquote ready.
Then finally, once they get it into their shop, they have to test it themselves, which is again the equivalent of unit testing and not systematic testing.
So our bottom line is that two years is typically not long enough to adequately prepare for compliance for even maybe one transaction type, but certainly not for our transaction types in a mandated environment.
One of the major problems is that most don't begin until the final rule is there. There have been historically some significant differences between the proposed rule and the final rule. So as business people, organizations aren't comfortable expending money to do something they are not sure will have to be done in the final rule, so that exacerbates the problem.
There has been some discussion of this, and I will come back to this point in more detail. There has been historically some evidence that federal government programs have not been ready by the compliance date. We have seen that experience with Medicaid programs, Indian Health and others. What that does is dilute the effectiveness of the federal government's leadership in putting out mandates and/or enforcing them. Past efforts have not been successful due to unrealistic deadline dates. We will comment more about that.
In conclusion, our industry experience and historical view based on history is that simply giving new compliance dates for a new set of standards is not going to do anything to change what we have experienced so far. The definition of insanity is doing the same thing and expecting different results. Two years is typically not long enough to adequately prepare, as we already said. Regardless of any decision on compliance deadline dates, any deadlines must be endorsed and in line with CMS' capabilities to meet them. We feel very strongly about that point. If compliance dates are not sequenced appropriately, we feel the industry will fail again.
Before I offer up our suggestion, I will tell you, there may be a few issues with our suggestion, but we are going to make it anyway. We would be happy to comment. At least we did our homework to try to identify some issues with our own suggestions from other peoples' perspectives.
Here is our recommendation to break this historic cycle. We are suggesting that the industry convene some sort of summit or collaborative meeting to do a mega project management session. We would be happy as HEMS Affect to help facilitate that, working with other groups in the organization.
I am going to tell you a little bit about what our thoughts are around this. Let me back up just a second. Our key point is, we would like to do that prior to the final rule coming out. I'll talk about why that is important to us. What we are saying is that a project management meeting -- and there has been prior testimony talking about WIDI SNP, how powerful and huge and wide and deep that was, how much we learned. But at the end of the day it might not have been as effective as we would have liked because there were certain issues that we could not get around.
What we would like to suggest is that prior to the final rule coming out, we have CMS, Medicaid programs, clearinghouses, large providers, large systems of software vendors and payors. We know that we can't get everyone, but if we think about market share and key players, and we get the stakeholders together around the table to have a discussion, we want to talk about realistic deadlines for compliance, a realistic plan, and try to create some collaboration and cooperation.
We would like to first suggest specifically that CMS be involved and committed to the overall planning process in tandem with this group and the establish of deadline dates. We would like to ask specifically that this include CMS operations staff versus regulatory staff. We would like to suggest that CMS commit to implement according to the final regulation that comes from this industry-wide group. We feel that is absolutely critical for the plan to succeed.
We would like to suggest that there is a hole in the process of even betting everyone to the table. That hole is that there is no trade group that we have been able to find that coalesces and brings together all of the small practice management vendors into one voice. We do have MGMA and other things that coalesce certain voices, but not necessarily all of those small practice management vendors and/or EMR/practice management vendors as we emerge in the market.
So a little bit more about what we think the purpose of this summit might be. Number one, to identify realistic industry compliance dates that are achievable by the industry stakeholders. This would allow time for gap analysis, for looking at current systems, for business and work flow, which has been briefly mentioned in some prior testimony but I think is a discussion unto itself, operations with the new rule requirements, and to insure that the required steps are identified and that compliance will be achieved.
We would also like to suggest secondly that this summit identify and clearly link the activities and dependencies with key milestones required to achieve these realistic compliance dates. This is project management 101, finish to start, concurrent activity, et cetera, but with multiple players.
For example, we would like to identify the sequence of activities with associated stakeholder responsibility, again as an example. Payors and clearinghouses, clearinghouses being our own group, who receive transactions may be the first group of stakeholders that should reach compliance, so that other stakeholders can insure there is someone to receive the transactions when their systems are in compliance and ready for testing and implementation.
I always use this as my catcher's mitt analogy. There is a whole lot of people out there throwing balls. If nobody can catch it and throw it back, you're not doing much. So this is getting that catcher's mitt ready and then doing the full circle of transactions out and back, compliance along the entire process.
Then, that we align or stagger -- I know those words are contradictory, but I think we really mean stagger -- the compliance date to conform with a realistic project plan. When we say stagger, we like to stress looking at staggering by stakeholder type, as we just suggested in the prior example, and by transaction type.
A couple of other key points to consider. Some of these are a recap. This summit would help us take a look at the adequate time requirements for analysis, coding and testing, testing at every level including unit testing and alpha testing. We also would like to have the software vendors have time for beta testing with their trading partners. We would like to look at that time of rollout from software of the vendors to their customers, which I personally believe is completely overlooked in our planning, at the multi month; it is not a year plus process for people to get versions and download it and put it in.
We would like to insure that providers and payors have the time to test internally and then tap into that full life cycle. We would like to insure that there is adequate time to test externally with trading partners and then to test the transaction flow when all of the pieces of software are in place for all the different players.
Finally, perhaps our major point, we would like to see this have some sort of pilot testing prior to the deadline date. The pilot testing has been discussed now from several different perspectives, so I think you are hearing consensus from yesterday and today that some sort of phase of something before drop dead would be helpful, but I certainly understand the common questions from the committee here, that how do you ever create a drop dead and an interim drop dead. It is a difficult problem that we are tackling with here.
One thing we might look at is something like a connect-a-thon that has been had for IHE, something like that, that could be used as a pilot test. There have been some other suggestions mentioned by other parties here, but that could congeal or come together with this idea.
So to summarize, no comment on NCPDP D.0. We support moving to 5010. We see it as an improvement, and that is why we support it, with the caveat that we urge that the compliance deadline must be realistic and we have offered up a suggestion for something that might help to create that. That happened prior to the final rule, such that the drop dead, but come out in the prior rule guided by this summit process, this industry wide sharing process.
You have my information. I'll be happy to take questions when you are ready.
MR. REYNOLDS: Good, thank you. Margaret, welcome back.
MS. WEIKER: Thanks. I'm Margaret Weiker. I am the Director of the ETS Business Exchange Services product, which provides scalable B to B solutions and services that allow our clients to better communicate, connect and exchange data with our trading partners. In the health care industry sector, this product is a clearinghouse.
ETS is the leader in transforming the health care industry to our products and services, aimed at reducing costs, driving quality and improving lives. ETS has been delivering solutions to the health care market for almost 45 years. With more than 7500 health care employees dedicated to serving approximately 250 clients in 21 countries, ETS touches more than 200 million patient lives daily through our services and solutions. Our clinical and administrative applications support 38.4 million patient visits per year, and we perform 2.4 billion health care transactions annually, including one billion in health care claims.
ETS supports the adoption of the following HIPAA standards: The ASC X12 version 5010 transactions and the NCPDP telecommunications standard version D.0, that standard version 1.2 and the Medicaid segregation standard version 3.0.
The primary value in moving to the next versions will be the ability to process ICD-10 codes, bringing the level of detail and severity needed to handle medical management and reporting needs. The new versions must be in production and precede the adoption of ICD-10.
In addition, the current transactions are over six years old, with approximately one thousand industry change requests submitted via the DSMO and directly to the standards organizations. These changes will reduce the number of work-arounds and improve the usefulness of the transactions.
For example, the ASC X12 and 278 is rarely used today due to the inability to submit payor required data for prior authorization. Other examples include work-arounds for anesthesia data in the 837 professionals, dental servicing provide address in the 837 dental. Sequencing of loops and inconsistencies of situations has required extra mapping efforts. Support of the MPI, multiple methods of submitting compound drug claims, coordination of benefits processing and Medicare Part D processing.
The final rule needs to establish a clear timetable and milestone targets with a turnkey approach to implementation. A phased implementation approach introduces additional support and cost as old software is maintained and additional conversion bridges are built to support the phases. An overall industry implementation plan would create severe coordination problems, and the whole implementation process would only proceed at the rate of the slowest adopter. Establishing realistic dates and adhering to them is the best way to insure the necessary budget allocations and work, including translation, validation, software vendor readiness, is accomplished.
Readiness can be tracked through the reporting of testing results and dates to a third party entity such as WIDI or the FDOs. A set of complex test cases and transactions would be useful for internal testing.
While there may be overlap with other HIPAA changes or other health care initiatives, this will always be the case, and there is no best time to begin other than now. Most vendors will need nine to 18 months to incorporate the changes into their products, and covered entities will need nine to 12 months after vendor readiness to install, integrate and test before the compliance date.
It is critical that education and outreach begin immediately. While all parties involved should be more aware of the size of the tasks and dependencies, detailed analysis is needed in order to properly allocate budgets, resources and plan for system changes. A CMS weekly e-mail newsletter or notification containing key postings and/or URLs would be beneficial to the industry as well as the HIPAA list serve with a robust section. The standards bodies would be responsible for addressing questions surrounding the standards.
The biggest mistake to avoid in the next version of the HIPAA transaction sets is the introduction of the addenda version at the 11th hour in an indeterminate time frame. By creating a long term schedule and sticking to it, all vendors and covered entities will benefit. The long term schedule would establish the adoption every X or N years of a new version of the ASC X12 and NCPDP transactions, which would allow for planning, budgeting, staffing and execution to be approached in a deliberative rather than a relative fashion.
In conclusion, I would like to reiterate that EDS supports the adoption of the next version of the ASC X12N and NCPDP transaction set. We believe the adoption process should begin immediately and that a firm clear timetable be established, adhered to and communicated to the industry.
I would like to thank the subcommittee for the opportunity to testify today, and welcome any questions you may have.
MR. REYNOLDS: Thank you. Linda.
MS. CAMPBELL: Good morning. My name is Linda Campbell, and I am with the James Smith Corporation representing QS-1 Data Systems, which is a pharmacy system vendor, and the Smith Premier Services Division, which is a pharmacy benefits manager. I have had nearby 25 years experience now in the corporation. Eighteen of those years were in the pharmacy sector, developing software. We have as a corporation now over 55 million claims representing well over 7,000 independent pharmacies throughout the country. There are some small chains that we still look upon as being the independent pharmacy arena.
With 23 years of experience dealing with NCPDP, I have represented NCPDP and my corporation as a work group co-chair heavily involved in the process of developing these standards, and I am very proud to be here today to speak to you on behalf of my corporation and NCPDP.
Regarding the benefit that we see to the next version of each of these transactions, I would like to speak specifically to the E1 eligibility verification. We feel that that will bring additional benefits to the pharmacy and help to streamline their processes. The coordination of benefit claims will certainly bring a lot of relief to the pharmacies in being able to submit those information claims correctly and receive correct information back. That will not only benefit the pharmacy, but it will also benefit the patients who are involved in these transactions.
It will also be better to have a new standard way to process the one time fill to the Part D drugs that are not on the new plan's formularies. That is creating an enormous workload for the pharmacies today. We also look forward to the fact that LTC information, more of that information will be embedded in the claims, which will also facilitate their processing, the claims submission and the reporting after the fact of information.
We currently have transactions programmed into the systems, but we do not feel that they are being utilized very heavily. Specifically the B3 rebill transaction is not being used very much at all. Again, that is a process situation we can't control very much at all, but we do recognize that it is not being a large factor in the implementation today. The eligibility transaction verification is also not used very much from the pharmacies, but it is used frequently to the true facilitators. The N1 information reporting is not used by the pharmacies as much either, but it is used between the facilitator and the payor for the Part D information.
We have not made any work-arounds in the processing and the utilization of these standards, but we have had to make work-arounds in the process in the pharmacies themselves. Sometimes that means that we have had to break up transactions and submit them two times just in order to get the information submitted correctly.
Regarding the suggestion that there should be an overall implementation plan to insure successful implementation, I disagree that there should be an overall implementation plan at the industry level, especially if it pertains to the implementation of pharmacy and CPDP D.0. In the pharmacy industry, the sheer volume of the claims being transmitted, combined with the fact that the pharmacies will not dispense the medication to the patient without having received a reply from the claims processor regarding the proper copay and payment information, has caused a lot of the pharmacy software vendors, pharmacies and PDM claim processors to have time to conduct a slow and methodical implementation. The initial test period should include voluntary participation by payors and pharmacies, using a mix of CANS tests, ones that we have designed that we know will test our systems and the processes that are involved completely.
We also should insure that certain scenarios and claim types are tested, but we also need to make sure that we allow the pharmacies to process the claims as they know them to exist. Ideally, periods of several days worth of claims should also be able to be reprocessed to compare the actual results with those of the test system, giving everyone an ability to compare results and justify or correct any differences.
In the next phase of the testing period, I envision a phased-in approach with a few test sites, payors and pharmacies b being both represented, using live data, real processing. Those live tests should be conducted for at least three payment cycles to allow for the complete claims submission and claim payment cycle, using the 835 or paper remittance process, to be completed. After a test period of actual implementation such as I described, any problems or issues resulting from deficiencies or errors in the standard should be able to be corrected or changed as necessary before having the standard mandated by CMS.
Software vendors have commitments to their software users and customers to maintain their compliance with the NCPDP standards. They all must incorporate the standards into their software systems, otherwise they would not be able to sell their software to the pharmacies. That being said, the magnitude of the project to prepare the software systems to make use of the new standard, while still supporting the old standard, will differ from one vendor to the other. That is not something we can predict, because we must also remember that these claims systems that are active and utilized in the pharmacies and in the PBM processors today are part of an all-encompassing business process system, so there is much more going on in that system than just claims.
QS-1 and Smith Premier Services have a long track record of always being ready to test the new version of the standard as soon as there are pharmacies, payors and processors willing to work with us. What we cannot be controlling of is the cost and the time involved at the pharmacy level to update their computer systems due to the unique factors at each pharmacy. Many of the other panel members today have spoken to this issue, but it cannot be disregarded that we are especially in my corporation representing pharmacists who must pay for the pharmacy upgrades other than being software upgrades or even computer upgrades because their system -- as you know when you have a home system yourself and you want to upgrade to the new Vista, maybe the actually computer itself will not incorporate it, it just can't run on it, so you have to buy a whole new computer system. We face that same issue with the pharmacies. They sometimes are working with three year old or older pharmacy system computers that do not contain the space nor the memory to accelerate that system up to a new version. So there is a lot of cost involved even down at the lower pharmacy level.
Regarding a phased implementation, controlling of a phased implementation should be mandated -- I do not believe we should be mandating that, but especially not by transaction. That will unnecessarily complicate things. It will be extremely confusing to the pharmacies, and I think it will also cause more errors. The end result, we are complicating and unnecessarily aggravating the people that we serve the most, and that is the patients who are entering our pharmacies to receive these medications.
I prefer to allow testing first by those willing to participate and share results with those in the industry regarding any issues needing attention and changes that must be made in the standard, and then let the natural market forces work to roll out the changes. Of course, some future date must be mandated by which all entities must be using the new standard, but we must keep in mind that other factors are involved, not the least of which are the right now expenditures to be borne by the pharmacies, system vendors and processors for software, programming, computer upgrades and the like. These expenses can be significant and have to be considered when setting your compliance dates.
It is impossible to declare that everyone in the entire industry must begin the use of a new standard on a particular day. We have dealt with phasing through natural business and industry processes for over 20 years now. Controlled phasing would unnecessarily increase the cost of support and definitely create confusion throughout the industry.
As far as my company is concerned, we have extensive abilities to conduct internal testing, including comparisons of data from existing live systems which would be reprocessed under newer systems and claims standards to insure like results.
We have participated in external testing with our partners in the NCPDP industry. As Annette Gabel from MEDCO alluded to earlier this morning, we have had great results by collaborating and working together to try and insure that our pharmacy systems are operating correctly, our PBM systems are operating correctly, payments are made, reversals are processed, and we have the liberty, especially with the 3.1 version which was many years ago, of making the modifications we found necessary, so that we weren't all forced to utilize a standard which had some errors and deficiencies in it.
It is hard to predict the time period necessary to insure complete testing of a new standard. Not every situation can be simulated in a test situation. However, once alpha testing has been completed, beta testing can be implemented. Pilots should again be long enough to insure that all the back end processes are also working properly and in concert with the new standard.
I am going to skip numbers seven and eight, because we have touched on that, and in the interest of time we have all spoken to the need for everybody to be able to test and make modifications.
Regarding tracking the progress of vendors and other entities, while you can have some mechanism by which vendors and entities can report their progress, I firmly believe that the natural marketplace forces, competition between vendors, data needs of the processors and other continuous software updates, have facilitated the natural migration to the newer versions of the standards. Vendors and processors may be ready to process claims using a new standard, but until the pharmacies upgrade their systems to be able to provide claims in the new system, nothing will happen.
What is most important to monitor and measure in terms of the readiness? The measures are different for every entity, however, the bottom line is, are we processing claims correctly, are we sending responses back correctly to the pharmacies to convey the information that needs to be conveyed, and is it correct, and are we able to report our payments correctly, deposit the money correctly, provide the correct remittance advices. All of that has a bearing, and some of that is not even addressed or hasn't been addressed when we first went into HIPAA 5.1.
How can an application vendor demonstrate that their software can process the standard? The only way to demonstrate that is to test. I have always found that the vendors have been eager to test their software. We must keep in mind that when a prospective customer is reviewing a vendor's system for purchase, one of the questions that is always asked is, are they compliant with the newest version of the standard. You are not able to sell your system if you cannot answer that question correctly.
What is the impact of a vendor not being a covered entity? I don't see that there is an impact. It has been a very few times that a pharmacy system processor has not wanted to test with QS-1 because we haven't been a covered entity. We have gotten over that speed bump in the road, and been able to continue along. But I don't see that a pharmacy system vendor nor a PBM needs to be a covered entity.
As far as education is concerned, while it is beneficial to have listserves and white papers and information and education coming out from NCPDP, regarding the pharmacies, they look to their pharmacy system vendor for their source of knowledge and information.
How does that pharmacy system vendor become an expert in what is going on with the standard and how to translate that information down to the pharmacy? I feel that it is imperative that the organizations, the standards developing organizations be that resource tool. I find from my own experience with over 20 years of experience in NCPDP, that NCPDP is definitely a resource tool for everyone in the industry to gain information about utilization of standards, but you cannot substitute pieces of paper or websites and telephone calls for the actual participation in the organization. People need to get in and have a voice. I think NCPDP has been extremely open and accommodating, so that we make sure that we do find consensus.
I think that regarding the changes that we see coming along in D.0, while it is hard for any company to justify modifying their software to accommodate changes, we need to do it in order to be compliant and be able to market our software system. So in the end result, we look forward to implementing D.0, because it will streamline the processes in the pharmacy and make things easier for our constituents that utilize our software systems.
The mistakes HIPAA again have already been alluded to by the other panelists. They were now allowing enough time to test the standard, and not allowing us to modify the standard and correct problems that we saw in our testing. So I implore you to allow us to begin the testing with D.0 and to have the opportunity to correct and modify where we see needed.
The time period needed? We don't know. We have created a standard that we felt in our infinite wisdom would address the needs of the industry, but until we begin to utilize the standard and see how it looks within the process -- because pharmacies being an online real time claim happening in three or four seconds, it is an entire process, so we need to make sure that we haven't adversely impacted that process, that we have not only improved it, but we have helped it along the way to utilize and helped the patient. That is the bottom line here.
In conclusion, I thank you for the opportunity to testify, and I am open to any questions that you might have.
MR. REYNOLDS: Thanks to everyone. I am going to ask a question this time, because I need some clarification. As each of you were discussing, you said the right amount of time, the right sequencing, the right testing, pilot testing and other things. Margaret was the only one that put a time frame in the ground.
We heard earlier throughout the last two days, two years from the time of the final rule and so on. So as this panel has presented it very logically using Chris' earlier IT 101, but as you look across the whole industry, the right amount of time for testing and the right sequencing and others is in the eye of the beholder a lot of times.
So if any of you can go one step further and talk about time frames, because on the one hand we hear two years and that may be too short. If the word proper is thrown in, there is no time frame, because proper may be in the eye of each beholder.
Then the other thing -- and I really appreciate the aggressive positions; that is part of what is very helpful to us also. But as we have written our letter at NCVHS, and not everybody is using all the transactions, so if you have the proper amount of time, do you have any idea if that will improve the number of people that would use all the transactions, which as our letter said may return a better ROI than if we took longer or did what we did. So I open that to the panel for discussion.
MS. CAMPBELL: I think that utilization of all of the transaction standards is independent of our ability to predict. It depends on your business need, and that will depend on the vendor and what specific market niche they address.
Regarding the time for testing and then final implementation, I think we have all touched on the fact that it must include all facets, so therefore in my time period it has got to be at least three cycles, a billing, a payment and a reversal cycle. We are looking at testing amongst our industry players of at least three months in order to allow that cycle process to completely play out.
But that is just testing. If we have any modifications that we have to make to correct, then we are looking at at least several more months. I think you need to at least allow for 12 to 18 months for that testing and final standards development process to take place, and then the implementation time frame, I think it is safe to say, depending on vendor specifics, 12 to 24 months for them to be able to incorporate those changes and begin to work them out. Then we have the unpredictable factor of what time frame is involved in getting it to be installed in the marketplace itself. You always have your early adopters. Then you have the ones that say it didn't hurt several hundred sites, now I can implement. Then you always are going to have the people you have to drag kicking and screaming to the table. But without some time period to force those people there, they would never be there.
Margaret, do you have any other things to add there?
MS. WEIKER: Our comment about getting a summit together and having input prior to the final rule is to answer that question more precisely, Harry, by taking into account what is reasonable from each stakeholder's perspective, and then trying to map that to a master schedule -- I know it sounds very aggressive, but to try to map that to a master schedule that would have dependencies.
We know it would be a subset of people that we might be able to get together, and they probably would be the early adopters. But it would at least be a comprehensive view of deadlines that are laid side by side and then interlinked where the dependencies would be, such that you could say when you calculate that out, it is three years and two months, or it is four years and 18 days, whatever it would be. But that would be one of our hopes for that outcome.
MR. HERALD: I guess my only comment goes back to part of our testimony. That is, if we can define the world in which we will live once the standards are fully implemented, and what value we are creating, I think that the process can speed up or slow down as a result of that incentive being in place. An incentive doesn't have to be cash paid out to a contractor or to a pharmacy or to a software company. It can be in the form of other types of incentives.
For example, if you have adopted the 5010, then you will not be subject to having to complete a companion guide alteration for -- I don't mean to pick on Blue Cross Blue Shield, but Blue Cross Blue Shield of the 54th state or whatever, we don't pick on anybody, but if there is some incentive there, it will bring the players to the table more readily.
Basically we are all in private businesses here, trying to make a profit and pay taxes. So with the taxpayers as the largest purchasers of health care in the country, they tend to drive a lot of the market. But even they contract with private companies to process claims.
So whatever the return is going to be, there must be some kind of value out there and if there isn't, then nobody is going to want to make it happen, anyway.
DR. COHN: I am listening to the conversation, and I just had a question or two about all of this stuff. The vision of HIPAA, I just want to remind you of at least what was contemplated, was that there was going to be this big initial implementation, and then on a predicable basis, every year, two, every three years, taking some defined length of time, not multiple years, to implement, there would be updates that people would be able to accommodate.
Now, so far what we are talking about is an update. We are not talking about the penultimate, we are not including ten or 12 new administrative transactions. Yet I am hearing multi-year implementations, I am hearing things that are making me wonder whether two years is enough. Maybe we need five years for this implementation, based on some of the conversations.
I contrast g with the fact that each of you, and actually everybody in the country deals with new versions of ICD and CPT every year. They get them around now, and somehow are able to implement them by the end of the year. The whole industry doesn't fall apart, doesn't come to a screeching halt. So maybe you can help inform me of your views on this. There is this general disconnect. Maybe you can help clarify this one for me.
MS. WEIKER: It goes back to a predictable process. I have implemented CPT, ICD 20 years ago, and every year in May or in April I know I am going to get this update that I have to take the process and blah, blah, blah. It is predictable.
We basically know the type of changes that are going to be made, new codes are going to be added, some are going to be deleted, some may be changed, kind of thing. We are going as an example from like 4010A1 to 5010. This isn't just a year's worth of changes that have been made to these guides.
For NCPDP D.0 this is like five years worth of changes that are being incorporated. Some are very major changes. For example, NCPDP has removed the optionality from all of its fields except for a few defined specific situations. So payors hopefully paid enough attention when those guides were balloted to make sure their business needs could be met by the situation.
The 278 is basically an unusable transaction as it exists today. What we have done is, we will accept it, but we give a canned response because we can't process it, because it doesn't have the data that is required to do a prior all. So it is like, now I have got to go -- and we will gladly automate and re-engineer. It will save money to do that, which is why we would need some of these new versions and some of these new changes.
It is just, the others are very predictable, very timely. You know when it is going to happen. You know it is a year's worth of changes, you understand. Now we are looking at at least five years worth of changes and a thousand different types of changes. It is a massive undertaking.
MS. CAMPBELL: If I could add to that, Simon, you speak to the ICD-10 changes; those are more or less file changes, whereas the changes that we are looking at with X12 and D.0, they are process changes. So they are not just an expansion from 50 records to 60 or you delete a few. It is whole processes involving the pharmacy or the medical practice, whichever.
MR. REYNOLDS: George, you had a question? If you would introduce yourself, please?
MR. ARGUS: Sure. My name is George Argus, and I am with the American Hospital Association. I have a question for the vendor panel. I know when we first were introduced to the HIPAA standards some years ago, there was a lot of talk about translation software and the focus of translation software in helping to deal with moving from one version to the other.
I'd like to know what your thoughts are around the use of translation software to make that change, and whether the vendors themselves would support the current version as well as the previous version during the implementation period or migration period.
MS. WEIKER: I know that we will support both versions at the same time. We do use some third party tools in our solutions. When you look at translators you have a variation of what they do and how they support. Some will take the base X12 standard which these HIPAA implementation guides are based on, and just do that. Then you have to go in and make some modifications to that. Others will incorporate those actual TR-3's into their products, to where you don't have to go in and code it yourself, so to speak.
So there is a different variation based upon some of those third party tools, but I know that we will support both versions at the same time. It is going to be necessary, because not everybody is going to be ready at the same time no matter what. MS. CAMPBELL: And not all vendors use translators, either, at least third party solutions. They may write something that, yes, technically we could call it a translator, but not everybody uses them. But yes, we need as Margaret says to support versions of the standard for some period of time. At some time it becomes prudent to discontinue the use of an old version, but that is certainly not even within a six-month time period. That is probably 18 months or longer, way longer, to support an old standard.
MS. PARAMORE: George, I think from the HEMS Affect perspective, most of our members who are clearinghouses and translators by their nature are already supporting multiple formats. Some are 4010, some are 4010A1. Then you have got the 31 flavors of the companion guides, the permutations back and forth.
So it would certainly be inside the standard business model to create and to retain the ability to translate between multiple versions.
MR. ARGUS: This is helpful for me just to understand, but I just wonder whether this would help mitigate the difficulties in moving to a new time period.
MS. PARAMORE: It is ironic if that would be the case. One of the promises of administrative simplification is the need for less translation between Egyptian and English and French and Spanish and whatever. But I think it would still be possible. There are certainly lots of third party stand-alone translator software vendors who will be in the business of helping to make that happen.
DR. WARREN: Mine is for Margaret. In your testimony, Margaret, you said that one of the ways we could predictability of change is within the standards themselves, roll them out on a certain time schedule.
One of the things that has hit me in all the presentations is the number of changes between 4010 and 5010. How would the standards organizations go about figuring a predictable rollout of these changes?
MS. WEIKER: You go back to our streamlining paper that we developed, X12, NCPDP and HL7. We each had that project plan. We each looked at the project plan that was in there and said, we can all basically adhere to this. There is a little bit of difference in some of the processes and procedures with each organization in regard to balloting versus public comment periods and those type of things.
I know from an NCPDP point of view, we can basically put out a standard once a quarter. We do it today. But nobody is going to implement it because of HIPAA unless there are other business needs, workers compensation, those type of things.
So I am going to refer back to that streamlining paper that says we can get this predictable. We are willing to get this predictable. Our membership wants it predictable. We just need to figure out how to get that done either through legislation, rulemaking or whatever. Even if it is every two years we can put out new standards, so to speak. This major upheaval that we are all hearing about and even talking about ourselves doesn't exist anymore. It becomes an ICD update, a CPT update, an NBC update versus the sky falling.
MR. STEINDEL: I really don't have a question, I just have an observation. I appreciate what this panel has illuminated from the vendor perspective and everything. But the one thing I would like to note, and this has been a common theme starting yesterday and I will just abbreviate it very simply, that is, when we consider making recommendations, one thing that should come across very clearly is that we should ask for test, test and then test again. I think that has been the very clear statement that has come across from everybody concerning the past implementation of HIPAA, that there was not enough time to allow for testing before systems went live.
DR. BLAIR: Miriam, I was really impressed by your idea of trying to set up some entity to provide some coordination of the testing. We have heard all of the different levels of testing. In the 5010 we have got eight or nine different standards, not just one. You have got different aspects or use cases that might be involved.
I can't see how this can be done without some entity coordinating the testing of the 837, the 835, the 270, without some entity coordinating this it just looks to me like it would be just a prescription for further delays and frustration.
I'm not sure what entity that should be. I think there is a number of candidates that could possibly play that role, whether it is HEMS or WIDI or whether even the SDOs themselves might be able to be part of that.
But the other observation that I had as I was listening to you, I'm afraid that if we want it to be done in a two or three year time frame, with all of the steps that are involved and all of the different industry segments that have to work together and all of the investments that have to take place, I'm concerned that the coordinating entity could do it strictly calling on volunteers. I think there needs to be some financial support for that coordinating entity during this transformation process.
May I have the reaction of the panelists to the observations that I just made?
MS. PARAMORE: I would agree that having that staffed voluntarily, whatever that overarching entity might be, would be a particular challenge. I can speak from very relevant experience in the Louisville Health Information Exchange, which is completely voluntary and coordinates all stakeholders in the industry without staff, but it is only for one city. It is extremely time consuming to get that group together to talk about what we are doing in our home town.
So I agree. I'm not sure where that funding support to have the machine would come from. We did not approach that in our comments, as you noted. I'm not exactly sure either who the convening body might be. But HEMS Affect would be happy to take a leadership role in whatever might come from this to help to make that happen. It could certainly put together some financial budget projections or something based on numerous experiences with HEIs and convening bodies that we have done in other arenas. So I would offer that perhaps as some additional research we would be willing to supply to the committee if you would like.
DR. BLAIR: Can any other panelists give us feedback on this?
MR. USRY: This is Richard Usry with HBMA. The testing certainly is one of the most important facets of going through this process, whether it be the 5010, the modification of the 4010 or whatever. The idea of having a testing organization that would monitor that capability could be a very useful tool for everybody in the industry.
The problem that I see is, it becomes an enormous -- like a blooming onion, it has got tentacles everywhere. But it has to have the ability -- and I am not as privy to the pharmacy operation as these people are, because we don't deal in it in our industry, but from the standpoint of the pharmacy and all the tentacles that have got to go out once you do some testing and they go out, it just becomes enormous to get down to the individual mom and pop pharmacy that has got to validate the transaction and issue the prescription. So that entity could just be huge.
But in looking at this whole process of the 5010 versus the 4010 versus the 4010A1, the 5010 in our opinion from the HBMA standpoint is, the 5010 that affects us is merely additional data elements that need to be added. It is not changing the whole schema from the beginning. It is just adding data elements. That is all this is.
Now, granted you are going from A standard to standard B. But it is just adding data elements, that is all it is doing. It is not restructuring the entire operation. It is not starting from scratch and coming out with a new implementation. It is adding data elements. It is like you order a car and you decide at the last minute, I want this added. Well, if you order from General Motors, they got it in their computer system, they add this change, and then somehow it appears on the end product at the end. That to me is what we are doing here.
Now, granted there are transactional information that is needed in these other industries to accommodate things. But a lot of them are just adding information. You said the 278 is not valid today because you don't have this additional information. Add the piece of information. Why have a new standard? Let's add the information and add it to the transaction set. It is a fairly simple change. It is not rewriting software from scratch. It is adding a data field.
When we talk about the ICD-10, there is no reason, no reason that the ICD-10 can't be put into 4010A1. There is no reason. Yes, you may need a category code. Add it in the data element, but why reinvent the wheel? Just add the data elements. That is the way we look at it. If we have got to modify something, modify it and move forward. We are talking about coming up with new deadlines in two years and three years and five years or whatever it is. It just doesn't make sense to me. I have been developing software for over 30 years, and I don't see it. I just don't see it, I'm sorry.
MR. HERALD: The only comment I wanted to add was, if we are going to find an oversight committee, coalition, what have you, I think soon the world is going to run out of these vernaculars of HEMS and Affects and CCHITs and the ABC soup. Let's just find one that is willing to take it on that already exists so a new infrastructure doesn't have to be created in order to oversee it.
HBMA sits on a health care administrative simplification coalition. It is an initiative from MGMA. Everybody can think of a great reason why that should exist. Here we are in the nation's capital; you can probably find hundreds of associations of all these different industries that sprout up just as a result of a panel that interviews the industry.
I like Mariam's idea. Let's find someone who has a passion for it, champion it and then make sense out of it. That is my only comment to Jeffrey.
MR. REYNOLDS: Don Bechtel, you have the last comment, question, whatever you are here for.
MR. BECHTEL: I'll try to be brief. I know we are ready for lunch. I came up here with one question, and after listening to the last comment I have two questions or comments to make, probably more comments than questions.
The first comment in response to the last person speaking. The 5010 changes are pretty much what he was asking for. When we look at 4010 and we want to make a change to it, we do just that. We change the 4010 standard to accommodate what we need. But we can't call it 4010 anymore. We have to move it to a new version because of the way the standards are constructed.
There is a great deal of technology behind the creation and development and delivery of standards in our industry than just simply adding a data field to it or adding a component to it or even adding a data value to a code set. These things are contained in databases that are versions so that we have consistency in our industry as to how a version exists. If you want to add something to a previous version, you are creating a new version. This is how the business works.
I would also point out that even a very simple change like adding a qualifier to an existing version requires significant industry change. It requires changes at the vendor level, it requires changes at the user level, it requires changes at all the implementations of that software to support it. So no matter how we try to do this, there is change.
Yes, we want to minimize it. I think that is why the SDOs are asking for more frequent updates that is more timely and predictable, so that we don't have these large gaps and tremendously large amounts of change. But we can't do the laser surgery that we were asked about yesterday.
The other comment that I wanted to make. I have listened today to a couple of speakers suggest that there is no benefit to 5010, and they don't wish to move forward, or the would like not to. I want to ask the question, what is the alternative?
When we think about changes to standards that have no benefits, the industry for health care is larger than just one segment. We have an X12, we have HL7 or NCPDP, many constituents of our industry there, and they represent the payors, the providers, the clearinghouses, the vendors, the billing services, whatever, and they want to make a change. They need to have a modification to support a new business requirement or to add data that they are required by regulation or whatever. They have to come to X12 and ask for it, and X12 will accommodate those changes. But if we don't implement them, what is going to happen? Where will these people go if they need to have business improvements or business data that they don't have today, and we don't accommodate by implementing the changes that they have come and looked at at the SDO table, we are setting ourselves up for some alternative. We will see more companion guides come out to accommodate the need.
When you can't address it with a companion guide because the standard no longer supports it, you are going to see proprietary standards come out, or modifications to the standard that aren't the standard at all anymore. I don't think it is sending us in the right direction.
I think what we really need to consider is, modifications to standards represent the broader good of the industry, and they are all constituents who benefit from these. I think there is tremendous benefit on the provider side. There is clearly a benefit on the payor side for these standard changes that we are proposing. Vendors and service organizations perhaps rarely see real significant benefit from this, other than we can provide the services to our customers who will benefit from it. I think that is the point I wanted to relate to.
MR. USRY: Don, I understand what you are saying about standards, I understand that, but what we look at is, what is the end point, when is it going to stop? When are we going to have the final standard? Give us the final standard and let us implement that, and take the two years, three years. But if every couple of years we have got a new standard to implement, then we are back at this type of meeting going through the same process. She is saying one thing, she is saying one thing, she is saying something else, and it is just a never-ending product.
Give us the final. Tell us what the final standard is. Then let us implement that. Granted, there is a difference between adding a field and a version, but all we are doing here with 5010 -- and you have to be honest about this -- is adding data sets, adding fields. We are not rewriting it, we are just adding fields. That is all we are doing.
So what we need to see is what is our return on investment. Yes, there is some return on investment in the pharmacy system, I'll grant you that. Yes, there is maybe return on investment in some of the transaction sets. But it is working right now except for some of these areas that they need data. It is just a data element. Add the data element. Give them the ability. Call it A2, call it A6, whatever you want to call it, but why reinvent and go through implementation and go through all this stuff? It just doesn't make sense. There is a lot of cost being implemented that I don't see is needed.
MR. REYNOLDS: With that comment, we will break until 1:30 by this clock.
(The meeting recessed for lunch at 12:24 p.m., to reconvene at 1:25 p.m.)
Agenda Item: 5010 Provider/Pharmacist Panel
MR. REYNOLDS: Welcome back. Our first panel this afternoon is the provider/pharmacist panel. We have from the American Dental Association Robert Ahlstrom, from the AHA Karen Raines, and from the MGMA Larrie Dawkins. So we will just go ahead and go in order on the agenda, unless you guys have worked some other agenda out. If you would start, Robert, we would appreciate it.
MR. AHLSTROM: Thank you very much. Mr. Blair, Mr. Reynolds and members of the subcommittee, I want to thank you as a member of the American Dental Association testifying on the issues related to the successful migration of the next version of the HIPAA standards.
My name is Robert Ahlstrom. I am a practicing dentist from Reno, Nevada. I have been doing this for 30 years. I have recently transitioned to teaching fulltime, so I have a different perspective, one from an old time practitioner and then seeing what our young students are doing.
The ADA is one of the world's oldest and largest dental professional associations, and it represents over 150,000 dentists, or almost 72 percent of those dentists in clinical practice. Since HIPAA was signed into law in 1996, the ADA has been monitoring the development and adoption of these regulations. Through our Division of Dental Practices and Office of Standards Administration, we participate in the standards making process to insure that the interests of dentistry are incorporated into health related standards. We are continually researching and developing resources to help dentists make informed decisions on managing their practice and providing for the oral health care of patients.
Taking the subcommittee's questions in order, the first one deals with business benefit and other transactions that are currently implemented but have limited or decreased utilization than other transactions. Potentially there are many benefits to dentists related to the implementation of the HIPAA standard. These are listed, and I would just highlight probably the bigger ones involved with this.
Dental offices' computer systems will be compatible with those of hospitals, physicians and other plans that conduct business with them. Referral inquiries will be handled easily. However at the present time this is very labor intensive, unreliable and mostly not compatible, and certainly not interoperable.
The other thing that will give us a great deal involved with this is that dentists will have a more complete data set of the patients they are treating, and even better care and decreasing overall administrative costs. This will result in more accurate information hopefully and decrease our errors of admission.
There is also some potential benefits to our patients. Patients who are seeking information on enrollment status or other health care benefits will be given more accurate, complete and easier to understand information. Consumer documents will be made more uniform and easier to read, hopefully. Patients will have the ability to see what is contained in their medical and dental records and who has accessed them. Patient records will adequately be protected through organizational policies and technical security controls. Consumer correspondence with insurers about problems with claims will also be reduced.
However, the ADA does have several concerns regarding the potential migration from version 4010, in particular with the 837 D dental implementation guide for claims. We do want to go on record and indicate that the ADA is currently working collaboratively with X12 and various other industry groups on potential modifications to address some of these concerns.
However, we also believe that NCVHS needs to have a full picture of the potential effects of adopting this new version of the HIPAA standard. First, the ADA asserts that NCVHS and others should note that there are concerns with the coordination process between X12 and content committees that need to be addressed. The ADA believes that this process could be improved and continues to work with other industry groups to look at these concerns.
One of the ways that the ADA believes improvements can happen is through the development of MOUs or memorandum of understanding between the various participating organizations. The ADA is currently working on an MOU with X12N so that the ADA's standards committee on dental informatics will be able to contribute to the content for future dental transactions for X12 messages. This type of a relationship is similar to what we have accomplished with HL7. The SCDI provided the content for the electronic claims attachment and an HL message is now being developed. In addition, HL7 collaborated with SCDI on a harmonization of some of the SCDI and HL7 standards. The ADA also has an MOU in progress with ASTM for the development of other standards.
Second, the development of standards such as the 837D 5010 applies to a defined community of users, i.e., a subset of the whole. That being said, the need for focused expert opinion on the development of such standards must rely on those most affected by them. The ADA believes that there is room for improvement in the development process for such standards. One example that was discussed is the ability to correct the guides in a timely fashion. Third, the ADA is pleased that they have been able to work with X12 and to gain acceptance of our proposal to consider the reference to HCPCS procedure modifiers in the 5010 version of the 837D as a type one errata. I was chairman of the ADA standards committee on dental informatics, and I have to say that this subcommittee has taken some acronyms to levels that we didn't even do in dental informatics. In the original version, the ADA successfully argued that HCPCS modifiers cannot be used with the CDT codes because those modifiers were not approved for use for dental claims and not mentioned as part of other HIPAA regulations as a recognized code set for dental claims. In addition, HCPCS is not included as an external code set in the 5010 837D. However, this process has been resolved, but it still has taken many months to come to a conclusion.
Fourth, the ADA is also collaborating with other X12 groups and industry representatives to address another concern for dentistry. In the 5010 version of 837D, there is a reference to the use of diagnostic codes. Diagnostic codes are not typically applied to dental claims unless the services are covered by a medical plan.
The ADA recognizes the difficulty faced by providers in reporting oral and maxillofacial and dental anesthesia services. However, it maintains that the situational use of diagnostic codes does not address this problem.
The ADA is currently developing a compromise change request for the subsequent version of the standards. However, should the 5010 version be adopted, it will present problems to dentists whose vendors may not be clear as to when diagnostic codes should be used.
The ADA also continues to address other solutions that have been proposed, such as adding tooth numbers or codes for tooth numbers to the 837 professional TR3.
The second question has to do with the overall industry implementation plan. The ADA believes that there should be an overall implementation plan to insure successful integration and migration from version 4010. The ADA also believes that all members of the industry should participate in this process to insure successful implementation.
There is no question that this will be very difficult to do, but we also realize that if this is a phased plan, additional costs will be passed on to the provider instead of a one-time overall cost increase. It seems to me if we are looking at simplification, this would defeat some of the primary edicts of the simplification plan.
What are the milestones for an implementation plan? The ADA believes that there are several concerns related to the issues raised in the questions, as well as others.
Software vendor readiness. Some practice management system vendors have not yet updated their software to include NPI, and may have similar problems with updating the next version of HIPAA standards in a timely manner. In addition, some vendors are not willing to update dental office current versions, and are requiring that dentists purchase new versions of the hardware and software just to accommodate the NPI.
For upgrades to the HIPAA standards, the same situation will present a significant cost to dental offices. One dentist recently contacted the ADA and said the current vendor was not going to update his current version in use today, and instead the dental office would be forced to buy a new system of $30,000 to $40,000 or return to submitting paper claims.
This is not uncommon with the migration that has occurred with practice management spenders in the dental field. There has been a rather substantial group buyout by vendors so that we have a very limited number of dental software vendors.
Phased implementation. The ADA believes that implementing a phased approach to the migration of the standard, either by transaction, industry group or some other classification, would most likely put additional monetary staff and time costs on providers and their offices.
As mentioned earlier, many software vendors are charging dental offices for new systems instead of upgrading existing software. If this is done separately for each transaction, costs would be significant.
Trading partner flexibility. Most of the electronic transactions that are sent from a dental office go through some type of clearinghouse for translation into an appropriate format. The clearinghouse function could be accomplished by routing a claim to the practice management system vendor utilized by the dental office, and then the transaction may go to a clearinghouse or eventually a payor, or the transaction may go from a dental office directly to a clearinghouse.
These vendors are considered trading partners. These trading partners should be capable of transmitting all the appropriate data elements required by most HIPAA standards.
Testing. The ADA does not have the ability to track the status of testing phase for transaction compliance of dental claims. But based on the comments we have received, the ADA believes payors/clearinghouses are behind schedule and believes that there need to be assurances that this will not occur with updated HIPAA standards.
As with any technical or IT development, testing would be appropriate for the majority of SDOs that are developed if these are truly consensus based. However, the cost is an issue that will have to be finalized and worked out.
Payment continuity concerns. Dentists are concerned about several patient issues, including revenue cycle management, payment monitoring and the availability of error resolution plan.
Data requirements. There are also concerns related to new data requirements that will be required with the migration to the next version of the HIPAA standard, including payor crosswalk solutions from version 4010A1 to legacy and other data systems and availability and provider practice management systems.
Once again, I greatly thank you for the opportunity to present information relative to dentistry's position on the migration to the migration of the next HIPAA standards.
MR. REYNOLDS: Thank you, we appreciate it, Robert. Karen.
MS. RAINES: Thank you, Mr. Chairman and members of the Standards and Security Subcommittee. My name is Karen Raines, Assistant Vice President of Regulatory Compliance Support for the Hospital Corporation of America, commonly known as HCA.
HCA is the nation's largest nongovernmental system with 173 hospitals and other health care facilities. HCA is an active member of the American Hospital Association and the Federation of American Hospitals. Also, I represent the Federation on the National Uniform Billing Committee.
I would like to thank you for the opportunity to present testimony today on ASC, X12N, 5010 standards. HCA believes 5010 contains many improvements to the current standards. One of the key benefits of 5010 is facilitating ICD-10DM and ICD-10PCS. Also, we believe the more definitive language in 5010 will eliminate many of the variances in interpretation in health plan companion guides today.
The new standards should be adopted as the replacement to 4010 and 4010A1 as soon as possible. At HCA, we can support 5010 electronic claims attachments, ICD-10, the implementation of the national health plan identifier and other regulatory requirements as final rules are published.
An industry wide implementation plan should be set forth in regulations. Thes should include requirements with regard to testing and should contain a clear timetable for implementation. It appears that CMS' best position to track progress regarding implementation and to provide education, perhaps using the listserve process.
As further background for the subcommittee, HCA outsources our support of the 837 claim to an external billing vendor. External billing vendors will not begin the process of implementing new standards until definitive guidance is published by HHS. These billing vendors have the most insight as to individual provider and payor readiness when standards change.
With regards to the electronic remittance, we support much of that work internally. While we transitioned our hospitals to the current version of the 835 electronic remittance advice, consistent with the pace outlined by the health plans, it took over two years for HCA to migrate to the current standard. As recently as six months ago, we worked jointly with the health plans to revise lingering issues with the implementation of 4010 and 4010A1.
Extensive end to end testing is critical to the successful implementation of 5010. Health plans have been reluctant to test the providers, as evidenced by both the current test and the NPI. Health plans need encouragement to be cooperative with such testing.
We encourage the publication of an NPRM to address the adoption of 5010 by the end of this year, with the final rule being published in early 2008 and a compliance date of 2010. A 2010 compliance date for 5010 permits transition to the next version of the HIPAA standards one year ahead of implementing ICD-10.
A phased transition to 5010, similar to what the NUBC approved for the EBF4 could be considered as an option. Health plans, clearinghouses and vendors should be required to transition first, followed by a dual use period and a mandatory compliance date for all covered entities.
Enforcement of the compliance date is of greatest importance. With EBF4, some state Medicaid programs still cannot project an implementation date. State governments must insure Medicaid programs transition according to schedule with 5010.
In conclusion, we are supportive of the adoption of the next version of the new transaction standard. Thank you again for the opportunity to provide testimony today, and I welcome any questions you may have.
MR. REYNOLDS: Thank you very much. Both of those were very concise and insightful. Larrie Dawkins.
MR. DAWKINS: Mr. Chairman and members of the committee, the Medical Group Management Association, MGMA, is pleased to submit testimony to the National Committee on Vital and Health Statistics Subcommittee on Standards and Security. My name is Larrie Dawkins. I am the chief compliance officer for Wake Forest University Health Sciences in Wake Forest University, located in Winston-Salem, North Carolina. I have spent 35 years in medical group practice and compliance and regulatory affairs.
MGMA was founded in 1926 as the nation's principal voice for medical group practice. MGMA represents nearly 21,000 managers who lead some 12,500 organizations and have 270,000 physicians practicing in those organizations. Approximately 80 percent of the MGMA members practice in ten physicians or fewer as far as group size is concerned.
In my testimony today, I will focus my attention on the issue of the forthcoming implementation of the 5010 version of the electronic transactions mandated as part of HIPAA. In addition to looking back at the physician practice experience with the implementation of the 4010 version of the transaction standards and the national provider identifier, we will also look ahead and offer a series of recommendations that may assist the industry in implementing the new 5010 version of the transactions.
If there is a theme to my presentation today, it is that 5010 is a clear improvement over 4010A1 and is needed, but if it is not implemented appropriately and in a cost effective manner, it will create additional and significant burden on providers, especially small and medium-sized physician practices. It is not a question of, should we change, it is a question of managing the change.
Why do we need 5010 transactions? Almost as soon as we had done 4010, the regulations were released, and it appeared that there were many problems that needed to be solved and modifications that needed to occur. In the period, designated standards and maintenance organizations, DSMOs, along with X12, have reviewed nearly a thousand industry change requests. Countless hours from dedicated DSMO volunteers have produced a superior set of HIPAA and non-HIPAA electronic transactions.
The 5010 version addresses many of the problems encountered with the 4010A1 version. We believe that moving to the 5010 transaction will produce an augmented and clear set of implementation instructions, improved data content and business functions, important clarifications of NPI instructions, cross transaction consistency, more consistent implementation by trading partners, reducing the reliance on proprietary trading guides, support for the potential move to ICD-10 codes, and enhanced industry consensus on critical transactions.
With many covered entities unable to meet the original 4010 compliance date, CMS responded by issuing first an extension and then a contingency plan for all transactions. In addition, the contingency plans are still in effect for some of these standards.
Why was the industry unable to meet the deadline? From our perspective, the lack of education and outreach from CMS, difficulty in securing provider buy-in. Reliance on non-covered entities for compliance was a major concern. Providers found out very quickly that their practice management vendor and billing system vendors are critical partners in the compliance effort. Unfortunately, these vendors typically are not covered entities and in many cases move slowly to upgrade the provider systems. These upgrades in many cases were expensive, and in some cases vendors would not upgrade older versions of their software, forcing practices to purchase the newest versions of their software. Providers also encountered vendors that refused to allow the vendor to go directly to health plans with their transactions, but instead wanted them to use proprietary clearinghouses, and of course incurring fees for these transactions.
Proprietary data requirements for health plans. Of large concern to our providers is the data content compliance for the 837 and of the 270-271. With the 837 claim, the industry went from 400 plus claim format as quoted in the final rule to more than 800 versions of the 837P as identified in the convergence projects. The lack of uniformity has forced many providers to utilize clearinghouses in order to have their claims paid. On the eligibility side, some providers have been receiving only yes and no to their electronic inquiries, and were forced to pick up the phone to access information regarding copays and deductibles. This failure to report the necessary data may be compliant with HIPAA, but it is certainly not in the spirit of the regulation.
No piloting of the standards prior to the national rollout. Some of the problems associated with the 4010A1 version of the transactions could have been identified prior to full nationwide implementation had the government initiated a comprehensive pilot testing of the standards. This is something that CMS is doing with the pay for performance model. This seems to have worked much better.
Few reliable cost-benefit analysis of HIPAA. The tables included in several of the NPRMs are not believable by most observers. They were either underestimates of the cost and overestimates of the savings. With a more accurate description of the costs and benefits, practices could have had better planning and budgeting to implement the process.
Of particular importance to physician practices is the necessity to modify or replace practice management and/or billing software. Many group practices reported they experienced significant challenges getting their software upgrades for the 4010 versions of the transactions and later for NPI. In some cases, years after the promulgation of the final rules, practices have not been able to take full advantage of all the HIPAA transactions, as their software still does not offer the ability to incorporate transactions such as eligibility verification, claim status, and remittance into the work flow of the practice.
Costs of the practices for 4010 and NPI modification range from zero, as the practice's maintenance contract with their vendor covered federally mandated changes, to several hundred dollars for software modification to many thousands of dollars to replace older software with versions that could be modified to generate NPI. Upgrade and replacements of practice management and/or billing software often requires practices to replace hardware as well, as the new software requires faster processors and larger memory capacities.
MGMA recommendations. CMS should expand provider and vendor education activities, should establish 5010 pilot projects. CMS should conduct comprehensive pilots for 5010 transactions utilizing results from the pilots prior to national implementation. Successful pilots can jumpstart the vendor community and produce supporting products in a timely manner that is expediting the process.
As an aside, I would just say, in my state of North Carolina there is a group called the North Carolina Health Care Information Communication Line, that brings vendors and providers and clearinghouses to the same place. I'm sure they would love to do pilot projects and assists in this process.
The 5010 standards must be staggered as far as their compliance dates, and allow sufficient time to insure successful implementation. Significant migration of the new standards such as the 5010 standards should first require implementation by health plans and clearinghouses. Implementation by health care providers should follow at a later date. This would delineate a significant testing period without focusing all covered entities to funnel into the same compliance date. Staggering the compliance dates may forego the necessity for CMS issuing contingency plans.
Consideration of a sequencing rollout of the 5010 standards. As the industry experienced with the 4010, certain of the transactions are more critical to business processes. Claims, eligibility and remittance in that order were for many providers the focal point of their implementation efforts. CMS should consider a sequential rollout of 5010 in recognition of the importance of these three transactions.
NCVHS assessment of industry readiness. Just as you did successfully with NPI, we strongly encourage you to hold regular hearings and work with industry groups to assess the readiness and levels of implementation challenges faced by each of the various industry sectors impacted by the change to 5010.
Reduced variability in data content. HHS should make every effort to reduce data content variability from health plan to health plan and the necessity for voluminous companion guides. Removal of the exceptions for federal and state programs. When the original rule was published, there may have been justification for permitting certain federal and state programs to continue using proprietary transactions and allowing them to exempt them from the requirements under HIPAA. However, it has been seven years now, more than enough time to modify software and allow programs that utilize the standard claim forms to be required to adhere to the data content requirements.
Full implementation of 5010 before implementation of ICD-10. If the industry has learned anything from the very complex and costly implementation of 4010 and NPI, it is that these types of massive industry overhauls cannot be achieved easily or in a short period of time.
Simultaneous implementation of 5010 and ICD-10 will be an impossible task. Such an effort will surely overtax the ability of the industry to comply with the standards and divert scarce educational, financial and human resources from patient care.
In conclusion, we strongly encourage HHS to adopt a very different approach to implementing of these transactions than they did for 4010. Should they fail to do so, the industry most likely will be mired in a similar protected and costly implementation that we experienced with 4010 versions of the transactions and with NPI.
Again, in order to achieve successful implementation of 5010, we must manage the change process better than we have done in the past.
We appreciate the committee's interest in this important topic, and are available to answer questions.
MR. REYNOLDS: Larrie, thank you. Excellent testimony from everyone. I would like to open it now for questions from the group. I'll go ahead and start.
Some of you have heard the other testimony today. As I look at yours from an ADA standpoint, the issue of making sure you were included in the X12 negotiations and what was in there, everybody talks about some kind of a transition as we go. So what kind of time frames are you talking about? You mentioned testing and education and so on. So as you go through it, what is that sequence to you? The comments are about sequence, but what is that sequence and what is the possible duration of that sequence?
MR. AHLSTROM: From the ADA's standpoint, we have already instituted time lines. For instance, we know that we are going to have to have some sort of diagnostic code setup. We have a task force with NHII to help the profession migrate towards that. We also resurrected our initial diagnostic code event for SNODENT, with the realization that there may be other diagnostic codes that we are looking at. Our guideline for that is approximately around 2009.
The other problem that we have is with our practice management vendors. They have been telling us that they are driven number one by mandates and number two, by the profession, by our actual practicing dentists. Our practicing dentists don't go, when are you going to be ready for 5010, because most dentists have no idea what 5010 is, nor any idea what 4010 is, nor do they particularly care. They want at the end of the day to press their buttons and have everything occur transparently or relatively seamlessly.
A lot of this has happened because of the work that you folks are doing and other things that are making this occur. That is one of the things we wish to continue to do, working with other standards developing organizations such as HL7, X12 and ASTM.
MR. DAWKINS: I guess it is hard to put a date on the time frame, because as all of us have said, we are driven by entities that are not covered, which are the business partners that we have that provide software and so forth. But if you said that you could wave your magic wand and make those folks comply, then for the practices to move there, in our case it is very dependent upon what we learned in 4010, is, some practices were ready, some payors were ready, some clearinghouses were ready, but there was a large number in both of those areas that were not ready, which made the whole system not work.
So I think a practice can move as fast as its vendor can move. The problem is that moving to full implementation requires various sets of the industry to be ready. So for me to sit here and predict how fast a payor can move to being compliant, I can't do. But I can say a practice can move extremely fast, depending upon what their company is able to do for them and what their clearinghouse is able to do for them.
MS. RAINES: I would agree with Larrie's comments from a hospital perspective. I know there has been a significant amount of discussion about various types of testing, various stages of the testing process. But a true end to end testing to emulate some type of a production environment from womb to tomb, so to speak, you can be talking as much as 18 to 25 months.
So with an NPRM by the end of this year if at all possible with the final rule published as early as possible in 2008, and then 18 to 25 months from that point forward.
DR. COHN: Thank you all for very good testimony. This is a general question to all of you, and one we may ask Don Bechtel to comment on, representing X12.
I want to use a case in point, but I think it is more of a general question. Throughout today we have been hearing from people talking about the need for testing at various points, preferably within an SDO prior to completion of a standard, as well as potentially industry testing.
Now, having said that, we are in a situation now where there has actually been a completed standard that has come out that is identified as 5010, that has gone through the complete SDO process, and has been approved and brought forward by the DSMOs.
Now, in the case in point, I just want to use it as an example to understand how things might work. Robert, you have identified and commented on a number of issues you have with the dental transaction that you commented on during the course of your testimony. You commented about HCPCS and you commented about uses of diagnosis codes, all things that I would presume are part of the 5010 standard currently, and it made it through the complete balloting.
Now, I am trying to figure out how these changes occur. Changes do occur to standards after they have done completely through the process. Or whether you are contemplating that the issues that you are describing are going to be handled in 5050 or the next version, and what gets handled where.
I am going to ask Don to help clarify that. I am trying to figure out if we would recommend any sort of a testing piece, whether it shows up as improvements to this standard or whether it is improvements to the next version of the standard, trying to avoid 4010A or B or C.
So Robert, can you tell me your understanding?
MR. AHLSTROM: I think I do. The big concerns we had were mostly under the professional claims of 5010. There was not tooth numbering systems placed in there. While our oral surgery colleagues do medical procedures in a hospital, there is no way of putting tooth numbers down on the 5010, nor I also believe on 4010.
That by default means that it has to go back to the dental claim form, which in actuality is wrong. It should go under a professional claim, not a dental claim. So there is a transcription that has to go back that is being denied, and then has to come back to medical, then they say it will work.
That is why we came up with MOUs with X12 and HL7 to try and get to this point. We would be developing some of the content that would be necessary in order to provide for those transactions in a manner that would in essence satisfy all the requirements that would be necessary for submission.
Does that make sense?
DR. COHN: It does, except that you are now dealing with all these currently in the 5010. I was just trying to figure out, were you anticipating that these things would be modified prior to more general release?
MR. AHLSTROM: I believe we were under the impression that 5010 would not be modified until it went to the 5010A or B or whatever.
DR. COHN: So basically this is for the future. Maybe that is the answer to the question. I'm sorry to put you on the spot here. My apologies.
MR. BECHTEL: That's quite all right. I believe we were talking about an errata one correction to the 837 for the dental guide, is that correct? I think that is what I rad in your testimony.
Typically, if I have this right, there are two ways we would approach this. We can issue a new release of the 5010 implementation guide for the dental claim, which would come out as a new document or a new implementation guide. That is essentially what we are doing with the 270-271.
We recently at our last trimester meeting made an agreement to change what we had written prior for the alternate search option. We agreed to make a modification. So we are issuing a new 5010 implementation guide for the 270-271. It comes out with a brand new number, X something-something number at the end, but it is a 5010 guide, but it will be a new release of it.
I think the same thing will be happening with the dental guide.
DR. COHN: So basically there is a capability that X12 has when issues are identified to upgrade implementation guides?
MR. BECHTEL: There are some types of changes we can make like this. We are simply changing instructions. If we are changing something about the standard that is not supportable in the version we were writing for, then we would have to move it to a new version. Then it might go to 5050 or 5060, depending on what needed to be changed.
If this change is only for wording or instructions, then we can probably do it the way I just said.
MR. DAWKINS: May I add a comment there? I think what you are talking about is, there is a process just as you heard Don speak to. The changes will be made through the DSMO process and all. We have the industry who has come together and talked and debated and come up with, this is our standard and this is what we are going to propose, and we put it out and let people comment, and done all that.
This process in my mind is a living, breathing thing. It is going to go on forever. To me, what we are tasked with is, 4010 didn't really go well, but that was the first time out of the box and we were all doing from zero. 5010 needs to go better.
From our perspective from MGMA, part of our problem is that there are some people at play that we need to rely on which are vendors that are not covered entities, that make their own business decisions about what they are going to do whether we want to do it or not.
We want the standardization. The standardization, I think all of us believe, eventually gets us to the point of simplification, which is more cost effective than anybody can realize in this very complex system.
So I think the deal here is that we are looking at, we have got a process that gets a standard, but how do we move that standard out and do that in an orderly fashion, is what the issue in my mind becomes. Then addressing some of the things we learned from last time, it is better if the clearinghouses are ready than it is if they are not. It is better than the payors are ready from a provider's perspective. I'm sure if I am a payor, it is better if the providers are ready, because they are going to invest money in doing this also.
But I think the issue is, how do we roll this out in a logical businesslike manner, so that we don't kill the industry, also realizing that this is not the only thing out there on the plate. There are many other changes that are coming at us that we are trying to absorb, and we are all trying to work within the budgets that we have with low margins. That is what we are wrestling with.
I don't know if that addresses your question.
DR. COHN: I agree with what you are saying. I was just reflecting that earlier today we had heard from a couple of testifiers that something would reassure the industry is some actual testing of the standard prior to beginning the implementation or at the first step, or whatever, and that that would lessen the risk for everyone.
There was a real world example here of somebody who had evaluated a standard even before he had started implementing, and had discovered, it sounded like some errors or some misunderstandings. I was trying to figure out whether those things could be reflected in the version of the standard, or whether you were then going to be stuck with implementing the standard you knew already had problems, and you had to wait until the next time HIPAA comes around.
I think your vendors would probably be much happier to know that the kinks had been worked out, or at least had been further validated before they start implementing the software.
MR. BECHTEL: I don't think any of us are naive enough to believe that we are after 100 percent testing, and it is all 100 percent functioning well. We are after some of the, for lack of a better term, the 80-20 rule, 80 percent of the big things.
If I remember right, when we implemented the 4010 version, a lot of places used the Claredi certification of levels one through seven of whether you were HIPAA compliant or not. Well, different payors picked different levels to determine what was HIPAA compliant or not. That was problematic for providers. But after awhile everybody got to the same level and we were fine. That would have been something that would have been nice to flush out during the testing phase and make that decision and call and move on. That is just one of those issues that might have surfaced. That would have been helpful.
MR. REYNOLDS: Can I play off of that comment? Earlier, I'm not sure you were here, there was a discussion about, as we look at testing going forward, maybe in a more national way than just an individual way. You said it was much more helpful to you when there was one level of certification which allowed you then to focus on being able to produce those transactions in a way that would work consistently rather than just one for everybody that you dealt with.
Stanley, would you introduce yourself?
MR. NOCHIMSON: Yes, this is Stanley Nochimson. In the discussions there has been a lot of talk about testing and transition and figuring out a way to get this done. From a regulatory perspective that has been difficult, but it seems to me that instead of a post compliance date contingency period, if there is a way that we could have a pre compliance date contingency period that would allow covered entities to switch to the new standard before the compliance date, as long as they promise to support the old standard, that would allow a transition so that everyone would not have to change on the compliance date. People could start processing.
Maybe there will be people that want to start the processing early to try to work out some of the bugs. Some of the vendors may be able to jump in early and say if you go with us you will have an opportunity to get this done and you will be ready.
So I think there could be some consideration for that sort of transition somehow, either as suggested in the NPRM or through a contingency plan.
MR. REYNOLDS: Can you run me back through pre contingency?
MR. NOCHIMSON: In other words, from an enforcement perspective, technically the new standard can't be adopted until a regulation comes out and says, adopt the standard on a compliance date. Usually that has been one day. Then we said, if you don't meet that day, later on we won't enforce -- the government will allow a contingency until you become compliant.
What I am suggesting is that we say you can switch to a new standard before the compliance date, which technically would mean you would not be complying with the old regulation. But the government would not have any enforcement, or would agree not to enforce any type of a violation, as long as the covered entity continued as necessary to support the old standard until the compliance date.
So it would allow you to support two standards, the old one and the new one.
MR. REYNOLDS: That is dual processing under today's world. That is going on right now. It is called dual processing. I wanted to make sure I understood it.
MR. DAWKINS: I like what you are saying. The only concern is going to what Harry was talking about, the dual processing. The worst case for providers, especially a small provider, is to have one company that wants to be at one standard and another company wants to be at another standard, and their software won't support sending both standards.
In the NPI and the proprietary identifier, we had some latitude there, because there was a place for both items to be covered in the same transaction, which allowed us great flexibility, which we were most appreciative for. But I don't know how payors would feel about supporting two and doing dual processing, which I'm sure they would have an opinion about that.
I will tell you, if it came to the point of, I've got to remember that Blue Cross does it A and Medicare does it B, that is very difficult especially for small practices who are driven completely by a vendor who may not be as flexible as large vendors.
MR. REYNOLDS: I think Larrie makes a good point also. We heard discussion earlier about backward compatible and so on with the NPI, the fact that both numbers were there allowed that to go on.
MS. RAINES: I think the shift when we transition as an industry from the paper world, that is something similar in nature that we did. We did have a dual use period. Maybe that is not the best analogy, because we are talking from a real estate perspective and a form perspective to an electronic transaction, but there was a dual use period.
Now, relative to 5010 it might take a longer window of time than that. But I know from my hospital perspective, our vendor as clearinghouse would be charged at the individual payor level, based on who that payor was and what type of claim maybe that was, as to whether to transmit 4010A1 versus 5010. At least from a hospital perspective, that might not be something that we would have to monitor and track and research on a daily basis, that that type of intelligence would be within the clearinghouse, the vendor world and within their operation.
MR. REYNOLDS: From a committee standpoint, we produced some letters in the past about HIPAA ROI and some other things. As you look at 5010, since you three represent the lion's share of the providers out there, does 5010 implemented as it is now -- Larrie, you made a comment a little bit ago about eligibility. In the past it could be yes or no and so on, and that may not have been sufficient. Does 5010 start moving so that it will give more of an ROI, and so that people that might not be using those transactions now would go to those transactions because of 5010? That is a question for all of you.
MS. RAINES: From an HCA perspective, we believe yes, that it does.
MR. DAWKINS: And I would say from MGMA's perspective, I would believe likewise. For instance, a good for instance in our mind, is on the 4010A1 everyone is not required to use reason and remark codes, from a payor's perspective. That makes it complicated. Even though they are using the reason codes, without the remark codes you can't quite figure out what is the need that you are having to get the denial.
With the new version, the requirement is for the reason and remark codes across the board. Most third parties have gone there, but some have not. It is much easier for us, instead of picking up the phone and going why did you deny my claim, to know the reason and remark code and move on with it. That is a very tangible, concrete example that makes it much more efficient for us to process.
MR. REYNOLDS: That is in the 835, correct? How about in the other transactions? We heard this morning that the 200 range is one of the ranges that hasn't been implemented quite as much. Does the 5010 help in those ranges?
MR. DAWKINS: I don't know specifically. Folks that I have talked to have said yes, but I can't give you a specific. I also believe that the referral ones are also enhanced in this process, as versus the one previously, which has not been used as much.
MR. REYNOLDS: Any other comments from the committee? What I would like to do now is, we are a little bit ahead of schedule. Since this is probably our own hearing on this, we are scheduled maybe in October, but we had hoped to consider whether or not we put something together for the September's full committee, I would like to take the next seven minutes or so, if there is anybody in the audience that as you have heard the testimony wanted to make any comments. Then after our next panel the committee will start going through some deliberations, and I will go around the table asking each of the committee members for their insights and thoughts.
So I'd like to make sure, if there is time available, if anybody that has been listening or anything else, since they didn't testify, you can come and sit at the table if you want to make a comment. That way, nobody feels left out and we have got a chance to hear from everybody. If you are a little bashful now, if we finish the next panel early, you may get the option again. We want to make sure that we are inclusive. Then when we are finished we will then begin our process of deliberation, and probably through a series of conference calls or something else start working on a letter.
So I want to make that available to you right now. I don't see anybody at the table. Yes, ma'am, if you will come up and introduce yourself.
MS. JOHNSON: This is Mara Johnson at the AMA. We submitted testimony written for the record. One thing that I heard today that I thought was important was from CMS, from Christine, the considerations on page 16 with regards to trying to complete the MAC and the EDC transitions prior to going to what they are calling HIPAA 2 testing.
I thought that was interesting, because one of the points we made was trying to take a more global picture with regards to what is on the plate especially with Medicare. I know Medicare is not the purview of this committee, but there are so many things that compete for a physician's attention. One of them is the MAC stuff. That is coming. That is going to be a major transition.
In fact, if not today, in the next few days CMS is scheduled to release the names of the contractors that are being awarded for the MAC for several states, a handful of jurisdictions. This is a major transition. So that will happen in the next few days, end of September. That has big implications for physicians who are going to be -- they may be in one contractor or carrier today and they are going to be in a different MAC, so they have to look at a number of different things, for instance, a consolidation of the local coverage decisions.
So these are things that add workload to a small physician's office. I would just hope that NCVHS would consider the workload and other things that CMS or Medicare may be having on a physician's plate.
Also, the Medicare enrollment process is something that has been experiencing significant disruptions since last May when they changed the process. I have been in contact with several doctors who right now are sitting on hundreds of thousands of dollars of claims. They have been working well with CMS on this issue, but they are not in a position financially to take on some of the changes that were brought about by HIPAA and NPI and 5010.
So it is not so much that they don't necessarily want to. In fact, we do support the transition to 5010. It is just that looking at the global picture of what else is on the plate of this doctor can sometimes be helpful.
So I thought maybe hearing from CMS and what they are considering, like the MAC and EDC, also hearing from them on other major things might be impacting doctors. We can always weigh in on that as well. I talked to some of my provider colleagues who agree with me on this.
I don't know the plan necessarily with regard to what HEMS put forward. I thought that was interesting, too. That might be another way to gather that sort of input with regards to globally what else is out there as you decide on time frames and implementation strategies.
MR. REYNOLDS: We have heard discussion today about the possibility of trying -- some people recommended trying to get the NPRM out for 5010 this year. Does your referencing those other things make you agree with that?
MS. JOHNSON: I guess it would depend on which date -- what the implementation time frame was. We recommended a staggered implementation time frame, as many other people testified today, so we think that would be useful. The smaller physicians and practitioners are going to have the toughest time implementing, as they have traditionally, precisely for these reasons, because they have limited resources that are competing for their time. So I think that would be a good discussion to have prior to deciding what those implementation dates are.
MR. REYNOLDS: Anybody else want to comment on that?
MR. DAWKINS: I would be very supportive of that. I think from the MGMA's perspective in practice management, you have to remember, the same people that are doing pay for performance are going to 5010. The same people are going to be doing ICD-10. The same people are doing provider enrollment, if there is a new electronic provider enrollment. The same people are going to have to do the transition to the new MAC and the new carrier.
All of these are the same resources, because this is highly electronic, and these are either companies that you are outsourcing it to or they are in-house resources that you are having to use. If it was such that it was, registration did one thing and billing did something else and we could divide this up -- but unfortunately a lot of these changes, it is almost like, I've got this laundry list, what is the priority, what do you want us to accomplish first.
We can accomplish these things, but we can't do them all at once. I think that is the important point, is that there are many of these changes that impact us as we go on.
MR. REYNOLDS: So basically, are both of you saying that one of our goals, whether we look at e-prescribing or anything we did as this committee, was to make sure adoption happens. So you have always got to look at the smaller entities first.
So with all this going on, if we recommend too early and it puts a burden on them, then your implementation gets stretched way out because they can't keep up. So that is the other thing. As you look at staggering and other things, where people would get ready early, if others can't get there then we have got these dual things going on for a long, long time.
Any comments either of you have on that?
MS. JOHNSON: I guess I would be engaging CMS, specifically the payor in Medicare, early and often, along with the small physician community, so that we can collectively tell you what is on the plates of physicians.
The Medicare enrollment process right now is something that has been causing the physicians difficulty. If they can't clear an enrollment in Medicare they can't submit their claims, so they can't get paid, so they have no money to do anything. I'm not trying to say that every doctor is in that position because that is not the case. But there have been widespread problems.
CMS when they do implement their enrollment system electronically, which is coming soon, that will alleviate some of these. But if you just look at each point in time and touch base, they will be able to see what it is that may be a point of difficulty that year. Enrollment may not be an issue next year, but there may be something else.
MR. REYNOLDS: One message that seems to be coming across is that when it has finally said something has to be done, or if CMS does something, those are the main drivers, and everybody else, no matter who else it is, is secondary. I think I have heard that consistently, that that is really what the front line is.
So if the regulation comes out or CMS decides to do something, that is driving it. You don't hear any of the peripherals.
MR. DAWKINS: And I think what we are asking you is to be sure that CMS looks at the overall picture, not just do one. Whatever that deadline is going to be, we are going to drop and go there, and if you drop another deadline on us, then we are going to have to turn around and drop and go to that one.
What we are saying is, that is not absorbable in the current environment, too many of those. We are trying to change the industry. We are all supportive of transaction standards, efficiency. That is not the issue. The issue is like we talked about, managing the change process. You can only push so much down the pipe at one time, and somebody has got to make the call of which ones are first and which ones are second. They all can't be first because the resources are the same.
We want to go there. We want them all. There is not an issue about not doing them. There is an issue about how to do them without breaking out backs in the process and everybody going to list them.
MR. REYNOLDS: Margaret, that got you out of your chair.
MS. WEIKER: Yes, it did, Harry. I think that may be applicable to a lot of the industry segments. Your comment about, so goes CMS, so goes the nation, so to speak, --
MR. REYNOLDS: Remember, I was stating the words said today.
MS. WEIKER: Okay. I would say that that may not be applicable to the pharmacy industry. There is a piece of that, the Part D, but it is not the whole driving force there. So I just want to make sure that we don't do this broad-based comment.
MR. REYNOLDS: That's a good point.
MS. WEIKER: Also, while I am up here, I think it is important to -- hearing the testimony, and I know I have used these words myself; we talk about the word stagger and we talk about the word pilot testing. But I think it is important, maybe we need to define what we mean by pilot testing somewhere. When we stagger, are we staggering the entities and how they implement? In other words, the vendors, the practice management systems go first and the clearinghouse second, et cetera? And/or are we talking about, the vendors go first and they do these transactions, or is it staggering transactions?
So when you say stagger, we may need to define exactly who and what we are staggering. So it may be important.
MR. DAWKINS: I think what we would say is, we are all staggering, we just need somebody to knock us out.
MS. WEIKER: There you go. But I do think when you write your letter, that it may be beneficial to put some definition, so everyone understands, and that there is no confusion in regard to what exactly did this mean. There is no assumptions.
MR. REYNOLDS: So do you have those definitions, or are you just wishing us well?
MS. WEIKER: I would be more than happy to help figure that out.
MR. REYNOLDS: With that, using the clock up there, we will be back at ten minutes to three. Thank you very much to that panel. Well done. We hope you can stick around for the rest of it.
(Brief recess.)
MR. REYNOLDS: Our next group is a continuation of the provider/pharmacist panel. From NACDS is Michele Vilaret, and from SuperValu Inc is John Klimek.
MS. VILARET: Thank you. I am Michele Vilaret, and I am the Director of Telecommunications Standards with the National Association of Chain Drug Stores. I would like to say thank you for the opportunity to comment on this important topic today.
NACDS represents the nation's leading retail chain pharmacies and suppliers, helping them better meet the changing needs of their patients and customers. Chain pharmacies operate more than 38,000 pharmacies, employ 114,000 pharmacists, fill more than 2.3 billion prescriptions yearly and have annual sales of nearly $700 billion.
During this presentation I am going to attempt to answer most of the questions asked by the panel. For this presentation I polled our members to obtain their opinions on these various issues.
The first question dealt with the business benefits of the various HIPAA standards. The 835 remittance advice is essential to pharmacies to insure payment. Tighter business rules to eliminate options is badly needed with the 835. Most of the problems that we deal with today are due to the various interpretations of the 835. The business rules are tightened and better defined, and there should be less room for interpretation.
It is very helpful that several of the codes have been eliminated. We are in the process currently of reviewing the list of eliminated codes, and so far there has been only one that we have found we needed as an industry, which we were able to prove is useful and get returned to the list.
It has been very helpful to be able to keep the NCPDP work group involved in this process, and I am thankful to X12 for allowing us to be involved in this process as well as NACDS. It is always good to eliminate codes that are no longer used, to keep the code list to a minimum.
Reporting of payment options is not as important to pharmacy as to other entities. Pharmacy prefers EFT. Secondary payment reporting is extremely important to pharmacies. This section results in a lot of errors and a lot of time spent manually reconciling claims. The changes made in this area are essential to our business.
Although the 837 is used in NTM and service billing, as well as by some state Medicaid plans for DME claims, chain pharmacies do not plan to implement this transaction. Implementation is just too complicated and expensive. Instead, pharmacies plan to use outside vendors in the billing process. There is just no return on investment to the provider if they invest the time and money to code for the 837. It is estimated that it takes well over one year to code for the 837 alone. It is not a good investment, and the transaction is not widely used by pharmacies. We are still waiting for a ruling from CMS on whether NCPDP 5.1 can be used in conjunction with the 837 for NTM and/or service billing.
Pharmacy needs D.0 to provide better guidance in coordination of benefits situations. Currently most of the problems that we have with NCPDP 5.1 deal with misinterpretation of coordination of benefits. NCPDP went to great lengths to redefine the other coverage codes and to provide claim examples in COB situations in order to eliminate future confusion. Pharmacists also need D.0 to process Medicare Part D claims due to all the enhancements that NCPDP and CMS have added to D.0 for processing of Part D claims, including the enhanced eligibility check and enhanced coordination of benefits section, which now identifies patient responsibility and benefit stage to help identify the coverage gaps on secondary claims.
Several enhancements have also been added to service billing for NTM claims processing, and hopes that CMS will rule that D.0 can be used to process NTM claims, especially for Part D. We currently have too many workarounds in pharmacy systems due to the shortcomings of NCPDP version 5.1, especially when it comes to processing coordination of benefit claims. D.0 is badly needed with its redefined pricing segment and its robust coordination of benefits, as well as streamlined compound claims processing.
As far as implementation, we need an implementation plan similar to what we had with 5.1. We found that working through NHIN, the Nationwide Health Information Network, for version 5.1 was very successful. For version D.0 we want to use the WIDI if NHIN is not available, or some other similar type organization.
It would be a good idea for the regulation to set milestone dates. This would help to keep the industry on track. But let the industry monitor its own progress through NHIN or WIDI. Some pharmacies will implement D.0 as a phased in approach, but others will not. Because of this, we would not support a mandatory phased in approach.
Testing between trading partners will be necessary but not mandatory for all. Testing will need to be mandated for plans or payors that are not going to implement a D.0 5.1 dual version strategy. Therefore, we cannot support mandatory testing for all, only for those who will not implement a dual version strategy. I explain that a little later.
We surveyed our members, and all of the chain pharmacies can support a dual version of translations for the phase in periods and beyond. This includes processors. If there are other pharmacies that may have difficulties with the dual version approach, there are vendors that are capable of assisting them through the transition.
Implementation process should be tracked through one entity as we did in 5.1 through NHIN. Pharmacies may not code for all segments, depending on the companion guides from the various payors. Suggested milestones for pharmacy provider in D.0 would be claims, eligibility, and these are just my suggestions for our particular piece of the industry, service billing, and this is just if it is approved for use in NTM, and prior authorization, and this depends on if we find that the different payors are using the prior authorization segments.
As far as education, education to the providers, payors and software vendors needs to begin as soon as the final rule is released. NCPDP has already had a series of educational questions. Additional educational questions will definitely be needed, since D.0 is quite different from NCPDP version 5.1. Previously CMS provided the Ask HIPAA listserve, which was very valuable. We recommend the reactivation of this service. Providers found this to be very helpful during the implementation of HIPAA 1.
Pharmacies have very limited resources, so the overlap with other HIPAA initiatives such as ICD-10 would tie up these limited resources that are already dedicated to priority projects such as D.0. This makes it very difficult to keep to an implementation schedule, since pharmacies don't always have dedicated resources for these types of projects. We ask that you not have overlapping compliance dates for these types of HIPAA requirements.
Lessons learned from the initial HIPAA implementation. The lack of time. We did not have enough time to implement. We definitely need a full two years to properly implement D.0. The state Medicaid programs were especially slow to implement the initial HIPAA standard. We must make sure they are on the same page this time. We also need to make sure that payors are flexible. We spent a lot of time last time dealing with plans that had misinterpreted the standards. It wastes a lot of everyone's valuable time. We need assistance from CMS or NCPDP in enforcing and interpreting the standards.
We cannot have all plans implementing on the compliance date. Plans should be required to implement D.0 prior to the compliance date with an either-or strategy. They can eliminate the use of 5.1 on the compliance date. So we want to be using a dual use strategy.
We also need to make sure that we don't have any early implementers. That was also a problem the last time. If a plan wants to mandate D.0 only, they can only do so on the compliance date, not before. Prior to the compliance date, they must implement with the dual version strategy. If plans are going to implement with a hard cut over to D.0, then testing must be mandated. There is no other way for us to insure a seamless implementation without mandated testing for this group of payors.
So how do we avoid extensions? We have to work with the slow adopters from the previous version of HIPAA, make sure that the Medicaid directors are on board and insure that the time line is workable. Also, make sure that pharmacies receive payor sheets or companion guides at least 90 days prior to the go live date with the plans. This should be mandated in the rule.
Based on experience with 5.1, it is very important that payors allow flexibility, especially in areas where they the payors have misinterpreted a standard and are asking pharmacies to provide inappropriate information, especially when this causes a HIPAA violation.
As far as the need for D.0, I'm just going to go through this real quick because everybody else has talked about it. You understand the eligibility transaction and the Part B enhancements with the ability to perform crossover claims. We only have one way to bill compounds now for the additional coordination of benefits section. That is the big, big bonus of D.0 and the enhanced service billing.
So I will get right down to the conclusions. Given the complexity of D.0, the chain pharmacy is going to need one full year to implement this standard. That is in talking to all my chain pharmacies. It will take them about one year to code and test. Our concern is that the state Medicaid programs will not be compliant even within this time frame. There is also concern that some plans may try to implement the standard early before systems are compliant. Therefore, we ask that the rule mandate that plans cannot implement prior to the compliance date with D.0 only. We prefer the plans implement prior to the compliance date and allow the use of either 5.1 or D.0. If a plan can only implement using D.0, then the plan must test with providers and cannot implement using this strategy until the compliance date. So we want to use the dual version strategy only prior to compliance date.
Our suggested final compliance date would be two years after the final rule. At that time, all entities should be able to process claims accordingly, using all aspects of D.0.
Thank you. We will talk about questions later.
MR. REYNOLDS: Thanks, Michele. John.
MR. KLIMEK: Mr. Chairman and members of the committee, good afternoon. Thank you for the opportunity to present to this panel from the pharmacy providers' perspective concerning implementation issues as it relates to NCPDP version D.0 and the X12 standards. My name is John Klimek, manager of the RXV department within SuperValu Pharmacies. In my current capacity I also assist our IT teams and project development as it relates to implementing NCPDP standards and other HIPAA related standards in our pharmacies. I would also like to mention that in the last ten years I have been actively involved in the standardization process of pharmacy claim information through my involvement with NCPDP. I am currently a board member at NCPDP, as well as hold various volunteer positions such as co-chair for work group two, standard product identifiers, and chair a committee for strategic planning for NCPDP.
Just a little history about SuperValu. We have approximately 950 pharmacies. Our company operates under multiple food and pharmacy banners as shown below. We process in excess of 50 million prescriptions per year. We manage and develop our own pharmacy software as well as our own accounting software.
Just a little information about what our patients see as being important to them. This source is coming straight from Drug Topics. They look at pulling prescriptions quickly; 92 percent of the patients see that as being important. Supplying written or printed materials, 90 percent. Pharmacist available for questions, 85 percent, and advice on OTC drugs, 64 percent. So as you can see, patient demands on our pharmacy teams require less confusion when it comes to the actual claims processing.
It is with the NCPDP standards that our pharmacies enjoy most claims to be positively adjudicated within seconds. The pharmacy community has benefitted greatly from the NCPDP standards. Any change in the standards that affect the pharmacies should be looked at as positive changes, with all entities using the same implementation guidelines. Any deviations from the standard on a plan by plan basis could change the normal process time from seconds to minutes to hours. That is why it is important when we implement new standards at store level, we make the claims processing as automated as possible, so as not to disrupt patient care.
Some past history on project development at SuperValu/Albertson's involved upgrading from NCPDP version 3.X to version 5.1. At initial phases, a team was developed to identify project scope and ROI. Our estimated cost for that project ran approximately $500,000 plus. Changes to accommodate the new NCPDP standard involved multiple changes to multiple infrastructure layers. The rollout involved a dedicated testing team that involved internal testing as well as testing with over 100 different trading partners.
The important thing to note with the external testing is that none of this would have been possible without an entity that NCPDP had identified to help with this process, which was NHIN, Nationwide Health Information Network. They helped monitor and hold weekly conference calls to providers. This was instrumental in timely testing and rollout. Our internal process also involves training store level personnel and approximately 10,000 associates. The project ran for approximately three and a half years.
Some items learned from the rollout with version 5.1. We needed a certification process for all processors, payors and switchers. Not having a certification process in place left uncertain outcomes at times of rollout. When rolling out 5.1, we found often that requirements to certify required us to send claims with information that violated internal coding. Examples of that were, when a certain drug was required to test, and the claim value and the certification process required us to make additional changes to our internal system to accommodate the expected claim value.
Our current pharmacy application uses industry known pricing values for drugs, and any changes in these values required additional coding. With that said, it was important that claims and testing packets mimicked real case scenarios. Any problem we ran into was when we were given very short time frames to test them and make any corrections.
As mentioned previously, it was very early in the process of implementing NCPDP version 5.1 that we realized the need for a central standards liaison. Working with NHIN and NECDS as our central contact, we were able to identify technical issues, coordinate testing dates and times, develop key contacts with trading partners as well as monitor the progress of rollout within the industry.
In the normal course of business, we require trading partners to share their payor sheets. This payor sheet outlines the claim requirements needed to create a successful transaction. Because we deal with hundreds of different payors, these requirements are needed in a timely manner in order to set up processing. It is with these payor sheets that we identify the required fields that may be different from other entities.
These payor sheets also identify COB or coordination of benefits segment information. The COB segment was the point of much confusion, being that it was a newer segment being used by industry and had much room for ambiguity. Getting payor sheets that outlined the plan COB process was essential to timely rollout.
It was with our process testing that we ran into many entities that developed their own interpretation of data element definitions or data conditions. With the help of industry involvement we were successful in getting many to change, but often there was much struggle.
Most of these issues revolved around COB processing. It was important in pharmacy that we didn't have to code COB or any other functionality multiple ways. That is why often through our weekly calls we identified these issues and collectively tried to resolve them.
Pharmacy providers code for the standard according to the implementation guide. Deviations require additional work effort and possible increase in programming costs. These deviations also cause a change in the training at store level. Any changes we require the pharmacy team to make from the standard process has the potential to cause the claim not to process correctly, which then introduces the possible disruption in patient care.
I just listed a few examples here of some instances we ran into with plans at our initial rollout in 5.1. I won't read through this, but this gives you the ideas where we ran into issues with plans requiring something that was different than what the standard called for. Again, a lot of these issues were brought forward in our NHIN weekly calls, and most of them we were able to identify and rectify before rollout of 5.1.
Some additional issues we ran into with implementing version 5.1 as it related to implementation dates. We had to call payors repeatedly for payor sheet information, because payor sheets are the blueprints that outline claim specific information needed in order to successfully process a prescription claim. It was very important that we receive these well in advance. Without this information we would see possible delays in rolling out the testing and implementation.
Early implementation of standards by plans or processors also caused disruption, because industry most likely was following the implementation date set out in the HIPAA rule. Although not NCPDP 5.1 related, recently we ran into issues with entities rolling out the use of NPI prior to the implementation date of April 23, 2007 of this year. We saw the same issues with plans rolling out 5.1 before the mandated date. Often the only pressure we could apply towards entities not complying with the standards was through a coordinated effort with all providers using NACDS and NCPDP and a forum.
Now for some items the pharmacy industry is looking for with version D.0. A big change for us and something that all our pharmacies are looking for is some clarification on the COB process. Right now, a lot of pharmacies are struggling through this.
Also, with Part B, one thing to mention there is that although there is much work that is being done with Part B enhancements, the reality is that Part B is not processed real time online, so these claims are usually sent to a clearinghouse, and our pharmacies and patients are often left in the dark at the point of sale. So although Part B enhancements are great, we would certainly like for that process to be online eventually one day.
Some additional benefits we look forward to in the next NCPDP HIPAA approved standard is defined situations for fields and segments within the standard. This will help remove ambiguity which caused deviations from the standard. We will also see fields and segments that once were displayed as optional, given better definition as not used, required if, required or optional.
My hat goes off to NCPDP staff and its members for the grueling task of going through the entire implementation guide and making these changes. It is my hope that these changes will help prevent interpretation and variations from the true standard.
Changes were also made in the service billing standard by adding additional fields to help supplement the needs for clinical, MTM, medical therapy management. It is our hope one day that the standard be used for our day to day processing of MTM claims, for our Medicare, Medicaid and private pay patients. Even today within NCPDP version 5.1, there are current recommendations for Medicare Part D dispensing and administration of vaccines which outlines a process of both drug and administration to be billed within one claim. This process of drug charge and administration fee all in one claim will enhance and maximize quality of care for our Medicare Part D patients.
The X12 standards coded and used internally in SuperValu is the X12 835. We saw similar needs and opportunities when it came to implementing the standard with all payors. Often we saw multiple interpretations of the standard which created additional work in coding.
One particular problem was the method in which payors reported reversals. We used the same method to monitor rollout of the X12 835 that we used for monitoring the NCPDP 5.1 rollout, by using NACDS as our forum for calls with payors. This worked with regard to identifying issues and working out the implementation date.
Today, SuperValu uses a clearinghouse to process claims that require HIPAA approved X12 837. This is achieved by our pharmacies submitting a 5.1 claim to a clearinghouse, which is then converted to an 837. Currently we have no project on scope to build an in-house application using the X12 837. This decision will be re-evaluated as market conditions change.
So in conclusion, in looking at moving forward with the new HIPAA approved standards, there are some internal steps needed derived from lessons learned. Each company will need to develop internal project development teams and process several of the prerequisites in determining ROI as well as time frames. As seen in previous standards projects, we anticipate significant drains on budget capital as well as resources. With this process there will also be multiple departments involved. We will also include but not limit it to the internal development testing protocols, as well as developing training pieces for our store teams that outline some of the newly added features that NCPDP version D.0 brings us.
In looking forward to the new HIPAA approved standards, here are some external steps needed as we move forward. Obviously needed is a time frame for implementation. From history, we know that entities require a minimum of two years to implement these standards. Along with this time frame it would be very beneficial to have outlined an industry implementation date.
As seen with rollout in the pharmacy industry of NCPDP version 5.1, a central source was needed that monitored progress of implementation as well as identified issues and help resolve them. It is highly recommended that we develop the same central monitoring resource.
In the process of rolling out a new version of 5.1, we found the need to maintain and support two separate NCPDP versions, until all entries were converted. This created a phased-in approach. At SuperValu we saw the need for this, and recommend that other entities plan for this.
It is also recommended that entities follow an industry wide approved testing plan. Everyone should be held to an implementation schedule as well as allow for some flexibility. We look forward to CMS' support in this matter. As mentioned earlier, payor sheets were beneficial and given a lot of time prior to testing and implementation. We also look for assistance from CMS as it pertains to entities wishing to implement these HIPAA approved standards before any implementation date. The ability for entities to be allowed to do this usually creates issues that affect other rollouts.
So in conclusion, today's increase in pharmacy business mainly due to the Medicare Part B requires additional time for pharmacists and pharmacy teams to deliver quality care. Anything we can do to maximize pharmacists' time spent with individual patient care as opposed to their time spent resolving pharmacy claims issues is a win-win for all involved.
Again, I want to thank the committee for this opportunity to speak in front of you, and the opportunities we see moving forward with new standards that affect pharmacy. Thank you.
MR. REYNOLDS: Questions?
MR. STEINDEL: Thank you for your interesting talk. I have a clarification question. I didn't think I could run into acronym collision, but what is NHIN with respect to your talk? The NHIN most of us are familiar with is the project initiated by the Office of the National Coordinator, and I have a feeling that is not what you are talking about.
MR. KLIMEK: That is not the same organization. This is actually a private organization. I think it is owned by PDX. They came to the plate and offered their time and efforts to coordinate efforts with all the other providers out there.
I do realize there is a another NHIN. I didn't want to confuse them.
MR. STEINDEL: Thank you. I wonder if they have their acronym trademarked.
MR. KLIMEK: I don't know.
MR. REYNOLDS: Any other comments?
MR. STEINDEL: I didn't have anything else, because they covered most of it.
DR. WARREN: I had one. It was an acronym, too. MTM?
MS. VILARET: Medication therapy management.
MR. KLIMEK: With Medicare Part D, that is one of the prerequisites in pharmacy.
MS. VILARET: Sorry, I should have spelled that out.
DR. COHN: Michele, I just wanted to clarify about your comments regarding dual processing.
MS. VILARET: Yes, dual version strategy.
DR. COHN: What I think I heard you say was, as an organization you recommend dual processing. It appeared that all of the people you queried indicated they were going to use a dual processing strategy, at least as I could tell by your note. Yet, you also didn't say everyone should do dual processing. Rather, you said if you don't do dual processing you need to do testing in advance.
Could you clarify that? I couldn't quite tell why you were doing that. Is that in case somebody else decides not to?
MS. VILARET: All the chains can support a dual version processing, but we would like all the processors of plans to implement using a dual version. However, there may be some that cannot. If they cannot, then we would advocate that they cannot implement until the compliance date, and they must test. If they cannot implement using this dual version, then we have to have mandatory testing with them.
By implementing using the dual version, that is an awful way of testing because you have the option of submitting 5.1 or D.0. The testing is up to trading partner agreements. If you run into issues you can always go back to 5.1, but if you are implementing in a hard cutover environment and have no testing, you are dead in the water.
So that is why we said if there is a payor that is going to implement as a hard cutover to D.0, then that is where the mandatory testing has to be implemented. When I told the chains, they did not want to advocate for mandatory testing across the board, because that would be impossible for them. There are so many trading partners that they work with, they couldn't possibly test with absolutely every single entity. That was the reason. But there are certain entities that they do have to test with.
Does that make sense?
DR. COHN: Yes, I think it was a very good suggestion. I just wasn't sure why you weren't saying everybody should do it. I think effectively you are, actually.
MR. REYNOLDS: Any other comments? One thing I would like to say is thank you. We appreciate that a lot of the stuff as you said has been covered earlier, and I think you just added on to what we already heard, but that is always good for us too, to make sure that we have that.
With that, I want to open it one more time. Don, would you mind coming back up again? I wanted to ask you a question on dual processing, if you don't mind.
Let's hold on a second. Jeff has a question, and then I want to ask Don something.
DR. BLAIR: Did you have an idea of when the dual testing would begin?
MS. VILARET: Actually, as far as the dual implementation, there is no date. That is the beauty of dual implementation. It can begin whenever, because there is no early date as far as the dual strategy for that. Anybody could implement -- or some of the chains could be ready as early as one year after the final rule, from what I understand.
DR. BLAIR: Thank you.
MR. REYNOLDS: Don, we heard dual processing. A lot of us know that with NPI, the first HIPAA was, you could do it because you didn't have all the HIPAA transactions in place. Then NPI was easy because you had both numbers. Now when you go to the 5010, to where you have the current 837 and the current 835 which match, then you go to the new 837 and the new 835 that match, does dual processing work as well this time, now that it is the 5010, versus the original when we implemented it, because you were HIPAA or not. Then you had both numbers on NPI, so it didn't really matter what you were. In other words, you just had some logic in the system. But now that you are matching 837s and 835s and all this and that, and this provider does this or this clearinghouse does this, and somebody does that -- we have heard dual processing, and it is a great term, and a lot of us have used it, but it seems as you think about this one, then maybe dual processing may or may not be possible.
So could you help us with that, or anybody else that wants to talk about that? We hear that a lot. I sense that it worked out in this implementation because you are more of an incremental change. This is changing the meaning of already existing fields. The old version means this and the new version means this in 5010, and what was situational is not situational in some of those things. So any way you can help.
MR. BECHTEL: I think you just answered it. I don't think going from 4010A1 to 5010 is going to be like adding NPI and running dual systems.
MR. REYNOLDS: A little closer to the mike.
MR. BECHTEL: I don't believe that when we convert from 4010A1 to 5010 we are going to have the same kind of dual processing experience we had with NPI.
You are absolutely correct in what you said. With 4010A1 we had a way to support both numbers, so there was a way for us to use the same transaction to do processing either with NPI or without NPI. When we go to 5010, it is a different situation. The changes that we have made in a claims transaction, a lot of the business rules or situational rules have changed to either be more strict or more clear. Certainly entities who had a different interpretation than we intended are going to have to make modifications to their systems to conform to what was intended.
So if I understand your question, a provider who wants to send a 5010 to one payor who is ready to do that and still send 4010A1s to another payor who is not ready to do that, they would be in a situation where they would have to create two different transactions. They can't send 5010 to both and have it work. So they would have to have the ability to make a 4010A1 as well as the ability to make a 5010 as a provider to support that scenario.
On the other hand, a health plan who has to receive 4010A1s from those providers that aren't ready but still wants to support 5010 for those who are, that would be the dual processing we know and love from 4010 conversion. I think that is going to be like you experienced it with 4010A1. It is not going to be any different in my opinion.
I don't know how much further you want me to answer your question.
MR. REYNOLDS: I'm just asking. Simon, please.
DR. COHN: I thought initially you were saying no, you can't, or it doesn't work. Then I heard at the end you say it is exactly like the NCPDP rule, processing using version 5.X and D.0 because they are relatively different transactions also. You are sending one in and they choose which one to use. Is there any difference that we are talking about here?
MR. BECHTEL: No, I don't think so.
DR. COHN: So you are saying this actually would work.
MR. BECHTEL: Maybe I misunderstood.
MR. REYNOLDS: Let me add one other thing to the question to see if it helps in the discussion. 837s map to 835s now.
MR. BECHTEL: The 837 mapping to an 835, you are talking about a claim mapping to a remittance?
MR. REYNOLDS: Yes. So basically when somebody puts in an 837, if somebody sends a 5010 837 and everybody is not ready to put out a 5010 835, you have got a whole different N, and those are not matched.
MR. BECHTEL: Right.
MR. REYNOLDS: So that is the one that is complicated. In other words, one or the other is fine matched together, especially if a situational field that is sent in has changed in the new version. The old version of the 835 doesn't expect it to be changed. So it is a little different, because everybody either did the 837 under the original implementation of 4010 and then the people that were ready to go to 835, but everything was proprietary other than that, so it was a different situation.
MR. BECHTEL: On the 835 relationship between 4010A1 and whatever goes forward, we tried to bring forward the 835 4050 about a year ago, in the hopes that we could understand what the change process was going to be like. We did verify that we would be able to run the 4010A1 837 with the 4050 835.
We felt that was possible. I believe we feel that running the 837 4010A1 with the 5010 835 is also possible. I am quite sure I heard that from the work group. But that may not hold true with all the transactions. It doesn't hold true with what you are actually sending on an 835 4010 versus an 835 5010. They are going to be different.
MR. REYNOLDS: John mentioned in his testimony just now a hundred-plus trading partners, whereas CMS mentioned this morning a million and a half trading partners. So it is back to that one on one, what level are you sending, what level do you want back, how are you going.
So it is the same thing as what happened before, but as we look at the size of 5010, those are the things that are the quiet pieces, because as soon as you have got to go to that new version and test with everybody, everybody has got to open those same things again. So when you have got 15,000 trading partners or a million and a half like CMS, it is a piece that is always there.
Again, it wasn't quite there in as difficult a situation with NPI, because you could play in place. It was a little different situation.
So not to belabor the point, but we have heard consistently dual processing, but I think it is just a little different as we think about it going in. I still think it is a great idea. You can't do the big bang. It is just something that we really hadn't drilled in on in our discussions. So thank you.
MR. BECHTEL: Sure.
MR. REYNOLDS: Why don't you stay there until we decide we are done? With that, I would like to see if anybody else in the audience would like to say anything, and then I would like to spend a minute with the committee going around the room, just getting a sense of what everybody has, and we will talk a little bit about next steps.
With that, the floor is open if anybody wants to come to the table and make any other comments that you want to be on the record as part of this deliberation? If you don't, we will go around the room, and we will chat. Seeing no movement and nobody is coming up, let's start. Steve, why don't we start with you?
Agenda Item: Subcommittee Discussion
MR. STEINDEL: Thanks, Harry. I thought this was a fascinating set of hearings. I think I started off with maybe a slightly negative to no opinion to how we were going to go, and I left the session yesterday afternoon when you asked around the room at the same time about, if there was any committee opinions, subcommittee opinions on this, and I said I need to hear what I need today.
I have to say that I was very surprised about what I heard today. It was very interesting, what I heard today. I think I heard a very constant theme that convinced me that one of the recommendations should be that we recommend to the Secretary that they go forward with an NPRM for 5010.
There are a multitude of reasons for this. I actually didn't hear a very over compelling business reason that 5010 is this great improvement over 4010, and the industry processes will automatically be changed. I did hear that there was a vast number of technical improvements made in 5010 that would be very helpful. I also heard that there is 4010 working today and solving some of these issues, maybe not in the best ways we would like to see, but businesses moving forward.
But what I also heard was that the movement forward of an NPRM and a process to 5010 actually will help elicit a lot of comments, a lot of opinions, a lot of maybe necessary changes in the way we do HIPAA, to move HIPAA forward to 5010 and perhaps beyond 5010. I think that is one thing that we should focus on in the letter to the Secretary about the items we have heard about implementation plans, firmness of dates, clarity of timetables, the need for testing sites, multiple phases of testing.
We heard comments about staggered and pilot testing. I agree with those people. I have multitude different definitions of what is meant by staggered and pilot testing. I think that the NPRM process will help us clarify a lot of that information.
I think it is very clear that I came in with an idea that maybe we can introduce ICD-CM without going laboriously through the 5010 process. I actually still think that there are ways, surgical ways, to implement ICD-10 without going through the full 5010 process. But after hearing all the testimony today, I'm not convinced that we would save much money in the long run by doing it that way.
That is an entirely different statement than whether or not we can do it technically. This has to do with what we heard about testing. Even if we made small surgical changes, even if they were relatively harmless, we might implement those surgical changes relatively quickly, go through the ICD-10 process, but then we would still have to redo all the testing as we move to a new version. So I don't know if we gain much by bypassing 5010. So I would think we need to stay the route of the 5010 course, the ICD-10 course.
I think I agree with a lot of the time frames of the testifiers. Even at our optimistic best we are not going to have this in place, this whole new system. 2012, 2014 is the earliest. I'm sorry, I'm just a realist there.
Harry, those are my observations.
DR. BLAIR: I think that the way Steve expressed his feelings is probably -- I think he expressed his feelings fairly similar to many of us on the subcommittee. But if you notice what he said, he observed that after the first day we didn't hear that there was a direct business case justifying moving forward, but that by the end of the second day we heard indirect rationales that were very compelling to move forward.
Now, we are all in the same room. It is going to take months or years while this process goes through. The fact that we may support moving forward now after two days where we all heard the same thing and went through the same mental recognitions of what justifies this, that is going to evaporate.
I think if the industry, the SDOs, the WIDIs, the HEMs, the industry that has worked so hard to create these improvements in 5010 and NCPDP D.0, if we don't take advantage of the next six months or a year to go that extra mile to gather the information, whether it is education or education and surveys, to be able to present a definitive business case, it is going to come up again, and in another setting six months or a year from now, we may not have the same opportunity we have in these two days to wind up saying, the indirect benefits that we heard are compelling.
So I think we should take advantage of the next six months to a year, the industry, to continue to work on education and showing where the justification for moving forward exists.
MR. STEINDEL: I'd just like to comment. Jeff, what I recommended is that we move forward with the NPRM. I did that in part because I heard statements from a lot of the testifiers today that we are really not going to get a coalescence of industry opinion or even industry looking in depth at 5010 until we start the regulatory process, that they use this as a point in time to allow things to start happening within their organizations.
Now, after we publish an NPRM, after CMS analyzes all the comments and we start looking at what is going on with a final rule in that area, I agree with you one hundred percent; we may change a lot of our perceptions. I don't know. I think we need the NPRM to get that information.
DR. BLAIR: Well, we seem to have a conversation here. I think that we are converging a little bit. The only concern that I have is that if the industry doesn't use this time between now and when an NPRM is issued, which as you know experience tells us could be a year or more, to provide that education to the industry, maybe do some other surveys, the NPRM will come up, and the folks that are not convinced might prevail.
So I guess what I am saying is, I think there is a window of opportunity here for education to take place. I think the NPRM is essential, that is going to be a driving force, but it could be driving it positively or negatively. I'm just saying that the time should be used to lay the framework so that it will be positive.
MR. STEINDEL: And the only reaction I can make to that comment which I totally agree with is something that we have observed throughout these testimonies today, that there was a coalesce from industry as there was with e-prescribing in the pharmacy arena. The industry got together, their act was very together.
I think all of us would be in favor of moving forward right now with the NCPDP transactions from a HIPAA point of view, because they garnered a lot of industry support. What I would love to see is the same type of coalescence in the X12 world, so that we would be in the state that you are describing. Maybe this situation will force them to start looking at that coalescence.
DR. WARREN: Like everyone else, I think it is probably time for us to move forward and recommend 5010 NPRM. The things that really hit me that were different on this one was from the lessons learned, that we needed to do pilot testing that occurs before this two year time line of implementation.
But I don't think we have heard things that clearly before, so I would like a chance to take a look at what that time line means. Are we looking at a three-year time line now, one year for the pilots and two years for the implementation? Is there something that we can put together for that?
We also heard some testimony about certification of the standard. I still need to think about that before I can make too many comments.
My final thing was following up on Margaret. She came up with, we needed to define terms about staggered implementation and pilot testing. I started thinking about that and I thought, there are probably some others. When we take this letter back to the full committee, they will not have sat in this room and heard all of our dialogue.
So if anybody has things they think they want defined in the letter they know, because I told Harry I will be responsible for following this draft through. But other terms I thought would be interesting to define were plan. We have used the word plan in about four or five different ways today, so I think we need to be clear about which kind of plan we are talking about when we write this letter. It may turn out when the letter is written that there is only one kind, but that kind of hit me.
Also, testing and certification, what those words really mean. Then we had my favorites, which I know we will have to define for the full committee of processor and switch. It almost sounds like a comedy team or something. Dual processing I think we need to define. The one that Steve mentioned, which was one I stumbled across last summer when we were working on the function requirements of the NHIN. There is another NHIN, and there is only one word difference in their titles, and they mean very different things. So we need to be clear if that shows up in the letter that we define those, especially if the Nationwide Health Information Network comes up in the letter as a place for testing that can occur.
So those are my preliminary ideas right now of where we are.
DR. COHN: I guess I should help first of all with acronym collision here, by noting that as we described the acronym, it is actually nationwide.
DR. WARREN: Yes, it is, but there is also a national.
DR. COHN: That's right.
DR. WARREN: There are two groups.
DR. COHN: It is not two groups.
MR. STEINDEL: Yes, they are both different. The ONC is the Nationwide Health Information Network. What they were describing here is not the nationwide, it is the national health information network.
DR. COHN: What they are describing is a firm.
DR. WARREN: A particular organization.
DR. COHN: Right.
DR. WARREN: Which means both had to be defined here if we wind up mentioning that.
DR. COHN: Or we have to describe it in its long name rather than as an acronym.
DR. WARREN: Yes.
DR. COHN: I made some notes too as I was going through. I think a lot has already been said. I think that there is a view of certainly going forward. I do find it interesting that we have Don up here, but we don't have an NCPDP representative, because we have got a lot more questions about X12.
But I would just observe that I think we have had a lot less question about the NCPDP, versus X12. I think we all observed that there is perhaps more of an issue.
I am thinking back to our claims attachment letter. We probably need to review that with the recommended testing. Testing has a very different names and very different meanings. I think I heard in the testimony that there was some testing that resulted in standard certification, and then a bunch of testing that related to implementation processes and best practices and all of that.
I think as we try to make this definition better, and I am referring back to the claims attachment letter, that we had talked about that initial testing being done prior to promulgation of the final rule, to make sure that that information provided input into the final rule. So that may be a useful frame for us to think about that, just harkening back to something that we did previously or that might have applicability here. So I think that is a piece that might be helpful for us.
Now, I did find dual processing to be a very -- I know Harry has been doing dual processing for years in a variety of things, but I did think it was a very interesting concept. I think that it is an alternative to staggered implementations and a whole bunch of other things that add complexity to the implementation and may be difficult for CMS to in any way put into an NPRM or a final rule.
Dual processing does allow a wide variety of staggered implementations, if you think about it. It is a way of actually doing that. It may be more asynchronous. So it is just a thought of another tool that might help meet some of the industry needs on that.
Now, I did hear -- if I could read my handwriting, I could be so much better. That is why I got into electronic health records back in the '80s. One of the things that I did hear was CMS outreach. I heard it in a slightly different way this time. I think a lot of CMS outreach previously has been going around to places and talking about the standards. I was hearing it in some of our morning testimony as bringing together stakeholders, implementers to talk about implementation challenges and issues, and figure out strategies together, which I think especially in the context of dual implementation might be a very fruitful conversation, to see if it can help galvanize and move the industry. That is a recommendation more to CMS than something that would necessarily have to be absolutely implemented.
I think I heard a unanimity from the industry about the issue of two year implementation from publication of the final rule. Even though I think HIPAA provides shorter periods for updating standards, I certainly didn't hear anybody that was advocating for a shorter implementation window.
I also heard a lot of support for not doing it at the same time as ICD-10 implementation; whether or not there is some possible overlapping I think would yet to be determined on that.
So that was the final piece which I think were in the notes here that I couldn't read.
In all of this stuff, one of the questions that I have, having been through this once with X12 at NCPDP and others, and I think we are trying to avoid being in the situation where there is a 4010A, an A version of the 5010 or whatever. But I think we need help from the standards organizations that, for example, if there is testing and standards certification and additional review or whatever, how best that could be reflected in the next HIPAA implementation, without having to send anybody back to the drawing board, as well as without referring all the learnings into the next update, which might be two to three years hence.
So I think that is something where we need guidance and advice, and maybe something that CMS might query the standards organizations as part of an NPRM, I would imagine.
Anyway, I think it was very useful. Like Steve and others, I came away with a much different opinion about things today than I did yesterday.
MS. TRUDEL: I think I would just like to follow up on what both Simon and Judy alluded to. I heard the word testing used in three different contexts today, interchangeably and totally confusingly. The first kind of testing was the testing of the standard itself to make sure that it is makes sense and it is workable, which is what keeps us from going to a 5010A.
The second is the testing of a particular implementation or product, which is where the certification comes in. The third part is the actual live testing between two parties. They are all important, but they all occur at different times. They have different requirements, they have different participants. I think when we do those definitions, we need to keep those three things separate.
MR. REYNOLDS: Denise, do you want to make any comments before I make mine?
MS. BUENNING: No, I think everybody has already covered my comments, thank you.
MR. REYNOLDS: Okay. I guess what I take away is a really well defined list of the 5010 changes, which Don, thank you, whoever helped you. All of you did a great job on that.
It is obviously the same transactions we did with HIPAA 1, even though there is not a HIPAA 1 or HIPAA 2. Those are not words of art. Individual changes on the 5010 are for good business reasons, but not compelling when added together, and no huge jump in ROI, and they are costly. So we heard those, I think.
5010 may be a necessary part of the HIPAA journey and a momentum that if stopped could be viewed by some as positive or it could be a major impediment for the future. If we are really on a journey to standards, we are at a crossroads today, that with all the changes that have come up in the last five years which is a thousand or more changes that were submitted for this, every year that it goes on -- as a matter of fact we heard from the Dental Association today that they are already looking at the next set for some other things. So business doesn't stop, needs don't stop. If the world is going to buy into the HIPAA journey, this is a logical next step in the HIPAA journey.
Pilot and implementation testing may be a little more central. Right now, what I heard in the discussion was, maybe you do it a little more consistently. Right now, every entity has set it up in a different way. If it was set up a little more consistently in some way, and once everybody got to the same level of editing, then the provider only had to do it one way and it was much better.
As you get all the entities that want to test grouped up whether it is CMS and payors and clearinghouses or whatever that turns out to be, and providers, and get that a little more central and a little cleaner process, then you can have people do things a little better going forward.
Some type of certification, I thought that was interesting. As a committee we are always hearing about CCHIT and the CHR and other stuff. We are dealing with probably bigger and more imposing systems and changes right now, not necessarily in the future, but right now. So that could be a process that we would consider.
Another thing I would like to see us consider is, going back to our ROI letters, is making sure as we do 5010 -- and Jeff mentioned what happens over this next year on business cases, taking a look at the transactions that aren't as heavily used now, and making sure that the business case that 5010 would bring to the table is well known by the industry, because if we write HIPAA the second, it would be nice to pick up some of those things that we had noted in one. The other things that pick up that ROI I think would be a good service to everyone.
Definitions need clarity and ongoing work. So maybe we need to cerate some terms of art, whether it is staggered or sequenced or whatever it is, and once it is out there, it is out there, so people are using the same rhetoric, because different rhetoric in the same room means that we aren't together. As an industry and as the whole group we have got to make sure that people are talking together and staying together, whether it is education or anything else. You use that word outside of the people in this room, everybody makes their own decision, and now they are either together or completely apart.
I heard 5010 and ICD-10 sequentially. I heard that consistently throughout the day. Do 5010, get it in place, then do ICD-10.
I made four or five pages of notes of a possible letter. Those would be my comments. Since a lot of us are moving right away onto secondary uses, I have asked Judy to work with me and Denise to try to get something together out of what we hear today so that we can start working on it right away, and then start getting something out, taking everything that everybody said plus anything else that we add as we go along.
Comments?
DR. COHN: Yes. I think the direction you are describing is fine. I do want to publicly comment that the NCVHS does willingly accept letters and comments from the public on all these issues. We have received letters before today. I welcome letters after today and ongoing.
I do this for the public record. There is one letter that I am looking at that included Avamed and HIMA and American Hospital Association and American Medical Informatics Association, Premier, Federation of American Hospitals, Siemens and MDMA. I have no conflict of interest other than that I am a member of AMIA. But we do elicit and welcome additional public input on this stuff as we move forward through our deliberations.
Having said that, I am curious in your view of what you think are the next steps in terms of this issue.
MR. REYNOLDS: I think the next steps are that we all just summarize what we thought. I think I hear from the committee the minimum is that we would want -- you could go as simple a letter as, we heard enough from the industry, we heard enough questions and issues. It needs to now be clearly surfaced so that the process starts, so that other public comment and processes need to go. You could go as simple as that letter, which I think we all agreed on. I didn't hear anybody disagree that we should consider recommending that the NPRM go out.
Now, I think that we need to start immediately, which we will, taking some of those other things that we seem to have a good synergy on. Steve started it off, and you heard people build off of that. Those things were pretty clear. I think we need to try to put some of those down. It is probably important enough to try to get something out for the September meeting, and if that is as basic as the NPRM with a further letter to follow as we would work it, or make sure that if we got four or five other things that we want to definitely put in it, we are going to get started on trying to put some straw person together, like immediately. I think that is what we need to make sure that we do, and put together a conference call fairly soon as to what that might look like, so that the committee says I agree with one, two, three, four, five, and then we put the right words around it and make a letter.
So I don't see any other way to do that, because if we don't do it in September, then we do it in December. That would be fine too, but CMS would rather have us consider something sooner. So that is what I am saying. We know number one. I haven't seen anybody say we don't want to recommend that an NPRM go out.
DR. BLAIR: Can I add an observation on this? There are a number of times when we have gone through this process. This value of a particular standard is very clear, and the value of going forward is very clear. We have tended to look upon the NPRM process as something that is a bureaucratic necessity.
This I think is different. I think if we don't recognize the difference we may fail to take advantage of this. In this case, I think we are looking at the NPRM to do three things. Number one is to alert the industry that this change is coming, and to try to get the attention of the industry to start moving.
Number two, it is giving us time to strengthen that business case, so when these issues come up again, we are on more solid ground. Number three, it is going to help us to clarify exactly how the testing would take place, when it will take place and who will wind up coordinating it and/or performing it.
MR. REYNOLDS: Say number two again, Jeffrey.
DR. BLAIR: Number two is that it is giving the industry time to pull together a stronger justification of those indirect and multifaceted justifications that we have heard here but are not on paper, that we may need to have set forth in a more compelling manner six months, a year from now or a year and a half from now. So it is buying time for us.
Then the third piece is that it is going to be a process that will help us shake out and define exactly how the multifaceted testing process should occur and what coordination will be necessary to be sure that it proceeds on time and on schedule. It seemed like everybody was talking about the testing process as a vehicle to try to avoid another situation where we come to the final deadline and people aren't ready.
So the testing that I was hearing was saying, let's get the testing done first so that we won't have another delay.
MR. STEINDEL: Picking up on what Jeff said, I agree with him. I think the way the letter should be shaped is, there should be a very simple statement, that we think the NPRM for 5010 should go forward. But I also think there should be a second part of the letter that picks up on Jeff's points two and three.
Judy listed a whole bunch of things, you did, Harry, Simon, you did, of things that we heard that we want clarification on. I think we should have a second section in the letter that is also relatively short but basically says, in an NPRM CMS should seek comments on the following points, and listing a lot of the things that you have in your four pages of notes, what Judy listed, what Simon listed, just very short bullet points. NCVHS could be suggesting that CMS use the NPRM as a mechanism to find comments from the industry on things that we are interested in and how to improve the HIPAA process as well, which is a lot of what this relates to.
DR. COHN: I think I agree. What we want to do is, we want to assist CMS as it begins to think through the developing of an NPRM and questions and all of this. I do however want to take an opportunity, since Jeff has said this a number of times, to maybe provide perhaps a different view of return on investment and the benefits.
I think I listened just like Jeff did. I think I heard something very different though than he did. Maybe this is a slightly different view of the world. First of all, I heard a very significant benefit being identified by almost the entire pharmacy industry, of moving to a newer version of NCPDP. So describing this as not having cost-benefit I think is missing part of the point.
I also heard -- and I once again reflect on pervious letters that we have written, where we have talked about the real ROI for HIPAA being the non-claims transactions. So I think when I hear comments and proposals coming forward to increase the utility of the non-claims transactions, things that right now are not useful but that will become useful, it makes me believe that there actually is.
Now, can they come forward and give dollars and cents? I think that is the responsibility of CMS assisted by the industry, in terms of an NPRM. But I didn't come away from the conversation today feeling that nobody had identified any value or return on investment for the change.
Jeff, I wouldn't have commented, except you said this a number of times today, and I thought I would provide my input on that.
MR. REYNOLDS: Remember, I asked Larrie Dawkins to specifically go into that. That is one of the reasons I mentioned it here, because those would be the ones that would be very helpful to all of us. Karen had her hand up.
MS. TRUDEL: Let me clarify how this process works, because CMS doesn't get to make these decisions. These are HHS regs and they have to be cleared and discussed through the policy makers at HHS. So it is really very, very important to make sure that these letters convey all of the appropriate information for the many policy makers we will have to engage in this process, who are not in this room, are not part of this discussion, and will just be looking at that set of recommendations.
Most specifically, there are things that came out of the discussion about whatever sequencing means, and whatever pilot testing means, that the committee is going to recommend be included in an NPRM. That is very important. If there is a distinction, and the committee isn't prepared to make a recommendation and simply says we should solicit comments, that is an important distinction, too.
So the letter really needs to inform people who aren't in this room.
MR. REYNOLDS: Simon, back to your question and next steps, that is why if we start from that base of the NPRM and then we pick the things that we know we agree on, because we would have another opportunity in December to send a followup if necessary. In other words, we need that one in September, we know that.
Again, our goal is to try to get any letter we want, any key comments in by September, but we are going to have to see how that plays here and plays with the full committee as we go through it.
DR. COHN: I think that if we are going to come forward with the letter on this one, we need to come forward with a letter, not a letter in three parts. We may determine that there are issues that deserve additional public testimony, and we might so indicate in the letter and then have that public testimony for December. But I think we should try to provide our best thinking on this.
When I was asking you about what was going on next, I was thinking that it sounds like there is a desire by the subcommittee to come forward with the letter for full committee consideration in September.
MR. REYNOLDS: Yes.
DR. COHN: It sounds like there will also be at least one and potentially a number of open subcommittee conference calls to consider that letter and develop a letter for the full committee between now and September.
I know this is a pleasure for everybody in the middle of summer, but I still think that given our testimony with all this stuff, --
MR. REYNOLDS: I am in total agreement with everything. I didn't want to oversell. In other words, I think we heard clearly from everybody, and that is why we went around the room, that we have got to put something together that we can quickly agree on the structure, agree on the things that are in there, and then make sure we get them fleshed out well in advance. So I think we are all in clear agreement. It is just exactly what that is and what exactly those words are that we have got to get on right away, and we have committed to doing it.
Is there anything else anyone has? Everybody got to say everything they wanted. We opened it to the public a number of times, and we are done an hour and 15 minutes early.
MR. BECHTEL: If I may make one rebuttal statement. In listening to Steve's comments, I agree with most everything he said, but the one point that I keep thinking about over and over again since he said it was, the changes that we see in 5010 are mostly technical.
I would really disagree with that. I think the changes that you see that are most significant in 5010 are business rules, of how to form and complete the transactions. This will significantly impact the success of these transactions in the industry. Maybe there won't be cash ROI, but there will certainly be a smoother implementation and a better use of the data. It will just make everything work better. I don't view it as technical.
So I just wanted to make a clarification on that.
MR. REYNOLDS: If I could make one followup comment. When you take situational fields and make them required, getting the NPRM in will be important, because that basically takes something that was discretionary and makes it mandatory, and will generate comments. I'm not saying it would generate them bad or good, but back to your business rules, you are taking something that was used in certain cases, and now it is either gone or required. Those are the kinds of things that drive business differently.
DR. WARREN: I just want to clarify with Don, when you are talking about business rules, how you fill out the slots or fields or whatever you want to call those little boxes, and Steve can clarify this, but when I was thinking of the business case for going to this, I am talking about going to the board of directors and being the CIO that has to request the budget to implement that. That is what we have not heard. We should probably make that distinction between the business case and the business rules.
MR. REYNOLDS: Yes. That is why I made the statement earlier, they are for good business reasons, but not necessarily have we heard a compelling business case.
DR. BLAIR: Simon, when you indicated that you thought there were compelling business reasons for going forward, I agree, and I saw those. But the most compelling ones that I saw were not the individual changes for business rules. They were things that were indirect, that were synergistic, that were related to. Those were very compelling, in addition to the specific things.
But what Judy just said is the thing that I have been concerned about, that there is going to be six months or a year from now, a lot of folks who are going to go out there trying to get their corporations, their hospitals, their medical practices to begin to move forward on this. They will be told, like they have been told for a long period of time, we are going to wait until it is mandated, and we are trying to see if we could get things to move forward before there is an ultimate mandate and things working the last minute.
At that point in time, if we could take advantage of the time between now and then to provide enough education where we can start to quantify, that is where I am talking about a business case. We have some quantification that you could show that executive officer that we are going to save money on this. Then you get a whole different way of moving forward than if we don't take advantage of this time.
MR. REYNOLDS: Using the word journey, the journey makes good business sense, not necessarily good standard sense only.
MR. STEINDEL: Despite Don's comment, I stand by my original statement. I think I made it in large part because of the conversation we just had around the table.
MR. REYNOLDS: So noted for the record. Any other comments from anyone before we adjourn? With that, thank you for your attention and focus, and we appreciate everything you had to say. That's it.
(Whereupon, the meeting was adjourned at 4:18 p.m.)