Statement To
DEPARTMENT OF HEALTH AND HUMAN SERVICES
NATIONAL COMMITTEE ON VITAL AND HEALTH STATISTICS
SUBCOMMITTEE ON HEALTH DATA NEEDS, STANDARDS, AND SECURITY
Health Insurance Portability and Accountability Act of 1996 (Public Law 104-191)

A Perspective from Early Implementers of the HIPAA transactions for Administrative Simplification

July 13, 2000

By: Donald L. Bechtel
Strategic Advisor for
Healthcare Data Exchange Corporation (HDX) and
Shared Medical Systems Corporation (SMS)
Subsidiaries of Siemens Corporation

Mr. Chairman and members of the committee, I am Don Bechtel, an Advisory Analyst responsible for Strategic Planning at HDX, a wholly owned subsidiary of Siemens Corporation. I am also a co-chair of the Eligibility Work Group under the Insurance Subcommittee of the ANSI Accredited Standards Committee X12 and a board member of AFEHCT (Association For Electronic Health Care Transactions). On behalf of HDX and our founder SMS, now also a subsidiary of Siemens Corporation, I want to thank you for the opportunity to testify today as an early implementer of Administrative Simplification.

But before I get to the substance of my statement, I would like to first introduce SMS and HDX to those of you who may not know us. This will also allow me to update the information about us, which I provided to you during my previous testimony on August 6, 1997.

SMS

Founded in 1969, Shared Medical Systems Corporation has over 30 years of network computing experience, operating the industry's largest Information Services Center (ISC) and Health Information Network for application hosting, e-commerce, enterprise systems management, and managed Internet services. SMS specializes in information solutions for hospitals, provides process and structural consulting, application services and manages IT infrastructures. As the premier Application Service Provider (ASP) in healthcare, SMS's ISC operates health applications for over 1,000 health providers with connections to over 400,000 customer workstations, processes over 80 million transactions each day, and manages over 500 connections to payers representing 130 million covered lives. Based in Malvern, Pennsylvania, SMS reported revenues in excess of $1.2 billion for fiscal year 1999. More information about SMS can be found at www.smed.com.

HDX

Beginning in 1987, as a direct response to customer requests to help them with issues stemming from the expansion of managed care in the health industry. SMS began an R&D effort to determine how the operational improvements of electronic data interchange (EDI) could be made broadly available to all of the participants in the health industry. Our research indicated that managed care was increasing the interchange of administrative information by at least one order of magnitude over then prevalent indemnity care. The resulting increase in administrative costs threatened to consume the savings many felt could be obtained by managed care/managed competition.

To translate our research into operational experience, SMS established HDX in 1991 as an arm’s length subsidiary to provide EDI clearinghouse services to all participants in the health industry – providers, payers, and purchasers. As HDX nears the end of our tenth year, we are now processing over 7.5 million transactions per month between over 600 provider customers and more than 300 payers, including commercial and Blue Cross & Blue Shield indemnity and managed care health plans, Medicare, and Medicaid. The bulk of the transactions that we process today deal with health care related administrative and financial issues, including eligibility, claims for institutional and professional providers, claims for institutional pharmacies, remittance advice, and referral notifications and authorizations.

Our current eligibility service operates in an online real-time environment using the ANSI X12 270/271 transaction set. We currently process millions of real time eligibility transactions per month. Our eligibility service is integrated with a provider’s information system so that an eligibility inquiry transaction is generated as a by-product of other business functions (e.g., admission, registration, or scheduling). The resulting eligibility response transactions can be used to automatically update a patient’s account information at the discretion of the clerk reviewing the response.

Our remittance advice service is available to any health plan that supports an ANSI X12 835 transaction for institutional and professional health care providers. Our initial implementation of this service was provided to meet requirements for processing electronic remittances from Medicare. Those rules were implemented several years ago and were very successful in providing more efficient processing of remittance information. By automating payment postings within the Accounts Receivable application using these transactions, our customers realize savings in clerical time required while posting payments. By having more efficient and accurate postings to accounts, secondary billing procedures can be initiated sooner, thus improving cash flow. These benefits encouraged HDX to broaden the use of this transaction to other payers. We currently support several hundred payers and process more than a million remittance advice transactions each month.

HDX additionally provides a service for authorizations, referrals, and notifications using version 4010 of the ANSI X12 278 transaction, a service that is particularly useful to managed care organizations. Like our eligibility service, our implementation of the 278 transaction utilizes online real-time processing that occurs as a by-product of other existing information system functions (e.g., order entry for authorization requests and Emergency Room Admissions for notifications to a managed care health plan). This service is currently in production for only a few providers and health plans due to the fact that most payers are not yet prepared to do this type of computer-to-computer processing. HDX has definitely been in the forefront with this service, but our experiences to date indicate improved and more accurate information flows allowing savings in not only clerical staffing, but also reducing clinician administrative involvement and patient waiting times.

The claim transaction formats that we transmit today are mostly UB92 for institutional claims, NSF for professional claims, and NCPDP for pharmacies. We currently process more than a million claims per month. In anticipation of the release of the HIPAA transaction standards, we are currently developing an implementation of version 4010 of the ANSI X12 837 for institutional and professional claims and expect to have this in production later this year.

Administrative Simplification

As some of you may know, SMS and HDX were very early supporters of the legislation Senators Bond of Missouri, Burns of Montana, and Riegle of Michigan, and Representatives Hobson and Sawyer of Ohio formally introduced in September, 1993 as the Health Care Information Modernization and Security Act. This legislation received strong bipartisan and bicameral support throughout the health reform activities of the Congress under both the Bush and Clinton administrations. And we are very pleased that this legislation was enacted as a part of the Health Insurance Portability and Accountability Act of 1996 as Subtitle F - Administrative Simplification.

At SMS and HDX we have been working very hard to help our customers obtain the benefits of EDI transaction processing, using the same transactions called for by Administrative Simplification. We have been analyzing the requirements of Administrative Simplification, as they were defined by the NPRM (Notice of Proposed Rule Making), providing comments back to HHS, and we have been evaluating how best to incorporate these into the applications and services we offer our customers. As a result of our early start, SMS has developed application and product designs to implement these new requirements, with the enhancements necessary to meet the draft security regulations for one of our products already generally available. As is our normal practice, we are making heavy use of our customer advisory panels and user groups to validate our approaches and designs.

HDX has already begun to implement a number of the draft standard transactions into our clearinghouse business by upgrading our existing transactions to version 40.10 of the ANSI X12 transaction standards.

In other efforts to support transaction standards in our industry, SMS and, following its foundation, HDX have participated in the development of transaction standards, including HL7 since the early 1980s and ANSI X12 transaction standards since 1991. SMS and HDX have also been working with organizations such as AFEHCT and WEDI to help develop recommendations on the implementation and practical use of such transactions within our industry. In fact, my statement today reflects the work currently underway within AFEHCT and WEDI. At AFEHCT, I led an effort to develop several white papers regarding the implementation of the transactions for Administrative Simplification. And, at WEDI, I am co-chairing a work group within the Strategic National Implementation Process (SNIP) that is preparing recommendations for a national implementation of the HIPAA standard transactions. I will make more specific references to these efforts later in my statement today.

The AFEHCT organization would like to make their White Papers available to the members of this committee, but we request that they not be added to the public record at this time. As these are a work in progress and are not yet ready for full public review. However, AFEHCT believes they will be useful to NCVHS as you consider the issues being discussed today. I have brought with me both paper and softcopy of these White Papers, which cover the following topics:

• Sequencing of the Implementation of HIPAA Requirements – Transactions and Code Sets
• HIPAA Testing and Certification Assumptions and Work Plan
• Business Front End Edits
• Model Contract Language Clauses
• HIPAA Awareness Building and Communication Plan

Conclusions

1. EDI can deliver substantial saving to the participants in the health industry.
Although SMS and HDX have not implemented all the components of Administrative Simplification, we have implemented a number of the transactions that have been adopted for implementation by the Department of Health and Human Services as required by HIPAA. Through these early implementations we have demonstrated that both “trading partners”, the provider and the health plan, obtain benefits from processing administrative business functions electronically. Additionally, clearinghouses that provide formatting, editing, and transmission services for these business transactions will receive further business improvements from content standardization and the robust transactions formats that meet the business requirements of all organizations. One of the most important benefits of HIPAA is the standardization of data content for these business transactions. Here are a few examples:

• St. Mary’s Duluth Clinic Health System wrote – “while verifying approximately 150 errors that ranged from no policy number to subscriber not found, I was thrilled that I could correct this report in a matter of a few hours rather than weeks.” They used the eligibility transactions to correct this report.
• Cape Fear Valley Health System wrote – “Integrated eligibility and electronic remittance advise are two key components of the applications suite which has enhanced the cash resources at Cape Fear by $30 million and decreased AR days by almost 30%, bringing them to the lowest level in 10 years.”
• Ohio Medicaid wrote – “The flavor of Medicaid services is changing quickly. We are seeing more HMO and Third Party activity because of the surge in managed care. HDX’s eligibility service helps us tremendously because we can respond quickly to the large volume of eligibility inquiries we get from providers each day, most with little or no involvement by Medicaid personnel. Before using the real-time EDI eligibility service, 80% of the calls received in the Medicaid office were for Eligibility verification. With eligibility verification online, that number has decreased tremendously giving the Medicaid Telephone Unit time to work on other billing questions.”
• Phoenixville Hospital wrote – “Electronic remittance automation has enabled us to reduce costs, enhance cash flow, increase revenue, … and free staff for other assignments. With electronic remittances Phoenixville eliminated 20 hours of work each week. Automated payments to Phoenixville eliminate keying errors and greatly reduce reconciliation problems.”
• Vendors like SMS will realize reduced development time for these B2B (Business to Business) transactions and faster deliver of modifications to market while lessening application impacts. The reason for this is that we will only have to focus on one implementation of these transactions, not one for every trading partner (or more), which is our experience today.
• Clearinghouses like HDX will also experience reduced development time for B2B services and faster deliver of modifications while lessening application impacts. Like vendors, clearinghouses will only have to support one transaction standard except where we support proprietary implementations for those trading partners in need of translation services in order to meet HIPAA’s standard transaction regulations.
• The bottom line is these transactions work, they’re efficient, they reduce the cost of these business transactions, they reduce errors in data, and free people to do other important work. Providers will be positively affected in terms of return on investment because of the standard transaction formats and the efficiencies they make possible.

2. New transactions should be promulgated
External notifications of admission, transfer, and discharge, a transaction that did not exist when the HIPAA legislation was drafted is now available and can now be quickly and easily implemented. It is our recommendation that this function should be considered for the next round of transactions under Administrative Simplification. The ANSI X12N implementation guide for this function is complete and ready for adoption.

3. Workflow integration (application integration) is the key
Our experiences have taught us that to really reap the benefits of EDI, it is important to integrate the transactions into the business operations of the customer, and this is best accomplished by integrating the transactions into the supporting applications that will use the data being exchanged. For example, making an Eligibility inquiry part of the Registration or Admission process allows the response data to be captured and stored with the patient accounting record. This captured data can then be reused to complete other business functions for that patient, for example, to determine whether authorizations are required, or to execute an authorization request, or to capture an authorization or certification number that must be submitted with a health insurance claim. This approach is being done today by several SMS applications which utilize HDX services to request and receive information between our providers and payers, saving thousands of dollars each year and reducing the staff hours spent completing these essential business functions within their organizations. However, without integration, most these benefits would not be realized.

4. Data translation issues require careful planning
Translation issues related to transactions can also be thought of as a sequencing problem. However, the concern is that several transactions actually operate in coordination with another transaction. In these cases, it may be necessary to move the same code sets or data values between both business transactions (e.g., a claim and remittance advice, or a claim and claim status, or an authorization and a claim). If all of these transactions are not converted to the new X12 4010 standard at the same time, then there can be translation issues between the new transaction standard and the old transaction.

The HIPAA transaction standards require additional data content for many of the business transactions that are being done today. This additional data is not always required, it will depend on various business situations, but where these situations exist the additional data must be added. These new required data elements must be collected by the business applications and their user, I don’t believe an EDI translator will always be able to add such data. Some examples of these new requirements in the claim transaction are “Billing Provider”, “Pay To Provider”, and “Service Facility”, which must be kept as discrete data elements. Another example would be “secondary identifiers”, which appear in many different places throughout the claim. We have found on the claim at least 150 such discrete data elements that will need to be accommodated. Some of these might be combined with other data elements, but this will depend on how the application system vendor wants to store and use this data.

Translation issues exist for codes as well as new data content. For the code sets (clinical and X12 codes alike), there are instances where we have a “many to one” translation concern, where it may not always be possible to move between old to new and new to old formats via a translator. Also, there are cases where the data content of a new transaction would have no place to exist on an older transaction format or the data field size is not large enough to accommodate new data requirements resulting in lost or truncated information.

These concerns are being studied by WEDI and their SNIP project (the Strategic National Implementation Process). It is expected that recommendations will be made on how the industry might handle such issues during implementation. I expect SNIP to identify one of several choices. (1) The industry should carefully synchronize or group the implementation of transactions and codes sets where interrelationships exist. (2) The industry may need to develop a mapping table that everyone would use during the transition. (3) Other solutions may also be needed, for example, in the area of drug codes and the differences between HCPCS and NDC coding schemes a different suggestion is currently being considered.

There are concerns related to stored data within the many data repositories and data warehouses that are kept today for such things as, institutional studies of disease management; local, state, and federal reporting; research, and so on. Analysis and careful consideration will be required to determine if and how these will be converted to take advantage of HIPAA data standards and code sets. Both administrative and clinical analysis efforts often look at trends over time, with rather large amounts of data and a length of time important for many studies. The current HIPPA approach is focused on operational interfaces and data content, but there is the potential for a tremendous disconnect in analysis and reporting capability if the coded historical values and identifiers cannot be accurately compared to the new standards. A number of statutory reporting requirements may also be affected by the inability to create accurate comparisons or historical reporting if identifiers and code values cannot be consistently compared and grouped.

5. The transactions should be phased in following a logical sequence.
The industry should define a logical order and timing for the implementation of individual transactions. We need to have an orderly process by which the vendors for all entities can anticipate the sequence in which they must complete their work. To attempt to have all these transactions and underlying application support ready for every transaction to be implemented in random patterns across the country is going to create severe resource issues and confusion. Such an approach could compress implementation windows as vendors try to get all the required features ready at once instead of approaching the implementation in small steps. A big bang approach will undoubtedly raise the cost of development and implementation as we deal with support issues related to the thousands of implementations that will be required across the country for these business transactions and the associated application and security enhancements needed to support them.

There is already arising the very real possibility that many smaller regional implementation plans are being developed across the country that will choose to implement the transactions in a different sequence or with different dependencies. This will create more confusion during the transition from our current business practices to the new HIPAA established EDI transactions. We are hopeful that these organizations will get involved with the work being done by AFEHCT and the WEDI SNIP project. This will allow both their plans and the work being done on a national level by SNIP to be aligned, creating a more unified approach to the implementation of the transactions, code sets, and new data requirements. Organizations such as NCHICA, who will also be testifying, have put a lot of time and thought into developing their plans to implement these same components. This work should not be ignored but should be included in the planning being done by WEDI. I should note here, that NCHICA is involved with both AFEHCT and WEDI. It is my opinion that all parties in the health industry (providers, payers, purchasers, clearinghouses, vendors, States, and others) must work together to have an orderly and successful implementation of Administrative Simplification.

Getting all entities aligned on a sequence and the timing of the associated implementations will be a challenge to us all. The work being done by the SNIP project will help the industry to address this and many other issues. I know that you will be hearing from the co-chairs of that work effort during these hearings. But, I would like to affirm that the work they are doing is extremely important and having the support of NCVHS will be essential to their success. All of the issues that I have raised today are being studied by the SNIP project.

6. Testing implementation time frames must be improved.
The methods used today are too time-consuming and labor intensive. Our current method of testing requires that we perform rigorous verification with each EDI trading partner to prove that our transactions and interfaces are working properly. For vendors and clearinghouses and even large institutions, EDI transactions are often submitted or received for multiple entities. In these cases, the validation process is often repeated with one trading partner multiple times, once for each submitting or receiving entity. Consequently, much of the work being validated has already been proven by one of the other entities. Similarly, this same testing is repeated with each trading partner, where validation has already been proven by another trading partner. For example, a vendor like SMS will submit claims for many of its providers throughout the country to a single payer; similarly a clearinghouse like HDX will do the same. We need to find ways to reduce this unnecessary and redundant work.

Verification of the transaction format and content is necessary to insure that, once these transactions are put into full production, there is confidence by both parties that they will be submitted and processed correctly. However, there is much concern that if we continue to take this approach for all our trading partners, including our existing trading partners when we convert to the new EDI transactions, we will not be able to complete the task in time to meet the implementation deadlines.

Our industry must find a way for trading partners to test and validate only once those features of our systems that will not differ from one entity to another, regardless of who the entities are or who the trading partners are for which the transactions are being submitted. For example, for vendors or clearinghouses that provides the service of insuring a transaction is compliant with respect to format and content, perhaps this could be proven once. Then, through some sort of certification process, which can be carried from one trading partner to another, we could assures each trading partner that certain implementation requirements are being met. Thus allowing trading partners to focus their testing on only those features that are unique to a trading partner’s connection or business requirements. Simply said, we need to find a way to standardize our testing to reduce the implementation timeframes.

Both AFEHCT and WEDI are reviewing this issue.

7. Chain of Trust and Model Contract language
Another concern shared by many clearinghouses and vendors is the need for a Chain of Trust. We completely agree that a chain of trust must be established. But, the industry needs to find a way to establish the chain of trust without having to renegotiate the thousands of contracts that exist today. However, at a minimum, we should establish simple model language, which would reference the rules where such requirements are defined that provide the necessary protections of data integrity and confidentiality. We believe that if such model language could be developed by the industry, it would help to shorten the contractual process. We further believe that if each contract must spell out these requirements, this will introduce many hours of legal review and interpretation extending the time needed to complete a chain of trust. Again, work is being considered within AFEHCT to develop such model language. It would be helpful, if this language were developed, for the Department of Health and Human Services to reference these models as good examples for completing this requirement. Assuming of course, that the language would satisfies the requirements defined by the final rules.

Mr. Chairman and members of the committee, this concludes my statement. Thank you.