November 28, 2000
By: Lee Barrett
Vice President of Global Healthcare for Complete Business
Solutions, Inc. (CBSI)
Chair of the Workgroup on Electronic Data Interchange (WEDI)
Mr. Chairman and members of the committee, I am Lee Barrett, Vice President of Global Healthcare for Complete Business Solutions, Inc. (CBSI) a publicly held corporation headquartered in Detroit, Michigan. I have chaired and served on many industry committees. In particular, I am currently Chair of the Workgroup on Electronic Data Interchange (WEDI), Executive Director of the Electronic Healthcare Network Accreditation Commission (EHNAC), past Chair of the Insurance Subcommittee ANSI ASC X12N, and a Board member of various healthcare organizations. It is in my role as Chair of WEDI that I am here today to testify on the activities of the WEDI, the Strategic National Implementation Process (SNIP), and the work they are doing regarding data issues.
Let me begin by first quickly describing how WEDI/SNIP is organized.
WEDI/SNIP is a consensus-based organization, where the work and recommendations of this group process are the opinions of its members. Membership to WEDI/SNIP does not require membership to WEDI. WEDI/SNIP is truly an open industry process.
I am working closely with the SNIP leadership to provide industry insights to their work, to bring other qualified individuals to the process, and to help the group work efficiently and effectively with highly political and complicated issues. I am uniquely qualified to do this from my years of experience as chair of X12N and WEDI.
SNIP has three key Work Groups, two are focused on specific areas of the HIPAA regulations and the third is focus on helping to provide education and awareness to the industry on HIPAA related issues and information forums.
Due to the purpose of today’s testimony, my comments will be focused specifically on the work being done by the transactions work group.
Through industry consensus, the transactions work group is committed to developing a national plan for the implementation of the HIPAA transaction standards. The goal is to define a sequence in which the industry will implement these transactions. It is important that the industry work in coordination on the implementation, as each transaction carries many information dependencies for subsequent transaction processing. Without this coordination, we will have many problems.
Further, by coordinating our implementation strategy, we can more efficiently utilize the limited resources that are available to us for such a large undertaking. If we can focus our activities on the right tasks at the right time, we will have much less confusion and the implementation process can be more orderly for everyone.
The Transactions Work Group, like each work group within SNIP, is committed to reaching out to the industry in as many venues as possible. We are seeking, as much input we can gather, and working to validate our recommendations and defined best practices through consensus building discussions. These discussions will occur on many levels, through conference calls and quarterly face-to-face meetings. We are also planning to have frequent audio cast discussions for each transaction and plan to discuss new issues associated with each. In addition we are distributing white papers and proposals via our web-site, and we are hosting a written discussion forum where anyone can openly submit comments to our documents.
We will look to identify issues regarding the transactions from the same venues just described.
Our web-site will be a way for organizations across the industry to submit issues that require a solution or best practice from an industry consortium. Through this vehicle people can fill out an issue form, by work group, and submit it to SNIP for consideration.
Also, during our audio casts we are planning to have a period for the listeners to ask questions either about what was discussed or to raise new questions or issues about the transaction in discussion, which weren’t already raised. These new issues will be captured by the sub-work groups and added to the Issues Database.
Most importantly, the work being done by SNIP is also being coordinated with the industry experts from the Designated Standards Maintenance Organizations responsible for these transaction and code set standards. Thus, we are not writing solutions to issues that are not in concurrence with those organizations. Further, we are not duplicating work, in fact, we hope to reduce the amount of redundant work by forming working alliances.
SNIP is working diligently to gain as much collaboration as possible. Not only are we working to involve those organizations performing similar tasks (e.g., AFEHCT, HCFA, NCHICA, UHIN, MHDC, MEHUG), but we are also working to help create local efforts that might be tied into the national effort being done at SNIP. These efforts to create regional SNIP-like organizations are being championed by the Education and Awareness Work Group. Also, working on this process, are many health information system vendors, clearinghouses, payers, and providers.
The list of those involved and new organizations that are being formed at the state or other local levels are growing daily. This is one more reason for having a plan, which encompasses a national scope. Without an organization like SNIP to help provide a national perspective to these local efforts, we could end up with many variations, which could create implementation problems for those organizations (payer, provider, or clearinghouses) that must operate on a national level and not just a local level. In today’s health care system this issue effects just about everyone.
In an effort be as efficient as possible, the Transactions Work Group has divided into several Sub-Work Groups (SWG), each focused on specific implementation issues. These work groups include,
Sequencing –This SWG is responsible for creating a transaction deployment plan that sequences the implementation of each transaction throughout the implementation period.
Data Review – This SWG is responsible for identifying data ambiguities and inconsistencies within the transaction implementation guides.
Translations – This SWG is responsible for identifying data translation issues between data and code values used in today’s environment versus what will be required for the HIPAA transactions.
Testing – This SWG is responsible for identifying testing methods that can be used by the industry to reduce the effort needed to perform testing during the implementation phase of these transactions. We must be able to reduce the time that is spent on this activity or we will not be able complete the implementation task in the time that has been given to the industry.
Business Issues - This SWG is responsible for looking at issues related to business problems that may evolve as a result of implementing these transactions. In particular, data that might be missing for an entity to perform needed business functions where work-around or best practice solutions will be needed.
Each sub-work group is working with a common set of goals, just described in our mission statement, and they are using a common process and tools to complete our work.
The Transactions Work Group has developed an Issues Database as a key tool for tracking and maintaining a list of issues and questions related to the implementation of the HIPAA transactions and security and privacy requirements.
This database will also be our tool to communicate recommended implementation strategies or best practices for specific issues to the industry.
We have developed a template for collecting, tracking and reporting issues by type, transaction, or regulation requirement, so that they can be easily searched and referenced by the industry.
Issues will be submitted either by forms sent to the transactions work group via the web-site, or from the activities of the sub-work groups, or from comments received during an audio cast. However, before an issue is added to the database, some research may be required to determine that an issue is one that should be addressed by SNIP rather than by another organization. For example, a policy issue may be directed to the Department of Health and Human Services, or an X12 transaction change request may be directed to the DSMO process.
Entries into the Issues Database will capture information about how the issue can occur, and document a resolution or suggested best practice. The sub-work groups will also describe their rationale for each decision.
As sub-work groups develop a position on significant issues, they may publish white papers or proposals that will be posted to the SNIP Web-site for public review and comment. These white papers will include some discussion that defines the issues, documents a best practice recommendation, and describes the rationale for the recommendation being made. A written open discussion forum will provide another tool for industry involvement, feedback, and consensus building.
Comments to these white papers or proposals will be solicited from the Discussion Forum, also found on the SNIP web-site and during the audio casts.
The sequencing sub-work group is focused on defining a transaction deployment sequence. While developing the proposed sequence a number of issues were considered. For example, the time required to develop application changes and interfaces to support the transaction, time required to adequately test the transaction, and time required to migrate from existing business practices to the new transaction standard for each trading partner, which can often number in the thousands.
Also, considered were industry benefits. For example, transactions that have promise of an early return on investment to the implementers through improved processing efficiencies, these were considered for early implementation. Also, net new transactions that will provide significant improvement to the industry. On the other hand, replacement transactions that will have little efficiency improvement but offer more long-term improvements were considered for later implementation.
The sub-work group also took into account concerns for development time and migration. So, for example, in the case of claims, where many providers are already submitting electronic claims and little improvement was anticipated in the short term, it was also recognized that the transitional conversion issues would be much more difficult and a longer implementation period will be necessary.
There are other complexities, such as, some transactions are complicated and are not being done in an automated fashion today, these will require more time to develop. While other transactions have data requirements that span across several transactions. Meaning, it will not be possible to implement one transaction, without implementing a corresponding transaction. This lead to the need for grouping transactions during the implementation process.
| Group 1 |
Group 2 |
Group 3 |
Group 4 |
Group 5 |
|
| Transactions Groups |
837 |
270 / 271 |
276 / 277 |
278 |
820 |
| Beta/Pilot Testing |
Jul 1, 2001 |
Dec 1, 2001 |
Feb 1, 2002 |
Mar 1, 2002 |
May 1, 2002 |
| Health Plan Readiness |
Oct 1, 2001 |
Mar 1, 2002 |
May 1, 2002 |
Jun 1, 2002 |
Aug 1, 2002 |
| Migration Completion |
Oct 16, 2002 |
Oct 16, 2002 |
Oct 16, 2002 |
Oct 16,2002 |
Oct 16, 2002 |
This proposal considered input from many sources and constituents of the health industry, (e.g., AFEHCT White Papers, NCHICA (North Carolina Health Information Communication Alliance) transactions work group, UHIN’s (Utah Health Information Network) implementation plans, vendors, providers, payers, and other early implementers). It is difficult in our industry to gain consensus on such broad issues that effect so many aspects of our business without having different needs and requirements. Although, this proposal may not meet with everyone’s hopes, it is workable, and it has the support many diverse organizations that were willing to compromise some of their requirements for the greater good.
The schedule has three Implementation Phases, (i.e, Beta/Pilot Testing Period, Health Plan Readiness, and Migration Completion.
The decision making rationale considered issues such as, the two year implementation requirement, industry implementation experience, logical integration of business process and data flows, inter-transaction dependencies, and pilot availability.
Also considered were provider cost reduction benefits, transaction complexity, transaction volumes, State legislation (e.g., NJ HINT).
Industry reaction to this proposal has been varied, but after discussion most have agreed with the rationale. But, the most common objection is not to the phases, nor the order, but the timeline. There is considerable concern in the industry regarding the fact that there is not enough time to complete all these implementations, especially when one begins to consider some to the complexities that are now being found by the other sub-work groups. We know that several organizations will be asking to have the implementation period for HIPAA transactions extended by another 12 to 24 months.
With regard to pharmacy transactions, we are still waiting for more input from NCPDP.
The Data Review Sub-Work Group, in conjunction with early implementers, is reviewing the Implementation Guides for each transaction in the order identified by the Sequencing Proposal. They are paying particular attention to issues related to data ambiguities and inconsistencies.
Data ambiguities exist within an implementation guide, and are normally found with allowable data values. Several transactions have allowable data values that seem similar, and knowing how to use one versus another may require more definition. From an industry perspective, there may not always be agreement about what one value means versus another, but the goal of SNIP will be to define a “best practice” that the industry can agree to use.
Data inconsistencies exist when one transaction will use a different data value than another transaction to convey the same information. The data value options are sometimes not available depending on how one transaction work group chose to define their list of available values. In these cases, a best practice that will need to be chosen for one transaction that will be workable for other transactions, or it may be necessary to request the list of allowable values be modified.
The Data Review Sub Work Group is working in coordination with X12N. Since it is very likely that these two organizations will be working on similar issues, it is important that both organizations are in constant communication regarding their work.
Solutions to issues will be posted to the Issues Database and in some cases discussion threads will be started on the SNIP Discussion Forum.
The Data Review Sub-Work Group spent much of their time during the early part of SNIP developing the structure, controls, and the form for submitting issues to SNIP. This will be one of their most important tools and one that will be shared by all the Sub-Work Groups of SNIP.
Now they are beginning to conduct their reviews of the implementation guides. This work is being done in coordination with X12N. Because issues may be sent only to X12N or only to SNIP, it is most critical that we have an effective communication mechanism between SNIP and X12N. It is believed that SNIP can help play an important role in assisting X12N in managing these issues with the industry.
In fact, as we begin to prepare for our first audio cast, scheduled for December of this year, one of the co-chairs from X12N who helped to develop the X12 837 transaction will be a key speakers during this call.
It has been our observation to this point, that few organizations have been forthcoming with the results of their analysis for these transactions. One of the key objectives for our audio cast will be to put a focus on each transaction with the hope that we can draw out some o f the concerns that people are beginning to have.
The Translations Sub-Work Group is working to identify translation issues that will occur during the transitional period when not all transactions have been implemented.
These problems manifest themselves in several different ways. One example is when current data requirements used by a payer/provider application today do not translate well to the new data requirements as defined for HIPAA. This situation will occur during the transitional period, when some trading partners have converted, while others haven’t, which will necessitate translations between the new and old data values and content. The problem this creates, is one may be able to translate in one direction (new to old) but not the other (old to new), due to complex “one-to-many” data translations. This occurs when a data element in one scheme (old or new) translates to many possible values in the other scheme, making a translation decision impossible.
Some translators offer a solution by allowing users to hard code translation decisions, but these hard coded translations are not dependable and may actually create more problems if an improper decision is made. Many translators will not provide this function, believing these type of data issues should be handled at the application level.
By working with early implementers, we hope to identify these translation issues and best practices that may help to mitigate their impact. By using common mapping strategies or other tools developed by early implementers, we should be able to reduce the impact of such issues.
SNIP will work to develop mitigation approaches for issues such as these, where no best practices have been identified. By working with representatives from all aspects of the healthcare industry SNIP will work to develop common mapping strategies that can be use across the industry. This work will be done in collaboration with appropriate industry organizations.
Some issues that have been identified to date include:
The sub-work group is examining each of these issues. We are exploring possible data mapping strategies or implementation strategies the may help to avoid the problem.
Another area where translations become a problem is with paper forms versus HIPAA translations. The issue is, will the current paper forms used today have enough data and of the right content to translate into the required HIPAA compliant transaction. As you may know, many providers submit paper claims and these will need to translate into the appropriate content to do the necessary processing on the backend systems. In many cases clearinghouses provide this type of service, but if the content on the paper form is incomplete or won’t properly translate, the paper forms will need to be modified. AFEHCT has been working on this issue for several months and has a liaison to SNIP for this issue. We expect AFEHCT to identify the issues and SNIP will work in collaboration with them to identify industry best practices.
The Testing Sub-Work Group is developing a Test Plan Document, which will identify testing methods, test plans, and scripts that can be used as a starting point when providers, payers, and clearinghouses begin to discuss testing plans. The Test Plan Document can be used within individual organizations, and later between trading partners.
Testing resources are also considered, which include the computing environment such as networks, hardware, software, and of course version management. Staffing resources are also considered in the test plans.
Standardized test input and output requirements will be defined to perform common repetitive tests that will test valid transactions as well as error conditions. Documented expected test results will also be defined.
After the test plan has passed its final reviewed by the sub-work group, each transaction in the order recommended by the Sequencing sub-work group will be evaluated against the plan.
The goal is to avoid unnecessary development of multiple testing scenarios by establishing industry standards to conduct testing validation of transactions. Thus eliminating unnecessary redundant development and predictable testing plans that can be quickly and efficiently executed between all trading partners is a consistent way.
The Sub-Work Group will work to identify willing beta testers of the Testing Plan. From their early testing, we plan to improve the test plan and continually refresh it when required changes have been identified. This product will produce a set of industry best practices, identify testing tools that will help the industry complete the task of testing each implementation of these transactions quickly with some assurance that the quality of the implementation is sound.
To date there have been 4 issues identified for the testing sub-work group, coordination of test plans, which should be included in the development of the test plan.
The Development of the test plan and methods as just described is currently being developed.
The Sub-Work Group is defining how certification programs can help in transaction testing, and investigating available transaction certification or testing vendors and/or tools that can be used by the industry. They are looking to describe how each vendor or product defines certification and to what level transaction validation is applied. It is not our goal to recommend one vendor over another, but rather provide considerations to be used when a certification vendor or software vendor is being evaluated. While there are some known vendors doing this kind of work today, the sub-work group is soliciting input from larger EDI communities in the hopes of establishing a larger list of possible vendors or products.
The Sub-Work Group is conducting an industry outreach to learn from the experiences of early implementers and include their knowledge in our list of best practices, as well of other lessons learned. It is critical to learn from the experiences of early implementers and to disseminate that information through a central repository.
Regional groups will be asked to contribute to our test plans and best practices. Again, our main objective is to find a way to speed up this process, which has historically been very slow and difficult to insure we complete we complete the task on time with high quality implementations.
The Business Issues Sub-Work Group is responsible for identifying data gaps that will prevent an organization from performing required business functions. Where the new transaction is lacking the necessary data and the new data content and codes are inadequate to satisfy the business function. This Sub-Work Group is working closing with X12N as well as with the Data Review and Translations Sub-Work Groups.
The Sub-Work Group is also responsible for identifying other types of business problems related to processing these new transactions. Discussions have identified issues such as: performing and reporting edits, or knowing where data should be stored when it is not used by a primary payer, but may need to be sent to a secondary payer for coordination of benefits. These become issues where the Implementation Guide doesn’t provide direction, but general X12 rules may.
This Sub-Work Group is considering issues related to confusion between the regulations and required business functions. For example, should a payer accept transactions from a provider where there is no Trading Partner Agreement, even though the validity of the provider can be determined? Under what situations are trading partner agreements needed?
They will also be considering issues about the practicality of having smaller health plans implement these transactions 12 months later. It may be more realistic to give all organization 36 months to compete this work.
They will seek to determine best practices when possible, if we are unable to resolve an issue, WEDI will communicate with the appropriate regulatory group.
We are writing White papers where we have identified significant business issues, the following white papers are currently being written:
Data Content and Code Sets, this paper discusses issues such as the following. The impact of eliminating local codes, recommendations to add high-volume local codes to national ANSI standard, managing version control of data standards and implementation guides, how to deal with submissions of claims with up to 999 line items, and tracking codes for HEDIS. Also being considered are the needs for HEIC and Alternative Medicine Codes.
Front End Edits, this paper examines issues related to business edits versus compliance edits, edit processing for the transaction receiver, edit processing for the transaction sender, communicating data errors, mechanisms for responding, and recommendations regarding other error messages.
Public Infrastructure Funding, this paper reviews issues raised by Medicaid and other payers. Topics include, what shared public infrastructure components are required, how the building of these components should be funded, who should build and manage these components, how to support new code sets without local codes, and how to enumerate the identifiers.
Trading Partner Agreements and Companion Documents, this paper discusses issues related to when Trading Partner Agreements required or recommended by transaction rule, what should be included in a Trading Partner Agreement, whether they can be standardized, what is considered to be a Companion Document, and when they can be used.
Direct Data Entry and Web Browser Solutions are being considered by many organizations. There are many questions about what can and cannot be done with these solutions. This white paper will discuss these issues and provide industry guidance toward best practices regarding data content, transaction completeness, field lengths, and so on.
Implementing the HIPAA transactions will require a significant effort to complete. It will require many people and organizations to work together with common goals and common plans. SNIP is positioned to help the industry define these plans through collaboration and consensus.
We are early in the process, however, we are certain to find many data issues as we move forward. Because of this, it will be essential for SNIP to have a well established process, and it will be essential for the DSMO process be operational as well. There are going to be many issues raised that will need resolution. Some will require resolution from the DSMOs.
SNIP transactions Work Group must bring together many issues that require solutions, recommendations, and best practices that everyone can truly implement. The sub-work groups just described are composed of many people from many different organizations representing all facets of our health care system. We are very encouraged by their ability and desire to work together in pursuit of these common goals. It is only through cooperation such as this, that we can hope to accomplish the task of implementing the HIPAA transactions on a national scale.
We would encourage more organizations to get involved and ask that the members of NCVHS in your roles as industry experts and advisors let others know of our work and encourage those who should be working with us to get involved. We very much appreciate Dr. Braithwaite’s recent email, which encouraged people to get involved.
Mr. Chairman and members of the committee, thank you for the opportunity to testify. This concludes my statement.