[This Transcript is Unedited]
Hubert Humphrey Building
200 Independence Avenue
Washington, D.C.
Call to Order and Introductions - Dr. Cohn
Panel Discussion of Local Codes Issues:
Delineating the Problem
Panel Discussion of Local Codes Issues:
Examination of Tools and Processes that Could Lead to a Solution
Panel Discussion of Early Implementers:
Vendor/Clearinghouse perspective on implementation of Administrative
Simplification Standards that will be Required under HIPAA
Panel Discussion of Early Implementers:
Provider Perspective on Implementation of Administrative Simplification
Standards that will be Required by HIPAA
DR. COHN: Good morning. I want to call the meeting to order. This is a meeting of the Subcommittee on Standards and Security of the National Committee on Vital and Health Statistics. I am the chair of that subcommittee. I went to welcome everyone who is here, everyone who is here, subcommittee members and HHS staff.
I also want to welcome those listening in on the internet. I want to remind everyone today, if we could, to make sure you address your questions and comments into the microphones, so that people on the internet can understand what is going on, and understand the issues that we are discussing. I may remind everyone from time to time about those logistical issues.
The focus of the hearings over the next two days is HIPAA administrative simplification. As we all know, the purpose of the administrative simplification provisions of HIPAA is really to improve the efficiency and effectiveness of the health care system by establishing standards and requirements for the electronic transmission of certain health information.
Now, the role of the NCVHS in HIPAA is two-fold. One is, in complying with the HIPAA administrative simplification, the Secretary is to rely on the recommendations of the NCVHS. The other role is that the NCVHS has been asked to track implementation for both HHS and Congress, and identify implementation issues and barriers and recommend ways to possibly mitigate those issues.
The purpose of this hearing is to talk with early implementers from various health care industry segments, to learn the problems that they are encountering with early implementation, and also tools and solutions developed to address issues.
One implementation issue of particular interest is the local codes issue, which we will be starting out with after we have gone through introductions and a little bit of update from HHS. We obviously want to define the problem. We want to look at possible solutions. Obviously, testimony will help us develop sound, informed recommendations for the Secretary.
We do have a very full agenda over the next day and a half. We really appreciate everybody participation and the work of HHS staff in helping us prepare these sessions, especially Karen Trudel and Bill Braithwaite. We want to thank you for that.
With those introductions, let's do formal introductions around the table. I am Simon Cohn. I am chair of the subcommittee, member of NCVHS, from Kaiser Permanente.
MS. TRUDEL: Karen Trudel from the Health Care Financing Administration, Staff to the subcommittee.
DR. BRAITHWAITE: Bill Braithwaite from ASPE at HHS, and staff to the subcommittee.
MR. BLAIR: Jeff Blair, Medical Records Institute and I am a member of the Committee.
DR. FITZMAURICE: Michael Fitzmaurice, Agency for Health Care Research and Quality, one of two government liaisons to the committee, and co-lead staff of the computer-based patient record working group, a working group of the subcommittee.
MR. MUSCOE: I am Tom Muscoe with the Health Insurance Association of America.
MR. LANDEN: I am Rich Landen with the Blue Cross Blue Shield Association.
MR. ROSENSTEIN: I am Stan Rosenstein from the California Medicaid program, MediCal.
DR. ZELINGER: Jerry Zelinger, Center for Medicaid State Operations, Central Office, HCFA.
MS. NARCISI: I am Jean Narcisi from the American Medical Association, representing the National Uniform Claim Committee.
MS. BALL: Judy Ball from the Substance Abuse and Mental Health Services Administration and staff to the subcommittee.
MS. GREENBERG: Marjorie Greenberg from the National Center for Health Statistics, CDC and executive secretary to the committee.
MS. FRAWLEY: Kathleen Frawley, director of health information services, St. Mary's Hospital in Passaic, New Jersey, and a member of the subcommittee.
DR. ZUBELDIA: Kepa Zubeldia, with, ENVOY Corporation, member of the committee.
MS. FYFFE: Kathleen Fyffe, member of the committee. I work for the Health Insurance Association of America.
DR. COHN: Would those in the audience please come to a microphone and introduce yourselves?
MR. SMITH: I am David Kent Smith. I am the chief clinical officer with the GCPR Framework project.
MR. KILLIAN: I am Bart Killian with the Utah Health Information Network.
MR. MC BRIDE: Allen McBride of Blue Cross/Blue Shield of Michigan.
MS. BONNELL: Claudia Bonnell, the coding consultant at Blue Cross and Blue Shield Association.
MS. RILEY: Kay Riley, the Health Care Financing Administration. I am the HCPCS coordinator.
MR. CARTER: John Carter, Health Care Administration Technology and chairman of the Oklahoma Uniform Billing Committee.
MS. EMERSON: Mary Emerson, Health Care Financing Administration.
MS. MC GEE: Michelle McGee, National Association of State Medicaid Directors.
MS. DOYLE: Lisa Doyle, Wisconsin Medicaid.
MR. URBANEK: Fred Urbanek with Premier Sourcing Partners.
MR. FINEMANN: Brad Finemann, Care First, Blue Cross/Blue Shield.
MR. BARTHELT: Eric Barthelt with Computer Sciences Corporation.
MR. RODD: Roy Rodd, a professor of health care information systems at the University of Maryland, Baltimore County.
MR. TAVARES: I am Luis Tavares. I am the practice director for the National Health Care Practice at Computer Sciences Corporation.
MR. EMORY: I am Jack Emory with the American Medical Association.
MR. LAUDER: S.C. Lauder(?) from the Health Care Financing Administration.
MR. HARTMAN: Herb Hartman, Center for Medicaid and State Operations, Health Care Financing Administration.
MS. GUILFOY: Helene Guilfoy, IMG Health Care Consultants.
DR. COHN: Thank you. Before we begin the first panel, we have asked Dr. Bill Braithwaite to give us a little bit of an update on the progress of the final regulations.
DR. BRAITHWAITE: As you all know, the Deputy Secretary of HHS committed that HHS would have the first final regulation under HIPAA, the transaction and code set rule, ready to publish by the end of June. We did succeed in doing that, but it hasn't been published yet. There is still a bureaucratic stumble or two that have to be gotten over before we can put it out in the Federal Register.
My apologies that it is not out yet, but I have every expectation that it will be out in the very near future. All of the other regulations that are stacked up behind it, several of them are drafted and ready to go into the process that will get them published as well, but we aren't starting any of that until we get the first one out, for obvious reasons.
I did hear that the Secretary committed to this committee not too long ago that the privacy regulation would be out, I think by the end of the summer, I think is what she said, which is a surprise to some of us, but a commitment that we are working very hard to keep.
DR. COHN: Any questions from the subcommittee? Thank you very much, Bill.
With that, why don't we start on our first panel. Obviously, the subject here is the local codes issues, and just trying to get our hands around the problem, which is the first panel. Then the second panel this morning will be looking at possible tools and processes that might be able to help with the solution.
With that, Jean Narcisi, would you like to lead off the panel? Thank you.
MS. NARCISI: My name is Jean Narcisi. I am the director of electronic medical systems at the American Medical Association and chair of the National Uniform Claim Committee. It is my pleasure to appear today on behalf of the NUCC before the Subcommittee on Standards and Security of the NCVHS. I would like to thank you for the opportunity to testify.
My brief statement summarizes the NUCC's views regarding the issue of local codes. As you may know, a letter was sent last March to Dr. John Lumpkin, the NCVHS chair, expressing some concerns regarding the use of local codes and requesting that the subject be explored by the NCVHS.
The NUCC believes it is important to gain an appreciation of the magnitude of the problem and to discuss implications, such as industry facilitation or approaches for efficient elimination of local codes. A more thorough understanding of the problem and issues with local code usage by all parties will better enable a sound administrative simplification solution. Therefore, I am pleased to share with you the NUCC's perspective.
The subject of the use of local codes and the difficulty of converting Medicaid local codes to national procedure codes was raised at our February 16 and 17 meeting by Ms. Linda Connelly, member of the NUCC representing the National Association of State Medicaid Directors. In addition to Medicaid coding problems, several other NUCC members stated that the issue of local codes is not limited to Medicaid, but also affects private payers and providers.
The NUCC believes that the development and use of local codes is in direct conflict with the intent of the standards addressed by the administrative simplification portion of the HIPAA. However, we realize that a reliable process must be established in order to effectively convert local codes into a national system.
The NUCC represents many constituencies, and our discussions have been unable to identify the existence of any national process for recognition, establishment or maintenance of local codes or regional codes. In addition to the information gathered from these hearings, the NCVHS and the Department of Health and Human Services may want to formally survey payer and provider groups, regarding the current uses of local codes.
We had several comments regarding codes in the NPRMs that were published. The NUCC made several comments and I would like to review them with you. The NUCC believes that if local codes are adopted as part of a standard national code set, the modifiers that apply should also be included.
In addition, if temporary codes are established for certain code sets -- such as local codes -- there should be a mechanism developed to move these temporary codes into a national code set and the temporary codes should sunset after a specified period of time, perhaps the next regular update for a specific code set. Furthermore, the NUCC believes that code sets should be technologically independent of computer platforms and transmission protocols.
Therefore, any propose coding modifications to the national code set should be handled through the respective committees currently maintaining the code sets and the review process should include the appropriate affected parties. The J codes are part of the alphanumeric HCPCS codes and are assigned on an annual basis. Many of the local codes that have been created were developed because of the lack of a J code for a new drug.
Therefore, HHS proposed in one of the NPRMs that NDC codes become the national standard code set for drugs. The NUCC believes that this could create extensive system changes for providers and payers without sufficient benefits.
Furthermore, the NUCC believes that the issue of the J codes versus the NDC codes needs much more evaluation. Therefore, the NUCC supports the following recommendation: NDC codes should only be used for prescription drug programs, retail pharmacy claims and durable medical equipment that do not have J codes, until the sufficient benefits and overhead costs of implementing the NDC codes exclusively can be further researched.
One of the HIPAA NPRMs specified that those who receive electronic transaction covered by the transaction standards must be able to receive and process all standard codes, without regard to local policies regarding reimbursement for certain conditions or procedures, coverage policies, or need for certain types of information that are not part of a standard transaction.
The NUCC supports this position in order to standardize the implementations. However, the NUCC believes that the language in the final rule should expand to include reference to applicable code sets including the numeric or alphanumeric codes and modifiers, and associated narrative descriptions as well as the notes and guidelines published by the code set developer that instruct the user how to apply the codes and modifiers of the code sets.
In addition, the final rule should declare that the version of the code set applicable to a calendar year is the version specified by the developer as applicable for that year. This would promote uniform implementation.
I would like to talk a little bit about some other code sets. In addition to the local codes as they pertain to procedure and diagnostic code sets, the NUCC believes there are several other code sets used in electronic transactions that need to have an effective national maintenance process established, because there have been a number of problems with adding or modifying the codes. These code sets include the following:
Place of service codes. The POS codes identify the location where services were performed. POS codes are reported on professional paper claims as well as electronic claims. HCFA maintains the POS codes, however, the process for maintenance is not at all consistent.
For example: The NUCC was copied on a request to NCFA regarding the possible implementation of two new POS codes in March of 1999. The Administrative Uniformity Committee of Minnesota requested the addition of codes to be added for urgent care-office and urgent care-hospital. The NUCC reviewed the request and determined that the NUCC should recommend to HCFA that the NUCC take on the role as the reviewer of POS code requests.
At that time, the HCFA representative to the NUCC brought up a concern regarding the review cycle for POS codes. The HCFA representative stated that although HCF staff maintains POS codes and the comments regarding change or addition to the POS codes, there was no established cycle of review.
Apparently, Y2K concerns had temporarily halted implementation of any new POS changes. The representative further stated that they believed the administrative uniformity committee at HCFA would likely welcome the support of a national committee such as the NUCC, potentially taking on the responsibility of maintaining the system.
As a result of those discussions, the NUCC made a formal recommendation to HCFA that the NUCC become the maintainer of all place of service codes. To date, a formal response has not been received from HCFA regarding the NUCC recommendation to be the maintainer.
In addition, the administrative uniformity committee of Minnesota has not received a response from HCFA regarding the request for the urgent care codes. Therefore, a local code for urgent care is now used in Minnesota for electronically reporting services performed at urgent care facilities.
The Claims Adjustment Reason Codes. These codes communicate an adjustment from a third-party payer to a provider and give a reason why a claim or service line was paid differently than it was billed. The code set is maintained externally from the HIPAA transactions and implementation guides. The committee has no formal governing protocol and is made up of interested individuals from the X12 community.
However, the number of third-party payers greatly outnumbers the providers. For example, there are 11 payers on the committee, four providers and two vendor/clearinghouse representatives. Therefore, if a provider member requests a suggested change in nomenclature to a code, it is very difficult to succeed in getting the change approved because there is not a provider/payer balance on the committee. The primary distribution of this code set is the responsibility of Washington Publishing Company.
Then, there are claims status codes. Claim status codes communicate information about the status of a claim, whether it has been received, pended or paid. This code set is maintained by the same committee that maintains the claims adjustment reason codes, and the primary distribution of this code set is also the responsibility of Washington Publishing Company.
There are remittance advice remark codes. The remark codes are used to relay service-specific informational messages that cannot be expressed with a reason code. Remark codes are maintained by HCFA but may be used by any health care payer when they apply. Code requests are submitted to one individual at HCFA that managers all of the maintenance of the code set. Primary distribution of this code set is the responsibility of Washington Publishing Company.
There are the provider taxonomy codes. This is an external code set whose original purpose was to codify provider type and area of specialization for all medical related providers. However, the provider taxonomy code list is inconsistent. It appears to have been developed based upon a combination of services, specialties, fields of scientific study, as well as age of the patient.
The Blue Cross and Blue Shield Association acts as the administrator of the provider taxonomy code list. Therefore, the code structure is classified as external to X12. Ongoing maintenance is solely the responsibility of Workgroup 15, provider information, within X12N, and the members of the committee consist of interested individuals from the X12N community. As with the claims adjustment reason code committee, there is no formal governing protocol. The primary distribution of this code set is the responsibility of Washington Publishing.
Similar to the code sets that I mentioned previously, the process for maintenance is not at all consistent. For example: I have personally attended several provider taxonomy meetings over the past two years because the code list was not consistent with the AMA Physician Masterfile Database. The masterfile database includes over 160 specialties that are primary source reported from the American Board of Medical Specialties.
There were approximately 34 specialties that are part of the AMA masterfile that are not included in the provider taxonomy code list. Therefore, I attended the meetings and participated in several conference calls in an attempt to get the missing specialties included. However, to date, our suggested changes have not been added to this code set.
The NUCC believes that the above-mentioned code sets are considered data content and, therefore, should be maintained by the key parties who are affected by health care electronic transactions, those at either end of a health care transaction such as payers and providers. In addition, a reliable process must be established in order to effectively manage a national system.
Furthermore, the utility of these code sets may go beyond HIPAA transactions. For example, the potential for use of these code sets in the public health community is very conceivable if they are broadened to include codes for community health issues such as maternal and child health, prenatal care, et cetera.
As you may know, the public health community does not fall under HIPAA. However, there is a desire to standardize the transactions and code sets for public health reporting. It would be much more efficient and cost effective if the same code sets were used for both HIPAA and public health transactions.
So, our recommendation follows. The NUCC would be the appropriate committee to oversee the maintenance of the five code sets that I have previously discussed. The NUCC includes representatives of standards development organizations, regulatory agencies, public health and the National Uniform Billing Committee.
Criteria for membership includes a national scope and representation of a unique constituency affected by health care electronic commerce with an emphasis on maintaining a provider/payer balance. In addition, the NUCC would collaborate and coordinate with the other data content committees and standard development organizations named in the memorandum of understanding for managing the change requests to the transactions.
On behalf of the NUCC, I want to thank you again for this opportunity to comment before the NCVHS. I want to express my appreciation for the several opportunities that have been provided to date to assist the NCVHS and the department in fulfilling the responsibilities associated with Subtitle F of HIPAA.
As one of the consulting organizations specified in HIPAA, the NUCC is highly supportive of the development and use of national standards for electronic transactions. We look forward to working closely with the NCVHS and the other members of the MOU to maintain the standards that will provide our nation with an administratively simplified health care system. Thank you.
DR. COHN: Jean, thank you very much. Jerry Zelinger?
DR. ZELINGER: Thank you very much for the opportunity to be here today, to talk about Medicaid and local codes. I am Jerry Zelinger. I am a medical advisor in the Center for Medicaid and State Operations, HCFA. I am also technical director in our division of benefits, coverage and payment in the Medicaid program
What I would like to do very briefly is to do several things, provide an overview of the Medicaid program, briefly talk about Medicaid procedure and coding requirements from a federal perspective, talking about statute regulations and policy, and then address the question of whether, at least from the federal perspective, are special unique procedure codes needed by the Medicaid program.
The Medicaid program, which operates as a joint Federal-State entitlement program, is the third largest source of health insurance in the United States after employer-based coverage and the Medicare program. The Medicaid program pays for a broad range of services for certain groups of low-income individuals. These groups are disabled children and adults, the elderly, pregnant women and single parents.
Total Federal and State expenditures in 1999 were about $190 billion with the Federal Government contributing, on average, about 57 percent of the share and the states 43 percent of the total. There are approximately 41 million beneficiaries in the program, including 41 percent of all children now born in this country and more than 50 percent of Americans with AIDS. Managed care has become the major delivery/payment system in the Medicaid program. In 1998, 53 percent of Medicaid beneficiaries were enrolled in managed care plans, more than five times more than were enrolled in 1991.
States are given considerable discretion and control to run their Medicaid program within broad federal guidelines. States are given a great deal of flexibility in developing their program eligibility criteria, in designing their benefit packages and in determining how much to pay for covered services. Therefore, across the country the Medicaid program consists of 50 unique, very different programs with considerable state-to-state variation.
Medicaid coding requirements. The fact is that there has been very little federal guidance on the procedure codes that Medicaid providers should use on claim forms to enable the state Medicaid agency to process and pay claims for services provided to Medicaid patients. Neither the Medicaid statute -- Title XIX of the Social Security Act -- nor federal Medicaid regulations specify what procedure codes are to be used.
It has been longstanding federal policy that states are to use the HCFA Common Procedure Code System -- HCPCS codes -- for these transactions and updates of the codes are sent annually to the states. Level III of the HCPCS coding systems allows for the use of local codes and we, at the federal level, have allowed and even, at times, encouraged states to create local codes to meet their own unique needs. As a result, today most state Medicaid programs use their own state-developed codes to identify many of the services for which they pay.
We have heard estimates that 40 to 50 percent of all state Medicaid fee-for-service transactions use local procedure codes and we know that there is enormous state-to- state variation with, some states using local codes only, and others using very few local codes.
We also know that Medicaid managed care plans have not been submitting the kinds of encounter data that are often required under their contracts with state Medicaid agencies. The reasons for this are not totally known and probably vary by health plan, but the impact of HIPAA and the elimination of local codes on Medicaid managed care plans is likely to be significant.
Are special unique procedure codes needed by the Medicaid program? With HIPAA on the horizon, we know that state Medicaid programs as well as other public and private insurers will be required to eliminate the local codes they have developed.
The question, or one important question, is whether and the extent to which special unique codes will be needed by state Medicaid agencies to run their programs or will the standard sets of codes used by other insurers be sufficient?
In other words, how different and unique are the services covered by the Medicaid program compared to the services covered by other insurers? I know that some of these issues will be discussed by others following me on this panel and on the next panel discussing the resolution of the problem. I would like to briefly and simply describe the issue and landscape from a federal Medicaid perspective.
Local codes used by states now can be classified into one of three categories. One category reflects local codes which are, in fact, basically the same as existing national codes that adequately describe the services that are commonly provided and covered by other payers.
States frequently use these kinds of codes and they can be safely eliminated under HIPAA. There is another category of local codes that reflects services covered by Medicaid and other payers but where no national code currently exists to describe the services.
For example, services provided where no national code currently exists to describe the service. For example, services provided via telemedicine -- which is now covered by 17 state Medicaid programs and by Medicare -- and new and emerging procedures and technologies covered by state Medicaid programs and other payers, but where a national code has not yet been developed. These are two examples in that category.
There remains a third category consisting of a substantial number of local codes used to describe special and unique services covered by the state Medicaid program, but not generally covered by any other health insurers. For example, there are currently 250 Medicaid home and community-based waiver programs operating in every state but one at a cost of about $10 billion annually.
These programs provide coverage for an extensive array of non-medical type services such as air conditioners, home and vehicle modifications, companion and attendant care for the elderly, disabled, mentally retarded and developmentally disabled individuals included in these programs.
Such services are not generally covered by other public or private health insurers. I should add that Medicaid home and community-based programs are expected to increase dramatically following the recent Supreme Court decision in Olmstead.
Another example of services covered by Medicaid but not other insurers is that of school-based health services. These are provided to disabled children under the Individuals with Disabilities Education Act, to enable these children to receive a free, appropriate public education.
Almost all state Medicaid programs currently cover these services for Medicaid children at a cost of over $2 billion annually while the local, state and federal education agencies pick up the rest of the cost for these services when provided to non-Medicaid children.
Other services commonly covered by state Medicaid programs but not other health insurers include transportation to and from health care providers, case management services and services that are part of Medicaid enhanced pregnancy-related services such as health education and counseling. Procedure codes to describe these special and unique services not generally covered by other health insurers are needed to enable state Medicaid agencies to run their programs.
I might just add that anecdotally, several years ago, we began a study to look at prenatal care provided to Medicaid patients. We selected several states that had predominant fee-for-service programs. Our intent was to identify, through claims encounter data, the number of prenatal visits that Medicaid patients had.
We thought this would be relatively easy. There are established national codes for prenatal care. Some of them are bundled service codes which consist of the entire prenatal care package, labor and delivery, and then there are some CPT codes to identify individual prenatal care visits.
When we went down to the state level to identify this information, we found generally that the states had many, many codes for prenatal care. They tended to have separate codes for the providers of prenatal care, whether it was a certified nurse midwife or a physician.
They also had separate codes depending on where the prenatal care was delivered. A rural health clinic had a separate code, then a federally qualified health center had a separate code from an outpatient hospital clinic and so on and so forth. It became quite an exercise just to try to figure out how many prenatal care visits were had by Medicaid patients.
DR. COHN: Thank you very much for a very interesting presentation. Stan Rosenstein?
MR. ROSENSTEIN: Good morning. My name is Stan Rosenstein. I am the assistant deputy director of medical care services for the California Department of Health Services. I appreciate being here today. It is nice to see a fellow Californian. I have been asked by the National Association of State Medicaid Directors to provide the subcommittee with information on local codes and the issue from the state Medicaid agency perspective.
As you are aware, the proposed elimination of local codes under HIPAA will have a tremendous impact on Medicaid's ability to perform our business function, to provide care to our beneficiaries and to reimburse providers. I appreciate the opportunity to share this information with you.
Over the last 20-plus years that I have been involved in this, I have been involved in conversions to various universal claim forms, ANSI standards and coding structures. I have a lot of personal experience in these areas. I would like to provide you with an overview of the use of the level three codes in the Medicaid program, and I would like to discuss how it is used in California and how we got to where we are on local codes. Finally, I would like to offer some global comments on the problems associated with forcing the use of standard coding for all instances.
Medicaid is the predominant payer of health care services for the country's most vulnerable populations. In order to meet the needs of some of those individuals who experience some of the most persistent and debilitating conditions, Medicaid provides services generally not recognized by other payers, whether they are commercial insurance or other public-supported programs.
As the Medicaid program has matured, the scope of services and products covered has expanded greatly. As a result, our coding needs have become even more of a mismatch to those of the commercial insurance world of CPT and Level II HCPCS.
Perhaps the most obvious example is in the case of home and community-based waiver services, that were created under federal law to enable persons who would otherwise be in a medical institution to remain in their home or community, and often where there is no family to support them.
This requires services and supports that are not currently identified in Level I or Level II of HCPCS because they are not customarily provided by payers other than Medicaid. They are non-traditional services provided to avoid more costly and less desirable traditional services and allow for payment of services that might otherwise be provided by family members in a non-Medicaid population.
As HCFA has mentioned, this is a growing issue with the Olmsted decision and becomes even more critically important. In addition to creating codes for non-traditional services, state Medicaid agencies rely on local codes to support our unique business needs.
Such codes assist in our ability to manage the care provided to patients by including numerous types of case management and care coordination fees. They also provide the ability to bundle together services that are appropriate for an entity to provide in a single visit such as a well child exam. Local codes provide very specific information about the items requested, such as individual parts for durable medical equipment, thus enabling fast replacement, processing and automation.
Detailed information is necessary to implement the appropriate anti-fraud and abuse edits and audits in the system. The level of detail afforded by local codes simplifies the fee for calculation by eliminating the need manually price claims and allow us to pay our services faster.
As a joint federal-state program, Medicaid has specific responsibilities and business needs that are greatly facilitated by the use of local codes. Services provided under Medicaid have multiple funding sources and varying levels of federal reimbursement. Local codes allow states to easily link payments to funding sources and determine the percentage of federal reimbursement for individual services.
States must also be able to meet requirements imposed on them by both the Federal Government and state legislatures. HCFA requires states to submit numerous federal reports that can be easily generated only if specific levels of detail are available in our computer systems. State legislatures commonly mandate coverage of specific services, which often have no corollary in the commercial market.
A good example is telemedicine. We are one of the 17 states and we need to respond to our state legislature. When state laws are passed, there needs to be a responsive mechanism to provide a coding structure for these services. Often we have very tight deadlines for implementation of various legislation. Quite honestly, our legislators are not very sympathetic for any delays.
Absent a comprehensive and timely national solution, state Medicaid agencies have had to rely on local codes to perform their business. We have provided an attachment that contains a complete listing of the categories of local codes utilized by state Medicaid programs.
Let me talk about the California experience. We are a heavy user of local codes. For us, local codes provide better patient access to providers of care, which is what we are here for. Local codes allow providers quicker and more consistent pricing and payment for services.
In addition, they have the ability to pay some providers a different and often higher reimbursement rate than the generic CPT 4 HCPCS codes. Local codes provide encouragement to providers to provide care for MediCal beneficiaries. We have significant access problems in California and we use our codes as a way to get providers paid quickly to keep that access.
Anything a state can do to counter-balance the inherent problems of our reimbursement structure is something that we must do for both the MediCal and public health programs that we work with, to be truly viable and effective in reaching our needy population.
How do we get to having local codes? Often, our local codes come from our provider community. I am going to give you two examples that very recently have come to us. We were asked to provide increased reimbursement rates to address a problem in our hospitals of their inability to get on-call physicians to come into the hospital.
That is a major crisis in California right now. An emergency room doctor will treat a patient and can't get a specialist to come in. The emergency room doctors asked us to provide a specific enhanced payment for on-call physicians. There are no current coding structures that allow us to do that. We worked with the emergency room doctors in our medical association and came up with the unique modifier to do that.
Without the ability to have local codes, California could not reimburse our on-call physicians more to meet our specific needs. As recently as yesterday, I got a call from our pediatricians, regarding a concern that they had about the elimination of California's current local codes for critical care. We have a set of local codes for pediatricians to use for critical care services.
The pediatricians believe that the coding structure that is currently in HCPCS is an adult-oriented system that does not recognize the critical care needs of children. They have asked us to stay with our coding structures. They believe it provides a more definitive nature so that it makes them less suspect of fraud and accusations that they out-coded, in a world now that is very anti-fraud oriented. It actually ends up providing them with a higher reimbursement rate.
We have local codes, in large part, because or providers want local codes. The same thing applies for coding for durable medical equipment. We have worked very closely with our providers of durable medical equipment to get unique coding to allow them to be paid faster and better.
Recently, about a year ago, we moved to adopt the uniform coding system for wheelchairs. We were forced to retract that by the consumers, who were concerned that the uniform coding structure would affect their access to services. Just so you understand this, this is not Medicaid using local codes for our own personal needs. Our providers and our consumers also want us to be using it.
I also would point out that most of our providers' current management systems of software are already programmed for current coding and any changes that we will make will be pretty dramatic changes to our providers, as well as to our computer systems.
Just to reiterate, the local codes, for us, allow us to react faster in providing new treatments for our patients. An example is the recent changes in cancer treatment that are hitting the market. We are able to establish local codes and pay for them as soon as they hit the market. It would be a shame to have to wait until we get federal approval before we could offer those services to our beneficiaries.
Local coding does provide us with a better way to price our claims. We can price them automatically and avoid the time frames it takes for providers to get paid through manual review. It does allow for us to better know what is going on with our service utilization. Fraud is a major issue in California. This gives us greater control on fraud and abuse in the program. Our waiver programs, again, have a wide variety of requirements that are mandated by state legislation. Local codes that are unique to these waiver programs are critical for effective use of those programs.
The proposed code set does not adequately support the current business needs of the Medicaid program. Prohibiting Medicaid agencies from using local codes will preclude our ability to respond to providers and consumers, as well as hamper our ability to process claims and data effectively.
Existing services, again, provider reimbursement would cease to be available in the absence of appropriate local codes. States would not be able to adopt new services or program developments if there is no way to acknowledge that program or service in the EDI world.
Finally, major changes in the claims processing system would be needed by the states and by the providers. To implement many of the codes, additional processing steps must be added to accomplish what the local code accomplished in one step, and would be costly in terms of both implementation and operation. These changes will affect the performance of both claims processing and cause delays in our payment to providers.
Of particular concern to the states is the impact that the elimination of local codes will have on what we call our closed loop transactions. Closed loop transactions are business arrangements created and operated by state Medicaid agencies that are specifically designed to pay for the provision of services to certain limited populations by certain limited providers, the unique Medicaid-only codes.
The Medicaid program is the only source of payment for these specialized services. We see little value in operating these closed loop businesses under a national standard format. Standardization may create barriers to designing systems best suited for the state, and undermining the state's ability to administer the Medicaid program.
When HCPCS was created, states were given broad authority to develop local codes. They have proceeded to do that, and to meet the needs of the 50-plus state Medicaid programs. There has been no need to use a lengthy and cumbersome process, which is what has been proposed for the local codes.
Prior speakers have talked about the process now in place for implementing the local codes, which appears to be a loose structure. With Medicaid, that structure will be inundated in the next two years with thousands and thousands of requests for local codes. I want to call this to your attention as a critical issue for state Medicaid programs, and our ability to provide care for our population.
Thank you again for the opportunity to testify on this very important issue.
DR. COHN: Thank you very much. Rich Landen?
MR. LANDEN: Good morning. I am Rich Landen. I am with the Blue Cross Blue Shield Association, the inter- plans programs division, electronic commerce and national standards unit. I mention that because there will be several other presenters from Blue Cross Blue Shield Association today and tomorrow.
Blue Cross and Blue Shield plans use local codes for five major reasons. The first is for services not otherwise classified, second, for new technology, third for new drugs, fourth for reporting compliance with private contractual arrangements and, fifth, for fraud and abuse protection and detection.
For services not otherwise classified, Blue Cross and Blue Shield plans, like many other payers, negotiate or require use of what I will call proprietary codes, either trading partners, where there are no what we will call standard codes available to report the necessary information.
If the various national coding systems -- for instance, CPT, ICD, HCPCS, NDC and the new LOINK codes that are going to be associated with claim attachment standards, if those systems create codes for the services not currently classified in the system -- for instance, infusion services -- those local codes for Blue Cross Blue Shield plan purposes could be migrated and deleted.
The point here is that the converse is also true. If those codes don't get incorporated into national systems, we will still need those codes to achieve our business purposes and requirements. For new technology, if the CPT tracking codes are successful, they can be used for the new procedures and quality measures, although it remains to be seen if the timing of the tracking codes will be quick enough for the Blue plans. For new drugs, if national drug codes are used, they will be available when the drugs are available, so that the NDC codes, at least in theory, can replace the local drug code needs.
However, the volatility of the NDC codes will be a challenge for health plans. New drugs and packagings are added continuously. This is the same issue that will impact the volatility and frequency of update issues affecting all code lists under the HIPAA administrative simplification. The question is how can an automated adjudication system keep current with all the updates to the hundreds of code lists that are out there.
Reporting compliance with private contractual arrangements, the Blue Cross and Blue Shield plans negotiate services and supplies as part of specific contracts. There are negotiated situations or conditions in those contracts that may affect or alter payment rates. The coding for plan-specific contractual arrangements does not necessarily lend itself to national coding. In the fraud and abuse protection and detection, we are concerned that codes that are too generic may present loopholes for fraudulent or abusing billing practices.
I would also point out that the HIPAA legislation does not outlaw contractual relationships. Therefore, the HIPAA transactions must be capable of transporting the information required to properly administer those contracts. Non-national coding is part of proper contract administration. What that boils down to, local, regional and proprietary codes -- call them what you will -- are a de facto part of health care administration.
Blue Cross Blue Shield Association is a participant in most of the major efforts going on with industry standardization in health care administration, both inside HIPAA and outside of HIPAA. We are a member of the NUCC, and we agree with the issues identified by Jean Narcisi and her NUCC comments earlier.
However, as is so common on voluntary committees and such, the opinions of the membership of the committees is not necessarily unanimous. BCBSA agrees with the problems as defined by NUCC. We do not necessarily say that the NUCC code solution is the only viable solution. We are certainly committed to working with all the organizations, including NUCC and NUBC, so that there is a solution to the problem.
Standardization under HIPAA is a desirable goal, but movement from the current uncoordinated environment to a coordinated or a standardized environment will require thought, planning, education and, above all, a coordination infrastructure.
The HIPAA and non-HIPAA electronic transactions utilize codes from hundreds of independent sources. Those hundreds of sources are not collectively exhaustive, meaning that there are needs for new codes that are not found on any current code list. The industry is dynamic. There will be legitimate business purposes requiring the creation of new codes for many reasons and for many uses.
One user friendly way to create unduplicated national codes must be established. Creation of codes must serve two purposes. First, it must meet state, local, regional and private business contracts and other non-national business purposes. Second, to move the new codes into the HIPAA- approved code list and transactions for national use. We would offer the single web site model of the HIPAA change request memorandum of understanding organizations as an appropriate model for code requests.
This committee is familiar with that, I believe, because we signed the documents here officially at the end of March. The new infrastructure would most likely involve a consortium of the coding bodies, and that would expand on the list that Jean Narcisi gave with the five specific code lists that the NUCC cited.
It would include a centralized library that would be virtual. A verification of the unique business purpose before any new code is issued, that would prevent duplicate or multiple code assignments, and it would essentially include rapid responsiveness of the health plan.
If a provider network negotiates a new contractual relationship, any new codes necessary for that relationship must be established in a matter of weeks, not years, as we heard a couple of examples earlier, so that the codes can be used immediately in the non-HIPAA transactions and can be proposed immediately for inclusion in the next round of HIPAA transactions or HIPAA code lists. Thank you very much.
DR. COHN: Thank you very much, Richard. Tom Musco?
MR. MUSCO: I am Tom Musco, the director of research and statistics at the Health Insurance Association of America. I want to thank the group today for the opportunity to discuss the ways in which private insurers and health plans use and are affected by local codes.
While HIAA represents private plans, the issue of local codes is not unique to these entities, but spans a range of public and private organizations, local and national plans, small and large organizations. HIAA represents a diverse group of insurers and health plans. Just as local codes affect a wide range of health plans, HIAA members are of all sizes, local and national in scope, and comprise a mix of programs, with some companies specializing in specific products and markets, while others have a diverse mix of products and client organizations.
When the request to present information before this panel came to HIAA, we contacted representative member companies to gather information about their current use of local codes, and the problems they were encountering currently, and then what effect of the proposed elimination of the codes would have on them. As expected, because of our diverse membership, the response was as diverse, in terms of both the use and potential effect.
There was, however consistent comment, in that there exists a clear need for private health plans to accurately identify the nature and timing of different services, and who renders those services, even if there are not now codes to express those services. Current code sets do not completely meet the needs of all health programs. Until there is a national standard that more broadly encompasses the full range of services covered by private insurers and other health programs, there will continue to be a need for local codes.
The current use of local codes meets many needs, most often to describe the non-physician services, supplies, equipment and drugs not now accurately described through some other system. The development of local codes is not only driven by private insurers and health plans, as you have heard previously.
Many companies serve as administrators for state Medicaid agencies. They have arrangements with groups of providers that offer unique services that must be coded. Private insurers have to comply with state- mandated benefit laws that are developed and require their own codes, and these state laws with vary from state to state.
In addition, private plans administer programs or very large plans for large employer groups that have specific needs or specific demands in the types of services they want provided to their employees. So, some specific codes may have to be developed to accommodate the needs of special clients. There are many instances where health plans will cover variations of a service at different levels of reimbursement, and thus, must track these variations separately.
One example used by one of our plans was that of air ambulance service. A code exists to describe that service, but this particular company does make a distinction in the type of vehicle used, because there is a very large difference in the cost involved. So, they have developed codes that differentiate between a propeller-driven and a jet-driven aircraft.
Often the state Medicaid agency or the plan administering the program wants to know detailed information about the services provided to their member. As you have heard earlier, many of the state agencies have developed many codes to describe the kinds of services that they need to collect for their enrollees.
I won't amplify the problem for the agencies with the examples that I have. Suffice it to say that you have heard some instances where there is a great need for local codes with those agencies. In developing local codes, as you have heard, the Blue Cross and Blue Shield Association has developed a detailed list of codes utilized by its member plans in the instances where it needs to describe services that are not now currently coded.
These codes are a form of local code. As you are aware, a subset of these codes was published in the HCPCS 2000 book under a section of temporary national non-Medicare codes. Until this year, the use of the S codes was limited to Blue Cross and Blue Shield plans. With the publication of these codes in the HCPCS code set, I believe we are seeing more private insurers making use of them.
One particular example and I am sure private insurers will make use of, as do many of the plans, is the use of infused or injectable drugs in the home setting. Suffice it to say the S codes are used to provide a means for billing and paying for some of these services.
One other development or recommendation that has been made, as you know, the NDC codes will probably replace the J codes in the HCPCS system. That probably will also expand the ability of private insurers to code for services that they do not now have.
Where there are neither applicable to level 1 or level 2 code or to a published S code, private plans may create a code or unique modifier to describe a service, supply or specific type of equipment.
They will do this when there is a high volume of claims for a particular service that is not now routinely described in one of the other existing code levels.
This happens often with durable medical equipment, when private insurers may want to pay for the equipment at a negotiated price, avoid a manual review of claims and be able to identify the frequency and volume of billings for that particular piece of equipment.
To accomplish that, the payers often request that vendors use a unique code to describe that piece of equipment.
State mandated benefits for privately insured populations can also create a need for coding that cannot be met with the existing levels of code sets, prompting private insurers to develop local codes.
Just a few brief examples of the types of mandates that private insurers are faced with, for example, in Georgia the state has mandated coverage of fitness trainers.
A health plan wants to track the charges and payment for these services distinctly from those of other professional services.
Indiana requires coverage for surgical procedures related to morbid obesity. While there may be codes to describe some general services in this area, insurers and private plans may want to describe a broader range of surgical procedures commonly used for the morbidly obese.
California has mandates for the coverage of PKU formula and food. There are no current level I or II codes for providers to bill the food components separately, and they may not be adequately described in coding systems. Many states have also implemented mental health parity laws that require coverage of a range of non- physician providers, including social workers, marriage and family counselors and like providers.
A health plan may want to track charges and payments for these services separately from those of physicians, or there may be a need to pay for similar services done by different types of providers at different rates; for example, an hourly rate for a physiatrist versus a person with a master's in social work.
As a final example, several states have enacted requirements for coverage of diabetic supplies and education, where specific professionals have been mandated for coverage.
Again, private insurers may want to track payment to different types of professionals providing these services. The codes may come about for different reasons to meet the diverse needs. Similarly, the use of the codes can affect the parties involved separately.
Because of the diversity of insurers in health plans, the information and claims processing systems they employ, different plans and the providers they deal with will be affected differently and more or less severely by the elimination of local codes. Some systems will need coordination across payer/provider partnerships, other systems must be coordinated internally, where a particular payer has multiple systems to be integrated.
On the other hand, to the extent that some plans make little use of local codes, but have to deal with provider-developed local codes, their elimination may be beneficial to the payer in that instance, but that may adversely affect the provider, in that there is no replacement mechanism to describe the kinds of services for which the provider has incurred an expense. Because the development of local codes is based on the need of providers and payers to communicate more efficiently, the elimination of the codes will affect both parties.
Health plans that are national in scope try to establish local codes on a consistent basis from area to area. While this simplifies claims processing, it may also affect the administrative practices of the local providers.
If local codes are eliminated, the health plan loses its ability to efficiently process claims. Inversely, companies that have not developed their own relationships with local providers, that rent provider networks, have consolidated processing systems and must accept claims from various geographic areas.
They must deal with the problem of provider- developed codes that may often be inconsistent from provider to provider. One provider group may have developed a local code to describe one of its services, while another group will use the same code to describe a different service, or a variation of the same service.
This creates conflicts in terminology and confusion in processing claims. It also means that claims must be reviewed manually, increasing expenses and causing undue delays in processing. In this case, the elimination of local codes benefits the insurer or health plans and providers in their ability to communicate efficiently about their unique services.
The Level I and Level II concepts were developed to describe a particular scope of services. By design, neither of the two concepts completely encompasses the full range of services, supplies, equipment and drugs that are included in the benefit plan arrangements of commercials and other programs. There is a clear need for both public and private health plans to be able to accurately identify the nature of the different services, timing of the services and who renders the services.
Until there is a national standard that more broadly encompasses the full range of services of private insurers and other health plans, there will continue to be a need for local codes. The elimination of local codes would leave providers without a means for billing certain services that most private insurers are willing to pay.
While discussions have been taking place on ways to track and implement new services and technologies more quickly into standardized code systems, either through more frequent updates or assigning temporary or tracking codes, it can take years for a code for a particular service to enter the current system. By contrast, local codes provide a more immediate mechanism to bill for services that are not otherwise billable and distinguishable.
Without some alternative mechanisms, claims for hundreds of types of drugs, services, equipment and supplies have to be processed under a miscellaneous code, clearly an effective and inefficient means of billing and payment.
As with private programs, other programs like Medicaid would be similarly affected. It would be difficult to process claims and track services provided to enrollees. If local codes could not be used, in many cases program administrators' systems would be unable to recognize a program benefit, pay for it and track it for reporting purposes.
Having said all that and having described the uses that companies make of local codes and the problems encountered, I do believe, however, that private insurers and other programs would benefit from, and welcome the consistency that a uniform national level of codes would bring. With certain aspects of that, like the NDC codes, which bring with it a certain format, it certainly would necessitate changes and cost to implement those systems. So, a proper time frame for implementation would be appropriate.
Along with the uniformity, there must also be the availability of some mechanism to meet the needs to efficiently communicate and process claims of provider services, equipment and supplies that health plans cover but which are not now described in the current code system. The inclusion of the S codes, the NDC codes, the temporary codes for new technology, and so forth, into current national systems will go a long way to providing mechanisms to satisfy the needs of local systems.
DR. COHN: Tom, thank you very much. I think we will have questions and discussion from the subcommittee. Kathleen Fyffe, you asked to be on first.
MS. FYFFE: Thank you very much. Thee were all very good presentations, very informative. Before we get down into the details of local codes, because we are all friends in this room and we are all interested in health care, I have a question for Dr. Zelinger about a particular sentence in your testimony that I am stunned about.
It says here that there are approximately 41 million beneficiaries in the program, including 41 percent of all children now born in this country. Is that statistic correct, or could it be a typo, because you have got 41 printed twice in the same sentence.
DR. ZELINGER: It is correct, and that percentage reflects how many children are on Medicaid. I haven't looked too high behind that figure. It varies from 39 to 41 percent. I am not sure if it reflects the number of children who come onto Medicaid at some time during the first year, or who are actually delivered and, at the time of delivery, are on Medicaid. It is roughly correct, yes.
When we state that there are 41 million Medicaid beneficiaries, that number also varies according to whether you calculate it in terms of person years. On average, Medicaid enrollees are in the program for only nine months a year. There is a lot of on and off roles. That is why those figures change a bit.
Forty-one percent is basically what we use now and it has grown. Four or five years go, it would have been 35 percent, 33 percent. Again, the reason for that is that, even with welfare reforms, state Medicaid programs have expanded eligibility up 200 and 300 percent of federal poverty level, to enable pregnant women to receive the care they need for prenatal care and delivery. So, it does make sense.
MS. FYFFE: Thank you very much.
DR. COHN: Other questions? Kepa?
DR. ZUBELDIA: Before I ask the question, thank you everybody for the testimony. I think it has been excellent.
I am a little confused as to what the real problem is. I will give you a little background. About nine years ago, I was part of a committee that put together the claim adjustment reason codes initially for Medicare use on the A-35.
We started by doing a survey of the Medicare carriers and intermediaries in the country and getting their claim adjustment reason code, because each one of them had a different list. We came up, in the first round, taking out the ones that were obviously the same, like deductible and co- insurance and things like that, with a list of over 5,000 codes.
We went back to them and said, now your carriers and intermediaries, could you go through this list and see which ones you don't need. Within 50 milliseconds they came back and said, we need all of them. That wasn't going to work.
So, our committee went through the list and came back with about 103 codes that were unique. Everything else was duplicate, different versions of the same thing with different wording that meant exactly the same, or different codes used by different carriers but with the same wording.
We also separated the list into two things, the judgement reason codes and the remarks codes. We saw a little more variety in the remarks code, but that did not affect the reimbursement. It was a remark. It didn't have anything to do with reimbursement.
Since then, the list has grown to maybe 200, which is way short of 5,000. I am wondering if the same thing is happening here with the local codes. I hear that there are things like telemedicine that is used in 17 states. Are those 17 states using the same code for the same services, or each state uses their own code.
I think that expediency has taken over. I have heard the comment -- it was kind of interesting. Stan Rosenstein stated that Medicaid didn't want to wait for federal approval of a code. You said it would be a shame to wait. I think expediency is taking over.
I am wondering if somebody wants to look at those local codes and try to combine them, how many local codes there would be and whether those would fit on the range that we have today of temporary codes that we have at the national level and see if that would be a temporary measure, to maybe promote them to a national permanent code, rather than have this multitude.
Now, the question -- I have two questions -- is whether you think this approach of consolidating the codes would work, and maybe for Jean Narcisi, how long would it take for somebody like the NUCC to put a code in place through some expedited mechanism for codes?
MS. NARCISI: Thanks, Kepa. The problem that the NUCC has looked at is that, for instance, the code sets that are external to the transaction such as the claims adjustment reason codes and the provider taxonomy codes, will not filter through the coordinated process that we are putting together through the memorandum of understanding.
Although they are considered data content, they won't go through that process. So, what we are saying is, it wouldn't be just the NUCC that would propose to get these codes kind of maintained, it would be through the whole entire MOU process.
DR. ZUBELDIA: Let me clarify the question. How long is that process or specifically local HCPC codes? How long would it take through that process for Medicaid or a private plan to request the assignment of a HCPCS code at the national level.
MS. NARCISI: The MOU process, we have outlined a time schedule for submitting requests. If there are appeals to any of the requests, then that could take up to a year. If there would not be an appeal to a submitted request for a data element or code, it could take a matter of a few months.
It has to go through the review process of the individual committee that would be responsible for that data content, and then it must be shared with the other committees. It depends on the meeting schedules. Until we actually have a trial run of it, I can't answer exactly the number of days or weeks or months that it would take. It would definitely be within a year's time frame to update the transactions.
MR. ROSENSTEIN: To comment on, is there consolidation that could be done, absolutely. I think your example of telemedicine, I am sure there are probably 17 ways that we code telemedicine. Certainly, there is a lot of work that could be done to bring common coding to those types of situations.
With procedure codes, I think we are looking at a much bigger range of differences than the example you gave. I think the effort should be made to consolidate, but we are still going to be left with some uniqueness among states, even when we are done with that. In terms of the expediency, that is just something we live with. The process does need to, and can work more expediently.
We have a lot of experience with the NCPDP standards and process for pharmacy. We had a new pharmaceutical program we brought up last February and we were actually able to get through that committee in a matter of weeks to get a new transaction set approved so that they can be.
For our state, neither our legislators nor our governor had a lot of patience for not providing this program for seniors. So, it was an instant demand for us. So, we do have a lot of expediency pressure. I think there can be a lot of consolidation. It will still come down to the issue that we are going to need local codes. There are a lot of codes that are not in any of the code sets now that Medicaid needs.
DR. COHN: Any other comments on this one?
MR. LANDEN: I would just like to add a couple more comments or observations. I think you have heard from all of us on the panel that there are diverse coding needs that are not yet met on a coordinated national basis. There has got to be a coordinated system to avoid the duplication that you are alluding to, where we have got two different regions setting two different codes for the same thing.
There has also got to be a body that can decide whether that thing really is the same in Alabama as it is in Oregon or not. The other thing that hasn't been mentioned yet is HIPAA creates a distinction between code sets that are internal to the transaction set and that are external.
The codes that are internal need a very different implementation and approval process than the external codes do. It is the same lead time to change the code, but the internal HIPAA code sets have, on top of that, the NPRM process or whatever it is going to be for the Secretary to promulgate the net HIPAA rules, which is minimum 12 months.
DR. COHN: Can I follow up with some questions here? First of all, I want to thank you for some very good questions. I want to thank, obviously, the panel also. Dr. Zubeldia, I am sure, has more questions. I am actually reminded, he is actually a physician. I don't know if many of you realize that because it has been a number of years since he practiced.
I recognize some physician behavior in trying to solve the problem immediately, which is all of our tendency here. I hadn't seen that in you before. [Laughter.] I am hearing sort of basically three issues, when I am sort of listening to everyone. I may be being too global, but just to try to put together a lot of various issues. I have heard from Jean very clearly that there is the issue of sort of looking at other code sets, provider taxonomy and all of this, and how do we best handle this.
I was actually pulling out my copy of the legislation, which is actually in my computer, to see exactly how code sets are defined in HIPAA. Really, the issues that you are describing are probably a little bit gray, but most of us tend to think of it as actually part of the standards. I will ask you a question about that in just a second. That is issue number one.
Then there is the issue of timely process for getting codes for all of the uses that you are describing. I mean, everyone here on the panel is talking about the need for timely responses to codes. Then there is the final issue that has to do with things that are not part of agreed-to code sets, and where some of the boundaries are.
Are air conditioners procedures? I don't think so, at least not the way I have ever thought about them previously. The question is, how does that all get handled. Now, having said those three problems, I am only going to ask a question on this first issue, which has to do with this other code set, provider taxonomy and all of this.
This is really sort of a question for Jean. When I heard you bring up this issue, it occurred to me, having been here at the last meeting of the subcommittee, where we actually had the opportunity to see all of you sign a memorandum of understanding that had to do with the maintenance and upkeep of the financial and administrative transactions, that at least as all of us had been considering this, that these code sets were actually intended to be internal to those transactions. I am actually wondering if this isn't sort of a first issue for the signatories of the memorandum of understanding. If not, why not?
MS. NARCISI: A code set such as the provider taxonomy code set is an external code set from the claims transaction, for instance. The transaction would identify a code source to use for a specific element and the provider taxonomy would provide a code to be used in that. So, it is external, just like there are several other external code sets. So, it will not be maintained, as I understand it, through our coordination process with the MOU, that is outlined in the MOU.
DR. COHN: I think it is a gray area, personally.
DR. BRAITHWAITE: I think when you look at the implementation guide, there are internal code sets which are specified in the implementation guide itself, and there are others, as Jean mentioned, not just the code set for diagnoses and procedures, but there are other code sets. Race and ethnicity is another one which is an external code set. IT is not the big sort of thing like diagnosis and procedure that we think of as the medical external code sets.
They are, in fact, technically, from the implementation guide perspective, external code sets, currently maintained by some other organization and coordinated, of course, through the external legal process. So, technically, they are external, but the question is how do we deal with them and maintain them and keep this process running smoothly.
Rich has mentioned sort of applying the MOU process to them as one solution to that, building a central registry of them. Whoever actually supports them could be, as he said, a virtual mechanism, but use the MOU web site, single point of contact feedback process to simplify and accelerate the process.
MS. TRUDEL: I think one thing to keep in mind is that the term externally-maintained code sets is extremely broad. I believe if you looked in the implementation guide, you would also find that zip code is an externally maintained code set.
I am not exactly sure that a solution that lends itself to reason and remark code is going to work with zip codes and race/ethnicity. It is obviously something that requires a lot of additional analysis.
DR. COHN: Other questions from the subcommittee or staff?
DR. BRAITHWAITE: I have one question. When Kepa talking about the 5,000 codes turning into 103 or something, I think that part of the local code process, at least the way I understand what you all said, is a combinatorial explosion problem. That is, when you go to an adjudicated claim, there are only so many orthoganol parameters that need to be specified. We need to know who the service was given to and who provided the service and where the service was provided and a few other things like that. We could make a list of what those orthoganol parameters are.
What I see happening, or it is implied in the testimony, particularly Stan's, that in order to be expedient, rather than building software which appropriately interprets those orthoganol parameters to come up with an appropriate amount of reimbursement, you build the reimbursement thinking and processing and adjudication into the code, and then make the provider process it for you. Instead of adding a couple of days of programming and computer time to the process so that everybody could use it, you make every provider in the country spend hours and hours doing the processing for you. I would like to hear your reaction to that interpretation.
DR. ROSENSTEIN: I don't think it is correct. When we do these things, we work closely with our providers. It is a level of detail. We try to avoid manual pricing. So, we get more detail on the precision of what is the service provided. Critical care is a good example.
We have, working with our pediatricians, a more defined definition of critical care than the common coding structures. We have our unique codes. We worked it out with them because they were afraid that there would be a lot of investigators coming in alleging improper coding, improper billing, up-coding.
DR. BRAITHWAITE: So, you need more detail on where and how and who.
DR. ROSENSTEIN: Yes, on the nature. Maybe an easier example is the products. The wheelchair codes, for example, are very generic. Because we serve a different population than anyone else, we get much more definitive on wheelchairs, because we have got various varieties of custom wheelchairs.
I think HCPCS code and Medicare has a generic code and they pay $6,000 for a chair, no matter what it is. We pay chairs that cost up to $27,000 each. We have got a couple choices. We can either come up with unique codes that allows the provider to tell us the nature of the chair they provided, or we can use a generic report or unlisted code and manually price it.
The providers prefer to use a more detailed code to tell us what they did so that it goes through our system through computer pricing. They say, I did X,Y,Z machine. We say X,Y,Z machine pays this amount and it zips through the computer.
DR. BRAITHWAITE: Excuse me, Stan. Do wheelchairs have UPC codes?
DR. ROSENSTEIN: No, they do not.
DR. BRAITHWAITE: Could they?
DR. ROSENSTEIN: That is a good question. They could. We have been working for a long time on wheelchairs. Right now, they are HCPCS codes, and there are very few wheelchair codes at all.
DR. BRAITHWAITE: I know that certain organizations in California and certainly the DOD has been moving to the level of detail you are talking about, to get a specific product of a specific manufacturer by using the universal product code as the billing mechanism, rather than again having the provider translate that into some grouped HCPCS code.
DR. ROSENSTEIN: That is actually where we would like to head, too. The problem with that is that it is a longer code that -- we would actually have to convert it into our pharmacy system, oddly enough, because of the length of the UPC code. That is where we want to head, too, and our industry wants to. That wouldn't be a problem.
MR. BLAIR: Just along the same lines, I thought there was an organization that testified to us -- I don't remember the acronym, but a developer of medical suppliers and durable equipment that had a code set that was national. Does anybody recall the -- EM something -- okay.
DR. ROSENSTEIN: For us, the Department of Defense codes are the best, as we understand also.
DR. ZUBELDIA: Following up on Bill's and your wheelchair example, I am really concerned about this orthoganol explosion of codes. Now, with the elimination of the type of service codes, we are going to see the local codes multiply times two or three. Now you need to combine different types of service with the same local code. So, it is a concern.
For instance, let me give you an example. On the wheelchairs, if California pays for a $27,000 wheelchair, there is nothing that precludes that code to be a national code, and other states don't have to pay for it. Other states, when they see that code, can deny it or pay it at a lower level. I don't see why these local codes cannot be national. It does not mandate that the Medicaid program or the private plan pays for it. The fact that the code is there is benign.
One thing I do see a need for local codes is in I think both California and the Blue Cross Blue Shield Association testified about the use of codes to express private contractual relationships. Sometimes you have a contractual relationship that is of such a nature that you want to keep it confidential, maybe. You don't want your competitors to know what your health plan covers.
You don't want to promote that code to a national level code that would let your competitors see at a glance the special things that you are paying for. I can see a need for that, and those codes would probably have to be private codes of some sort.
Everything else that can be promoted to a national code should be promoted to a national code. We probably would end up with 99.9 percent of the local codes removed.
Now, there are needs for specific states to have specific codes because there is some legislation that has been passed that requires the payment of that service. I think the MOU provides for a process, and maybe we can get clarification here, for a process of expedited approval, in case of legislative requirements.
If there is such a process -- and I see Jean saying yes there is such a process -- what are the time frames in that process. How quickly would that process permit a code to go as a temporary national code, in case a state needs it.
MS. NARCISI: Kepa, I will attempt to address that one. There is some type of emergency type relief, you might want to call it, through the MOU process, if there is some kind of a legislative need for something to be added to a transaction set. That should also include a code to report something.
We have set up a time frame process within the MOU that should be able to take any elements or any changes that have been suggested through the entire process in less than a year, so that the transactions, if need be, can be updated within that year's time. Like I say, we have not tested it out. There should be the same solution for the codes that would not be included as part of the transaction. Those are external.
MR. LANDEN: I would like to respond to Kepa and also tie in something from Dr. Braithwaite's earlier comment. In my testimony where I talked about the requirements for business confidentiality, I did not mean to imply, and I think you interpreted it that the codes themselves needed to be confidential. I think what I mentioned is that there may be arrangements where certain practices get reimbursed differently or services are covered or not.
The privacy or secrecy, call it what you will, of those contracts I see as separate and apart from the existence of codes to report compliance with those terms between providers and payers.
So, I would not say that the Blue Cross Blue Shield Association sees a need for continued private codes, that we could go with a public system, as long as that public system gives us the capability of transmitting the information that we need to monitor compliance with the contracts. That gets back to Dr. Braithwaite's comment as to who establishes these codes. I think his question was right on the mark. In past history, in industry, there are different answers to that.
The federal programs, in many instances, HCFA or whatever the agency is, issues a set of regulations. Thou shalt use these codes. In private industry it worked kind of like that. It is kind of negotiated. There are kinds of things that came from both sides.
From the National Uniform Billing Committee perspective, what the NUBC has is a series of state level advisory bodies called SUBCs, state uniform billing committees. Those recommendations from the states come up to the national committee. Now, it varies tremendously across the country, whether or not a state has its own SUBC and what the representation and voting balance on those SUBCs is, whether it is payer dominated or provider dominated or state agency dominated.
The NUCC does not have those kinds of state organizations. So, in partial answer to Bill's question, practices are all over the board. I think it is a great opportunity and challenge in this HIPAA environment, how do we bring a structure, how do we bring a coordination to this process.
MS. NARCISI: I would like to make another comment to Kepa. There was an example of a legislative mandate that came down. It went through the National Uniform Billing Committee. There needed to be a way to report the patient's reason for visiting the emergency room.
There was no way to work that into the transactions. So, what happened, a code was added to one of the code sets that the NUBC manages, a value code or something. That is how that was handled, and it was handled within a couple of months. Then there was no need to really change that transaction, which was really finalized in preparation for the release of the final rule.
DR. ZUBELDIA: But the process took a couple of months.
MS. NARCISI: It probably took a couple of months before it could be reviewed by everyone. It depends on the schedule of the meeting date.
DR. ZUBELDIA: That included an initial change of gears because the initial thought was to change the transaction and then it had to be changed into a value code.
MS. NARCISI: Yes.
DR. ZUBELDIA: So, that process was longer than it could have been, than if it had just been a request for a new code to begin with.
DR. ZELINGER: I just want to make one comment. I think in discussing HIPAA and the need for codes to identify services that are covered by various plans and reimbursed by various plans, I think we need to keep in mind, whatever the method is or whatever the process is, and talking about the responsivity of this process, I don't think HIPAA should drive the coverage and payment that various plans have.
In other words, if there is a state mandate or a state Medicaid program or a private payer decides that they want to cover a product and there is not a national code, I think there has to be built in a mechanism so that they begin coverage as soon as they need to.
Then, build in a timely response on the coding side to develop a code. Whatever that mechanism is, have a temporary local code or whatever. Then have a timely response for establishing an appropriate national code. I don't think the tail should be before the cart here, so to speak.
MR. ROSENSTEIN: I would be 100 percent with you on that. Another one is AIDS resistance testing, that we added as a benefit of our program effective July 1. We need to make it available. What we ended up doing was working with consumers and providers in bringing up a code as quickly as we can. I agree with HCFA, that we cannot let the tail wag the dog here.
DR. COHN: I guess what I am hearing from all of you is the need for a timely process.
MR. ROSENSTEIN: Very timely in this case. We had a mandate, have it up in one month, have the program up in one month. That is the reality of how the Medicaid programs work.
DR. COHN: I think we have time for one more question or comment.
DR. ZUBELDIA: I have a very quick question. Would temporary local codes be a solution, where you assign your code until it gets put on a national code set?
MR. ROSENSTEIN: It could be, depending on how the process works. It would mean two sets of changes for us and our provider, but it could be workable.
DR. COHN: I think there was one question from the audience. Do you want to come to the microphone and ask the question?
MR. RAY RODDA: I had a question about the timeliness of coordination, which seemed to be one of the critical issues. I didn't know if the proposal was a case-by-case solution like the NUCC proposal that they maintain the POS codes, or whether you had suggestions about national kinds of efforts.
The National Library of Medicine had this unified medical language project. I wouldn't know if you think that anything like that could be extended to facilitate the rapid coordination of integration of local codes into national codes. What I am asking is, what do you think would be solutions that would lessen the amount of time necessary for a code to become national.
DR. COHN: I think that was Ray Rodda from the University of Maryland. Any quick responses, for a question that could take hours to try to address?
MR. LANDEN: I think there are other panels today and tomorrow that are going to be focusing on that question. What I had proposed was similar to the MOU process that has been set up among the three standards development organizations and the data content committees, as applied in the transaction NPRM under HIPAA. What we are dealing with is a current system that is uncoordinated but includes many autonomous organizations and entities.
Some of them, like the CPT and the HCPCS, are very well organized, very good protocol, very good participation. Others -- Jean mentioned a couple -- are whoever just happens to show up in the room, no real formal protocols, no balance of representation, no real good research.
How do we fit all this into some sort of national structure that comes out with a product where we have access, where we have assignment of codes, and we are insured that those codes are non-duplicated, so that what is reported from a provider in California and processed by a health plan in Connecticut is not confused with a same or similar code reported from Alabama but also processed in Connecticut.
There has to be an infrastructure set up. The way that our organization is look at that is something similar to this MOU process, where we will have autonomous organizations coming together to cooperate and coordinate.
DR. COHN: Richard, thank you for that comment. With this, I think we are at time for a break. I want to adjourn for a break in 15 minutes. We will start again at 11:00 o'clock. I want to thank the panel again for a very interesting presentation.
[Brief recess.]
DR. COHN: We are going to start the next panel. In our first panel, we heard, I think, a pretty clear delineation of the problem.
We are looking to this panel to begin to hear about some of the solution sets and approaches that you have all been taking, I think, to deal with the problem in your environments. Obviously, the problem we are talking about now is the issue of local codes and how the non-specified code sets are going to be addressed as we move forward into HIPAA administrative simplification.
With that, I think we are going to start with C. Kaye Riley, and if you would start with your testimony, please?
MS. RILEY: Thank you for allowing me to be here. I would like to take a moment to introduce myself again and provide an overview of the alphanumeric HCPCS process. I am Carolyn K. Riley. No one knows who Carolyn is, so that is why I include the C, because my e mail address is CRiley@HCFA.gov, should you ever have a question or need to get in touch with me.
I coordinate the alphanumeric HCPCS activities at the Health Care Financing Administration. I chair the HCFA HCPCS work group, represent HCFA on the HCPCS national panel, and serve as the chairperson if the HCPCS national panel.
HCPCS is an acronym for the Health Care Financing Administration Common Procedure Coding System. It is a national coding system used to describe physician and non- physician services, procedures, health care products and supplies. The codes are used by Medicare, Medicaid, public and private insurance programs in their claims processing systems, to screen billed services.
HCPCS includes three levels of codes, as well as modifiers. There has been some confusion that if you are talking about code sets, you are not talking about modifiers, but the code sets include the modifiers.
Level I HCPCS, or CPT, current procedural terminology codes, is owned, managed and copyrighted by the American Medical Association. They consist of five position numeric does and associated terminology that describes specific professional services and procedures.
The AMA has entered into an agreement with HCFA which permits HCFA, to use CPT codes/modifiers and terminology as part of HCPCS. Developing and maintaining the CPT codes is the responsibility of the American Medical Association, and all additions to, or modifications of the CPT codes are made by the decision of the CPT editorial panel.
Correspondence to request an application for coding change should be directed to the CPT editorial research and development, AMA, in Chicago. Level two alpha numeric HCPCS are five position codes with an alpha character as the first digit, followed by four numbers and associated with specific nomenclature.
They are used to supplement CPT codes and identify professional services and procedures, which are not included in Level I. They also contain codes for ambulance, audiology, physical therapy, speech pathology and vision care, and such products as drugs, durable medical equipment, orthotics, prosthetics and other medical and surgical supplies.
Coding decisions related to the Level II HCPCS National Codes, descriptors and modifiers, which begin with the letters, A,B,E,H,J,L,M,P,R and V are made by the HCPCS national panel. The national panel is comprised of representatives from Blue Cross Blue Shield Association of America, the Health Insurance Association of America and the Health Care Financing Administration.
Coding requests may be submitted at any time throughout the year. Information related to the process as well as a copy of the recommendation format may be downloaded from the internet at the following web site, and this is the only internet web site that I want to give you. It is www.hcfa.gov/medicare/hcpcs.htm. Others will be in the written testimony that you have.
The HCPCS data base, not including the D codes, is updated once each year and posted on the web page in October, with changes effective January 1. The D codes, copyrighted by the American Dental Association, are updated by ADA every five years, and they are not included on the internet. They do, however, appear on the computer tape available from NTIS and distributed to all the Medicaid and Medicare contractors, and through the paper copy through the Government Printing Office. The D codes have been provided under an agreement with the American Dental Association, permitting HCFA to use the code on dental procedures and nomenclature as part of HCPCS.
An amended licensing agreement is currently being developed to permit expanded electronic use of the ADA codes. Dentists wishing to submit a new code request for review may call the ADA's Council on Dental Benefits Program in Chicago at 800-621-8099, extensive 2753, or visit their web site.
The G,C,K and Q code sections of the alphanumeric HCPCS have been designated by the national panel for HCFA use, to establish codes needed to identify professional services, procedures, products or supplies to implement specific Medicare or Medicaid policies.
The C code section has been recently established to permit implementation of Section 201 of the Balanced Budget Act of 1999. The C codes will be used to identify items for the hospital outpatient prospective payment system. These codes are product specific and will only be valid for Medicare on claims submitted by the hospital outpatient departments.
Any other use on Medicare claims will be identified as not valid. These codes will be part of the national HCPCS. They will be published and come out in the update. They could potentially be used by the Medicaid state agency or any other private insurer that wished to use them while they are in place.
The K codes have been established for use by the durable medical equipment regional carriers or the DEMERCs. The G codes are assigned by HCFA to identify procedures and professional services. The Q section contains codes for drugs and biologics and other unspecified medical supplies not identified by the national permanent codes, but needed based on Medicare internal operating needs, in order to implement the Medicare program.
The HCFA coding decisions are made through the HCFA HCPCS work group coding process. The HCFA temporary codes and effective dates for use are posted on the HCFA web site.
The S and the I sections of the Level II alphanumeric HCPCS have been designated for use by the private sector by the HCPCS national panel. The S codes were first published in the 2000 HCPCS update. They have been established by the private sector based on the private sector internal operating needs, for the implementation of private sector policies, programs and/or claims processing. The S codes identify products, supplies, professional services and procedures that do not appear in the national Level I or Level II codes.
Modifiers are two position codes and descriptors used to indicate that the service or procedure which has been performed or provided was altered by some specific circumstance but did not change the original description or its five position code. The WA through ZZ range of modifiers has been reserved for Level III local codes. The G,K and Q modifiers are reserved by HCFA temporary Level II codes. The remainder of the alphanumeric and numeric series is reserved for national HCPCS modifiers, Level II, and AMA modifiers, Level I.
The level III HCPCS, these are the local codes and descriptors developed for Medicare carriers and fiscal intermediaries for use at the local level. They are five position alphanumeric codes in the W,X,Y and Z series. They represent professional services and procedures, products and supplies that are not represented in Level I or Level II codes.
Historically, when Medicare contractors identify the need for a local code, they were instructed to submit their request with supporting documentation to the HCFA regional office. The HCFA regional office would determine if other contractors in that region also had a similar need. In turn, the regional office would submit the request for a local code to HCFA central office for review and coding decision by the HCFA HCPCS work group.
Several years ago, when Medicare was planning to implement a system of national uniform claims processing software, called the Medicare Transaction System, or MTS, instructions went out to all the Medicare contractors, asking that they review their local coding practices and strive to eliminate as many local codes as possible. We were asking them to assist us in standardizing the code sets, so that all the contractor operating systems would use the same set of codes. Does that sound familiar?
We ask that they eliminate all the local codes that duplicated national codes, to eliminate all the local codes that had not been used in the last 18 months, eliminate all the local codes that represented specific brand-name products, identify and remove from the list of HCPC codes any codes that had been established strictly for internal operating needs, never published, never submitted on a claim form, and identify codes that could be coded through other fields, such as place of service, or by ICD-9 diagnosis codes, or by changes in the units columns. That effort greatly reduced the number of Medicare local codes. The printout of the local codes in 1995 filled a four-inch binder. The 2000 local code HCPC printout is less than a quarter-inch thick.
MTS was never implemented, but we certainly did a good job on reducing the number of local codes. I have asked that the regional office again petition the Medicare contractors to begin now to reduce or eliminate the remaining local codes and to use national codes or modifiers.
Efforts to reduce local codes for the Medicare contractors is working. Region V recently reported that, after asking contractors again in the region to review the local codes, they were able to eliminate 122 codes and 62 modifiers. The contractors will be asked to closely review the 2001 HCPC update and strive to eliminate as many of the remaining local codes as possible.
If any codes remain, they will be instructed to prepare and submit national coding modification requests with documentation to support each request to the regional offices, who will determine if the code is needed by the contractors in the region, and then present the final coding request to HCFA central office and the HCFA HCPCS work group. They will review it and make a coding decision or a recommendation to the national panel for a permanent national code.
When received by the regional office, the requests are placed on the next available work group agenda. We generally schedule a work group agenda every month of the year. We have to have time to mail out the information, to mail out the packets, to get everybody informed, so that when they come to the meeting they can make the appropriate judgement.
We have a three-week lead time. So, depending on when we receive it, it could go within three weeks to the next agenda, or perhaps another four weeks to the following agenda. If a decision is made to establish a HCFA code based upon that request, that code could be established within a matter of a couple of days, a number, and of course, it has to be operationalized.
I think that is what some people forget. You have to review it. You have to know what these codes are. You can put a number on anything, but the number isn't any good unless it can be recognized by the data systems. Additionally, I have been working with the Medicaid bureau and HCFA central office in communicating with the Medicaid state agencies via telephone conference calls, in an effort to assist with the major task of moving toward the elimination of the local codes used by Medicaid state agencies.
They have developed a plan and they are putting it into action. When they have identified a prioritized list of codes that will meet the need of the state agencies, they will be instructed to submit the request with supporting documentation through HCFA central office, Medicaid bureau, for review. Central office will coordinate the preparation and the submission of the request to the HCFA HCPCS work group will review and cording decisions, or for recommendation to the national panel for national permanent codes.
We anticipate that this will initially be a major task. Once the bulk of the codes have been identified, the state agencies can then coordinate any subsequent coding requests through the Medicaid bureau, or through submission to the regular HCFA HCPCS work group and national panel coding process. The alphanumeric coding process is evolving and many changes are occurring. In October of 1998, we placed the HCPCS file, without the D codes, on the internet, free to the public to view and/or download if they wish.
We established the HCPCS internet web site, thus providing another link to the alphanumeric HCPCS code set and the ability to download a copy of the HCPCS coding modification information packet and request form. We posted the HCPCS national panel agenda, the tracking numbers and all the coding requests as received, increasing public awareness and permitting an opportunity for public review and comment.
The internet web site also includes a list of various sources for obtaining paper and electronic versions of the 2001 update, a list of sources for the 2000 Medicare fee schedule information and a list of the temporary HCFA HCPCS codes established for use this year. For those with questions or comments regarding the alphanumeric HCPCS coding process, we have established a direct electronic link, HCPCS@hcfa.gov.
The Medicare Manual section 4501 and other manuals will be revised to reflect the HCFA temporary coding process involving the Medicare regional offices and the Medicaid bureau and central office. The national code sets -- CPT, alphanumeric HCPCS, ADA, CPT-III, the FDA NDC codes and ICD-9 codes -- have established maintenance and updating procedures in place.
Public and private insurers must work together to make necessary changes, and take immediate action to support and use the national code sets. Remember, when people speak of standardization of local codes, they actually mean the use of national codes. Thank you.
DR. COHN: Thank you very much. Lisa Doyle?
MS. DOYLE: Hi. I am very pleased to be here today. I have been asked by the National Association of State Medicaid Directors to present to the subcommittee some thoughts about potential tools and processes that could lead to a solution of the local code issue. This is obviously critical to be addressed in order for the state Medicaid agencies to continue to be able to conduct their business. We welcome the opportunity to be involved.
First, I will provide an overview of the efforts being taken by the National Medicaid EDI HIPAA work group.
Second, I will discuss the difficulties with the current procedure code review and approval process. Finally, I will present some recommendations that address he problems created by the elimination of local codes under HIPAA.
In November of 1999, the National Medicaid EDI HIPAA work group, or NEMI, was formed by NASMD, to give states a forum to assess the impact of HIPAA's administrative simplification on the Medicaid systems. Today, there are approximately 40 states that are actively involved in that work group. We conduct national conference calls twice a month to discuss any burning issues that we have that need to be resolved.
Because HIPAA AdSimp has so many components that affect Medicaid systems, e have identified or formed several subgroups. One of the subgroups is tasks with identifying and categorizing local procedure code and procedure code modifiers.
The New York State Medicaid agency leads the local code subgroup and receives local code templates from the NMEH participants. We have a pretty strict criteria for local code research and what should be done prior to submission to New York State.
First of all, find all local codes. There are sometimes some codes hiding in little pockets. If you don't thoroughly go through, you may think that you have all the codes submitted where, in fact, you have forgotten, say, your entire vision program or something of that sort.
Determine if there is an existing national code. We don't want any of the Medicaids to be submitting codes if there is, indeed, a national code that will fit their business needs.
Third, eliminate any codes from the list that were not billed in either calendar year 1999 or 2000. We certainly want to be able to prioritize this list. We felt that eliminating codes that didn't exist prior to that time was a good start.
These submissions will form the basis of a national local code data base. In order to be included, states must include this information to New York State Medicaid by July 31, 2000, so just the end of the calendar month. Once the local code and procedure code modifiers have been received, they will be prioritized by volume per category.
We will then submit all in priority order, procedure and procedure code modifiers to HCFA, for inclusion in the appropriate national coding structure. As it was discussed in the previous panel and within this panel as well, state Medicaid agencies rely heavily on local codes to meet their unique business needs.
Since its inception in the mid-1980s, the HCFA coding system has been reflective of the services and products available under the Medicare program. If all the Medicaid processes currently being supported by local codes must be included in the Level II HCPCS, the demand on the HCFA HCPCS work group will be immense.
We question whether the existing quarterly review process and the HCFA resources will be adequate to meet this demand.
We are concerned that, unless there is adequate staffing for the review each quarter, states will have no alternative but to continue to use their local codes beyond when HIPAA compliance is mandatory. In addition, the process of adding new procedure codes has not been developed to accommodate the numerous rapid turn-around requests that states will have.
This has been discussed quite a bit by some of the other panel members. So, I won't go into detail but our basic concern here is that state Medicaids have a different time frame than the HCPCS review process has in regard to state legislated services that we must provide, that won't necessarily fall nicely and neatly into the review process time frames. Local codes are integral to the business of Medicaid and reflective of the unique products and services we offer.
Many of them support closed loop transactions, for which Medicaid is the only source of payment for specialized services. While the goal of standardization is logical in today's electronic world, it may not make sense in all situations.
We believe there is little value in imposing national codes on the closed loop business of Medicaid. However, in the absence of the final rules, assuming that all local codes are eliminated, we offer several recommendations. These are based on the premise that Medicaid will create the greatest demand, both initially and ongoing, for new Level II HCPCS codes.
First of all, in light of the fact that the business needs of Medicaid differ from those of commercial insurers and Medicare, it is critical that we become part of the process. The National Association of State Medicaid Directors should be offered a direct voice on NCVHS and the HCPCS alphanumeric editorial panel.
Both of these decision-making bodies already include representatives from the commercial insurance sector. Secondly, timing is critical in establishment of procedure codes and related nomenclature, should never be allowed to drive effective dates of policy. State legislation and approval dates for federal waivers drive effective dates for policy which, in turn, create the need for local codes today, level II codes in the future.
The alphanumeric editorial panel that advises HCFA meets three times a year. This is not adequate for the needs of the states. Consumers should not have to wait for a service, nor should providers be asked to wait for payment for a service authorized as payable, simply because the bureaucracy has not yet created a procedure code.
A more rapid response process must be implemented in order for standardization to succeed. In the interim, HCFA may want to consider a policy of allowing states to create and use temporary level II codes, while awaiting action by the HCPCS work group.
This policy could include an understanding that, upon establishment of a permanent level II code, if that code differs from the temporary code, the state will agree to adopt the permanent code and, where necessary, perform history conversions to accommodate federal reporting.
Once again, I would like to thank you for the opportunity to testify before the subcommittee today. Elimination of local codes under HIPAA presents a challenge of huge proportions. It will take a great deal of collaboration between not only HCFA and the state Medicaid programs, but also with the entire health care industry. We look forward to being an active player as administrative simplification moves forward. Thank you.
DR. COHN: Lisa, thank you very much. Allen McBride?
DR. MC BRIDE: Good morning. I am Allen McBride. I am the senior associate medical director for Blue Cross Blue Shield of Michigan. I have been invited here this morning, more or less, just to give you an idea of what one Blue Cross Blue Shield plan has been able to accomplish within the field of local codes.
To give you a little bit of background, Blue Cross Blue Shield of Michigan historically has used four different code sets, for the purpose of reporting and processing professional claims. They are the HCPCS Level I and II codes, which we just recently had a discussion or a presentation, the Blue Cross Blue Shield Association's S code system which was mentioned in your first panel.
When all three of those failed to give us the coding needs that we had, we had to develop our own local X codes, Y codes and Z codes. Why did we have to create these local codes? I think we will just go ahead and give a brief summary, even though you heard some of those reasons this morning.
There was a need for Michigan-specific codes, because of, for example, state mandates or something that we decided to cover for our local business which was not covered anywhere else in the country. There were also newly-recognized health care services for which the coding structure had not kept up with the technology. We had recognized it as eligible for coverage, but had no way to report it.
We also needed to have some way to automatically process the claims for what we call NOC codes that are currently in CPT, and not elsewhere classified by any method, which we needed to know by our accounts what we were paying for. We also needed to have the capability to correctly process claims for services defined by our group contracts.
The Blue Cross Blue Shield of Michigan has what we call a large amount of national account business, where we actually do all the claims processing or administrative work in Michigan, but we have subscribers across the country.
Also, we have some very specific reimbursement mechanisms with our local provider community because of our market share and other relationships. Each Blue Cross Blue Shield plan faces those same restraints. So, compound 52 Blue Cross Blue Shield plans all with the need for local coding structures, also spread it over to the commercial carriers.
Then that led to a whole variety of problems that we have been facing over the past several years, and has really deteriorated our relationships not only in our ability to service national accounts, in our relationship between the Blue Cross Blue Shield plans themselves.
Providers not knowing what codes to use for out of state. They may have very familiar -- let's say, in Michigan, a Michigan provider knows how to bill us. They already have put those numbers into their system. Now, they are going to bill someone from Illinois and the claim gets denied. It is tied up in administrative hassle.
As I said, providers using the same codes which are good for one carrier may not necessarily be recognized by another. We have great difficulty analyzing utilization trends because of local codes, which may or may not survive from year to year.
We have difficulty in providing sufficient benefits across our state borders. For these reasons, we started an effort back in the spring of last year, in order to examine the need for local codes, and what was going to be our position, especially in light of the HIPAA implementation coming out about it. We did it a couple of different ways. Once, we tried to find a national replacement when possible. We wanted a HCPCS Level I or a HCPCS Level II code, because that helped us with our cross over claims with Medicare and also when we are the secondary carrier on a coordination of benefit issue.
Failing that, we would go to a Blue Cross Blue Shield replacement code, or an S code. When all else fails, we had to more or less bit the bullet and say we are going to eliminate the code, we don't need it. So, we went through that process and we identified 532 local codes that were unique to Blue Cross Blue Shield in Michigan that are scheduled for the block some time this week or next.
We were able to eliminate without replacement 236 codes which, again, were unique to Michigan. We replaced with a HCPCS Level I or a Level II code an additional 216. We were able to replace 41 of our local codes with Blue Cross Blue Shield Association S codes.
We are making some assumptions on that move, on the S codes. One is that the HCFA Level II codes will remain in the post-HIPAA implementation era.
Two, the S codes will continue to be published as part of the HCPCS level II update, and that CPT-5, which I believe some of you may have heard about, with some changes that are going through the AMA CPT process, will give us the coding structure that we need for the granularity and, hence, no longer a need for a local code. We did look at the cost of what was going to happen to our benefit pay out. We estimate it will be less than one percent from the local code.
There will be some administrative cost up front as we go back into a hard coding claim system and try to remove these codes. We believe that, once that is accomplished, the administrative savings, no longer a need for manual review, unnecessary suspense of claims will not only benefit the plan but also the provider community.
The reaction to our movement toward the elimination of these 532 codes, overall, has been received favorably, especially from the provider community, who now can bill us the same way they bill everyone else. We did have some reluctance on some of the accounts at first because their main concern is, especially on an administered service account, where they pay their own bills and we are just the administrator, what would it do to their claims payout.
Historically, when we went back and looked at the origin or the root cause for these local codes, many of them came because there was a group-specific request. They wanted some little quirk in their benefit structure that was unique to them because they thought it would save them money.
More or less, we have now taken this opportunity, for all the reasons I have told you previously, why we wanted to eliminate the local codes -- I was joking with Dr. Cohn earlier, and this is an aside -- we are going to blame the government and HIPAA because now we will be able to make these changes. Overall, it has received very favorable treatment.
There is still going to be a need, when we look back to those root causes that I listed, there is always going to be a need for local codes. You have heard those repeatedly this morning, from everyone who has presented so far. I think we have to have some type of a national system by which we can have the prompt release of at least a temporary code.
Again, just like our previous speaker had mentioned, if we make the decision at Blue Cross Blue Shield of Michigan to cover a new health care service, we want to be able to cover it today, not next year. Some of these new technologies, again, we have the possibility of morbidity and mortality in our subscribers if we delay reimbursement of new services that we recognize. With that, I will abbreviate my testimony, Dr. Cohn.
DR. COHN: Thank you very much. Bart Killian from Utah?
MR. KILLIAN: My name is Bart Killian. I am with the Utah Health Information Network, which is a private/public partnership, not-for-profit organization made up of state government agencies, the provider organizations within our state, excluding the state dental association, and all of the Utah domicile payers with the exception of Cignet Health Care, as well as the major private corporations in our state.
A number of things that I was going to talk about have already been covered. So, I am going to slip down and only cover those areas that have not been discussed this morning.
We are trying to run an organization that is very HIPAA-like, in that we cross payers, we cross entities, and we have been running since 1995, some days more successfully than other days, but that is the way it goes. I would just like to say that we determined early on that we would eliminate as many codes in as many hours as possible. Our providers mandated it.
They took an opposite view of what we heard this morning. They felt there was a much greater area for fraud by mistake on their part if there were all of these specific codes that meant different things to different payers. We definitely went for reduced amounts of codes early on. As an organization, we did exactly what Blue Cross of Michigan has done.
We went with Level I, Level II. Since we are multipayer, we looked very carefully then at what was then the next level that we would use to keep our codes smaller, but still cover everyone's problems. We decided, and our Blue plans decided, that they would not use S codes but, in fact, we would go to the area of state Medicaid, which is part of our coalition, and use Y codes.
We spent approximately 11 months of anguish looking at Y codes, getting rid of Y codes, convincing state Medicaid that they didn't need Y codes, and fitting all commercial areas into those. At this point in time, UHIN for that area uses Level I, Level II and Y codes. Now I am going to talk to you about how we use the Y codes and maybe an alternative as to how you can do it.
There are certain areas at UHIN where you just had a very hard time getting codes at the national level. We have not been able to get into some of the national codes because either they are not physician-based codes or Medicare doesn't pay for them. Therefore, there is less interest and there were numbers of local codes generated. We have attempted to pull those together and we believe we have reduced codes.
Now I want to go into areas where we have created codes. So, this isn't a single way to do things. UHIN has standardized a number of areas and we used Y codes as our temporary -- and I use that loosely -- but our temporary coding structure while we are trying to gain national exceptions.
We have a standards process that becomes part of our insurance rule as we go through it, and when it is adopted by our group unanimously, it becomes part of the insurance code. Clearly, home health is an area that there are no national codes. No one seems to take an interest. No one wants to use it.
In our state, it is a big industry, not only for Medicaid, but for commercial payers. It seems to be a more economical way to deal with those things. I have included in your packets copies of these standards that you may wish to look at. I am not going to spend a great deal of time on them.
First of all, Dr. Root was supposed to be here and isn't. She knows the detail much better than I do. I can tell you, assuredly, of the processes. Home health is clearly an area where we had to do something, create something in the Y code area to do what we needed to do.
The next area is an example of state-mandated areas. Again, we talked about this earlier on with this. It is an area where dietary supplements were required, not only of Medicaid but of commercial payers in our state, a very short period of time to respond.
Not only did they have to pay for them, they had to do it with standard codes so that providers got paid within a specific amount of time. Again, try and get that through Level I or Level II in the appropriate time. Again, our Medicaid agency was good enough to establish Y codes, go through the process with us.
As you look at those standards, you will see they are very detailed. They have way more information than any of us normal people want to know, but I guess it is necessary to adjudicate claims. Dietary supplements aren't the only areas. There are areas -- nationally we have to be aware that medicine is a regional and state-practiced industry. That is just a fact.
Legislatures have a great deal of impact on what you do and when you do it. I really would argue, as Michigan has, for a temporary local process at some point in time. The third area that has become very popular and probably the most annoying area to us to get any kind of national codes is telehealth.
By the way, as you look at those standards, there are really very few codes and they are really modifiers to make it national -- this is an area of medicine that is growing rapidly in our state, but not only in our state, but in the entire west.
We were not alone in trying to break down the walls of Medicare to get these codes in place. We know that the states of Oklahoma and Montana and California, as we have worked with them, have tried very, very hard to get these. Again, it is not traditional and it was very hard to do. The process needs to be involved. Again, I am highlighting only those areas where we have problems, understanding that most of it has happened in the other areas.
The next one is ambulatory surgical centers, another -- oh, yes. You understand, we are a HIPAA-type organization in our state. Lots of discussion happens on these things. What actually happened when we got through and argued all the pros and cons to it, it boiled down to, was it actually cost billed or market billed. That is really what it boiled down to.
We solved that problem but, again, how do you do that. By the way, all these codes have been forwarded to one place or the other and have been since early 1999, and we have not gotten any responses to date for national codes, nor have any of the partners we have used.
Local codes. In summary, I think we as an organization and as a state are committed to complying with HIPAA and complying to national code lists.
If we are going to truly make a difference in the cost of health care in this country and administrative simplification, we all have to be committed to that. Clearly, we will do what we have to do in order to make that happen. I need to emphasize the testimony of this morning.
We need to open the process. We need to speed up the process, and we don't need to limit it to a specific payer or a specific provider. I think codes, as Mr. Landen said this morning, are not proprietary and they cannot be used for business reasons. There are a number of ways to use codes and keep your plans proprietary.
We would hope that, as we go forward in HIPAA and NCVHS makes the recommendations, that they look for a way to open the process, to speed the process and make everyone's business needs met. Thank you for your time.
DR. COHN: Thank you. James Marshall?
MR. MARSHALL: Thank you, Mr. Chairman. My name is James Marshall. I am the director of the Council on Dental Benefit Programs for the American Dental Association. We represent approximately 144,000 practicing dentists in the country and appreciate the opportunity to offer the following comments on the issue of local procedure codes and the role of the ADA's code on dental procedures and nomenclature known as CDT-3, in the implementation of administrative simplification standards required by HIPAA.
The ADA fully supports the goal of eliminating local codes by HCFA as soon as possible. If a process is established by HCFA to review requests for temporary local codes, the ADA strongly recommends that it have input along with other data maintenance bodies into that process.
Such input would help eliminate duplicative codes and help identify suitable existing codes that could meet the needs of payers. In the opinion of the ADA, temporary codes should not be used as a means of bypassing code sets named in the standard and thus defeating the intent of the original legislation.
The Association is committed to continuing an open and functional code review and revision process. As mentioned, a mechanism already exists for submission of suggested revisions to CDT-3, specifications for which can be found on the ADA's web site.
The Association is of the opinion that, with a concerted effort by all interested parties, the needs of payers, providers and employers will be fully addressed. Codes will be reviewed by the ADA on a regular basis with revisions made in compliance with HIPAA. This review and revision process should permit timely introduction of needed codes as the art and science of dentistry dictate but without undue burden on users of CDT- 3, either providers or payers.
As part of the most recent revision to the dental procedure codes which went into effect January 1 of this year, the ADA agreed -- as has been previously mentioned -- with a request from the HCFA to change the ADA code from numeric to alpha by replacing the first digit 0 with the letter D. This change eliminated a duplication of certain CPT codes that existed within CDT. The change should also result in HCPCS and CDT becoming one and the same code set for dental procedures.
The ADA is in the process of executing licensing agreements with users of CDT-3. Third party payers, including HCFA, practice management, software vendors, publishers and other users of CDT-3 are being licensed in this fashion. Our intent, in part, is to assure that no unilateral changes in the copyrighted code -- numbers, nomenclature or definitions -- are made by users of CDT-3.
The ADA has organized the dental content committee for purposes of coordinating revisions to data elements in electronic business transactions involving dental offices. This committee includes representation from the Health Care Financing Administration, third party payers, providers and employers.
Local codes that are not related to dental procedures -- CDT-3 -- but that are used in electronic transactions to and from a dental office should be referred to the dental content committee for consideration. Once again, it is our pleasure to have presented here.
DR. COHN: Thank you very much for that. Shall we take questions? Kepa, would you like to start?
DR. ZUBELDIA: Thank you very much for the testimony. I think it was very enlightening. In fact, some of the more interesting parts were about the disagreements between the people here.
For instance, I would like to get a clarification. How often does the committee meet to review the requests for national codes. It has been said it meets monthly or quarterly or three times a year. I am not sure now.
MS. RILEY: As you can see, there is a great deal of confusion over this very complex coding system. People have a tendency to interpret it based on hearsay, as opposed to really looking into it. As I say, the HCPCS coding system is a national coding system. It is two parts private sector and only one part public.
The decisions by the national panel, on that group of codes that I identified as the permanent national codes, are made by that national panel, which meets three times a year, or four of five, depending on the number of requests that are necessary. If we only had a couple, we might only meet once a year. We base the number of meetings on volume.
We have, in the past five years, have met three times a year every year, for the national panel to review for the national permanent codes, the A codes, the B codes, the J codes, the L codes, for the orthotics and prosthetics, the J codes for the drugs, et cetera. The process is more than that. The process involves these various -- these three major organizations. Any request for a HCPC code comes to me as the central point of contact.
I distribute that information out to the associated groups. I hold a work group meeting at HCFA. I have meetings scheduled every month. If we only have three items on the agenda, we certainly don't hold a meeting. We are not going to bring people from out of state or hold a meeting every month.
I would say that, in this year, we have had nine HCFA HCPC work group meetings. At those work group meetings, there are two things that can happen. They are a review and a decision by the work group that this request deserves special consideration based upon Medicare's internal operating needs.
Medicare needs to have this code in order to implement a law or a special procedure or some reason that the number of claims for a particular product or something is overwhelming, and we have to establish the temporary HCFA codes, being the C, the G, the K and the Q. Now, that is a different process. Part of this process was also that we had encouraged -- we have a Medicaid representative that sits on this work group whenever we meet.
One gentleman here says he had submitted and there was no interest. If you take the time to go through the alphanumeric codes, you will find that many of the codes are not valid for Medicare, are not paid by Medicare, remembering that coverage and payment are separate from coding. We look at the codes from a unique category standpoint, not whether or not Medicare is going to pay for it or not.
If no code existed and somebody has requested a code and there are enough claims to justify the establishment of a separate code -- and I say that because we get occasionally requests from a product manufacturer that says, well, we sold 10 last year. Well, that is terrific but they can submit that claim using a miscellaneous code and receive manual review for those 10 claims around the country and that does not need a separate code.
If they have an adequate number, and we try to look at the percentages of patients or bennies that would benefit from the product or the procedure that is being asked to be coded, to see what percentage of that, and we usually say, actually if it is more than three percent of that number, actually, we will go ahead and see that a code is established.
An example, Medicare has very little need for a code for a breast pump. In the 2000 update, there was a code added because we received a request for a breast pump and there was adequate use to justify the establishment. Of course, it is marked that it won't be paid for by Medicare. So, the panel meets three times a year or more, and the work group tries to meet every month if there is an adequate agenda.
It is obvious that the confusion exists. As the gentleman said, there is no interest in the codes. Well, we sure have interest in all the codes. He said, they had also submitted for national codes. Who did you submit for -- I mean, this is very specific. Who did you --
DR. COHN: Please, I would like you to talk a little bit.
MS. RILEY: Who did you submit to? We are sitting here and you saw these looks between the panel members saying, we never saw it, we are not aware of any such request. Had we been, we would be looking at it and we would have considered it.
DR. KILLIAN: Dr. Root filled out the form. We got them from the Western Region, sent them to Medicare, and we sent them, particularly for telehealth, we send the products in, the rationale, the whole thing, tried to follow through and haven't received any response back in those areas.
MS. RILEY: I am not aware of ever receiving any such requests. Again, Medicaid agencies, you know, HCFA manages not only the Medicare, but the Medicaid. We have encouraged the use of the HCPC code and the use of the HCPCS process. We have received -- would you say there are like two from Medicaid agencies, requests over the last couple of years and we have tried to address it.
We would like to encourage it. That is why I have been working with this work group and on these telephone conference calls, trying to provide information and help in coordinating the activities to make the submission. It will not be the HCFA HCPCS work group or the national panel and say, well, this code has a code over here. It is up to the states to take that action.
DR. COHN: I just want to make a comment here, because I am fascinated by this conversation. Certainly telehealth is a very interesting example where there is actually a HCFA final rule around telehealth, particularly in rural areas.
This is certainly an issue to HCFA. I am actually sort of impressed in this panel and the last that there is a big problem -- at least I would observe there appears to be a profound lack of communication. I mean, if people are sending things and they don't even know where to send it to and they are sending it to the wrong place, if they are sending it to regional offices it is not making it to the right place in the national area.
I am sure that Lisa and C. Kaye are talking together, but as I listen to the issues, I am once again just sort of impressed that it appears that one of the main issues we are confronting here has nothing to do with policy, has nothing to do with practices or procedures, but letters aren't being answered, people don't know where to go, et cetera, et cetera. Maybe you can comment.
MS. RILEY: That is why we have established the HCPC web site, so that information is posted and made available about the process, about the request forms, who to contact, a direct e mail connection. HCPCS@hcfa.gov will get that message directly to me.
I will respond. If you can't find it, I will help people. I do remind you that I deal with the coding aspect and with the coding data base, not with the payment associated with the codes, or the coverage. Those are other areas, because payment and coverage are separate.
DR. COHN: Well, you need a code to charge, frequently, and that is, I think, the issue. Art, you had a comment.
DR. KILLIAN: I was going to say that, now that the web site is here, I promise you that you will have at least all of these standards and probably five more recommendations before the end of this week.
DR. COHN: The one comment that I was going to make, and I think Kepa wants to make a comment, is that the establishment of a web site does not solve all communication problems.
MS. RILEY: It is one step.
DR. COHN: It is one step. There is the issue of publicizing that web site and publicizing the existence of the whole process which, as I said, I think I know a fair amount about codes, but I have learned a fair amount today in your testimony, once again, a communication issue. Kepa, do you have a comment, and then I know Karen has a question.
DR. ZUBELDIA: It seems to me like the process is somewhat broken, beyond the communication problem, and again, this is my perception. It looks like HCFA has a status of a favored nation as far as getting HCPCS codes.
MS. RILEY: S codes, private sector.
DR. ZUBELDIA: If somebody else submits a request for a code, and HCFA determines that they don't see a need or there are not enough claims, the code is not given. I would say that I have heard previously today that some of these plans want to institute a new reimbursement scheme, something new for which there have been no claims before and they need a code without claims.
If a private entity needs a code for which HCFA sees no need, I don't think that should be the question. I think the process should be more open to the needs of other people. Let me finish that. Another thing where I see the process could improve is by giving representation to Medicaid in the national panel.
The national panel has HCFA and it has the Blue Cross Blue Shield Association and it has HIAA. I think Medicaid should be there, too, as an interested party. Another part where I think the process is broken, and this, I would like to hear the comments from the whole panel, is how you find the codes.
Lisa mentioned that they have been trying to find the codes and that is difficult. I can see Medicare, through their carriers and intermediaries, issuing local codes, and Medicare did a great work of consolidating local codes in 1995. Medicaid is also issuing local codes, and they were not part of that consolidation. Then the commercials also issue local codes, and they were not part of the consolidation.
Now, if I am trying to find all the local codes, unless I have a situation like in Utah where there is an organization that coordinates the local codes for the state at a state level, I go to any of your states and there are local codes coming from multiple sources and there is even no assurance that two of those sources will not issue the same code with a completely different meaning, which can perfectly well happen. I think the process for local codes, when we are talking about local codes, we are talking about multiple things. It is not one set of local codes.
From HCFA's perspective, you issue local codes and that is what you see. Medicaids in each state issue their local codes and that is what they see as the issue. I think the issue is much bigger than any one entity. I would like to get comments from the panel on this.
MS. RILEY: Just a couple of comments back on that. The issue isn't local code process, the issue is, as I said, it is not the standardization of local codes, it is the use of national codes. That is the way we need to move, away from all of these entities just sitting down and making up any number of mean anything and using it. It does cause for a great deal of confusion.
Medicare and HCFA does not make the decisions. This is a national panel for the national codes, and those decisions are made jointly by private sector.
HCFA oversees Medicare and Medicaid. We have a work group that has representation from the Medicaid. I have had someone from the Medicaid bureau on my work group since I have been there, because I felt it was very, very important. I would often send them back to find out, is this an issue or a request that is important to Medicaid and, therefore, Medicaid and Medicare are represented on the work group.
When I go forward, I go forward as taking the recommendation from that work group making to the national panel and, you know, for those national codes or, at that work group, Medicaid and Medicare participate in deciding about the establishment of those codes.
They used to be called temporary codes, but permanently temporary some of them will be because, like EPO and the ESRD area, those codes were established as HCFA codes, as temporary codes. They will be around forever because no one else uses those particular Q codes.
We are not -- the work group and the national panel is not a barrier to the coding issue. The problem has been, from my perspective, that the Medicaid agencies have not participated in the program.
If there is a need for a set of codes, no one has bothered to come forward. Any national codes, temporary national codes, HCFA or private sector, which are the S codes, we made sure that the S codes were also placed on the web site and part of the HCFA data base, so that they could be used -- a lot of them were -- I apologize for my incoherence here, but it is such a complex situation.
The S codes had been established for years and years and did not appear on our data base. We discussed it and said, if they are out there and you are using them, let's make them part of that national data base so that everyone can use them and be aware of them, and they can be used nationally, just as our Q codes.
As I say, if Medicaid had ever submitted a request, we would have certainly considered those requests right along with all the others and been working to see that those codes were established expeditiously. We are not being a barrier to this. We want to help them get the codes that they need.
MS. DOYLE: I would just like to indicate that in some scenarios, as we have mentioned, we like to call them our closed loop areas, where we provide a unique service to a section of the population where the provider doesn't bill anyone else, because there isn't another health insurance that pays for the service.
In those situations, and prior to HIPAA, we didn't really need a national code for that. That was our feeling. So, in regard to not submitting codes previously to the HCPCS panel, I think it is somewhat irrelevant on a history-type basis, because prior to HIPAA, it wasn't necessary. We got waivers from the Federal Government and from HCFA to provide these services.
Certainly with our contacts with out regional offices, they were aware that we were using and assigning local codes. Really, with a lot of things related to HIPAA, if Medicaid was not at the table previously, there was not really a need for us to be, because the standardization wasn't mandated.
I don't want to sound defensive on that, but I would also like to indicate that I think it is important that we are recognized as a group who has been very proactive in consolidating almost all of the states in coordinating a national data base for Medicaid national codes, and trying to make sure that, when we send our request to HCFA at least initially, prior to a state-by- state basis, that we will have done a lot of this work. We are going to categorize them by the category of service. Then they can say, well, here are all of our home health-related codes.
When we do that, and we consolidate that data base, we are hoping to be able to see where we all are duplicating the same kind of service. So, instead of 40 states sending prenatal care coordination procedure code requests to HCFA, they would only get one for that particular procedure.
I think that that particular level of proactive measure is a good indication of how cooperative that we are being. I would also like to indicate that this will be no small feat. It won't be a matter of, oh, everybody found their codes. Well, did they really find all of them.
Is there really not a national code out there? Once we continue to do that clean up job on that list, then it is a matter of where do we have duplicative services within this data base so that we can eliminate the duplicates before we send them to HCFA.
Having them due by the end of July, I really don't have any guesstimation that I can give you realistically on when we can make sure we will have a very clean template and table to be able to submit. It is really difficult to say until we get an indication of what the volume is going to be.
DR. COHN: Other comments from the panel?
MR. KILLIAN: I would like to say one thing in regard to the response we got. To say there aren't a lot of claims or hasn't been done before is not a reason not to establish a code.
I am going to go back to telehealth. A number of western states, the small rural states, watched the Montana experience. They got a waiver from Medicare to pay for telehealth services in certain areas. A lot of us looked at it and it went slow. Oklahoma became an adopter, we became an adopter.
When we started out in our state with telehealth claims, and we got a standardized coding method, there was not a single payer -- public or private -- who would pay for telehealth. What they wanted to do was collect the data, run it through their actuaries and see what it meant.
Now, that is two years ago. Today, more than half, including the public sector, pays some form of telehealth claim. To say that volume is a reason for denying a code is, I think, an incorrect process. The same could be said of home health.
We really need to look at a methodology to allow plans and/or geographical areas to be able to use codes to determine how medicine should be practiced. Thank you.
MS. RILEY: May I make another comment, please?
DR. COHN: Yes, a short one, and then we have another question.
MS. RILEY: On the telemedicine, we certainly did look into that. I am sorry, but I just didn't bring my code book with me today. There are so many and so many things that have been happening.
I know that we did review telemedicine codes and that we did establish, I believe two general codes, based upon a request, not from the community and not from Medicaid, but internal from Medicare, saying they were showing the justification for the need to be able to identify these services. I believe there were two last year.
I recall it, but I don't have the details on the top of my head. I would be more than happy to look it up and get back with you and share the codes that currently exist. As I say, again, I was thinking about a $10,000 bed, that 10 were sold, doesn't qualify it for a separate code.
Whenever there is a law or a new type of service that is not covered any other way or not identified any other way and you are receiving claims under the miscellaneous code, and you provide some adequate details and justification, the national panel and the work group are extremely open to those type of supporting documentations. We don't just look at numbers. We look at the whole picture.
DR. COHN: Thank you. Obviously, we are not assigning any responsibility. I know you are feeling a little defensive. Please don't. We are just sort of looking at the process.
MS. TRUDEL: Actually, I have two questions. Dr. McBride, I understand that you are associated with the CPT panel process. I wonder whether there is an analogous local code issue with CPT codes and, if so, how does that panel handle those questions?
DR. MC BRIDE: You must have gotten that information from Dr. Cohn. The CPT is going through what we call an evolutionary process that started almost 24 months ago now, looking at how it could serve its customers, looking at non-professional providers.
One of the concepts that we have actually already started with is the concept of a tracking code or a provisional code, which will not necessarily be recognized by the payer community as eligible for reimbursement, but will be available for reporting mechanisms and for utilization trends and for health outcome analysis.
For example, a new and emerging health care technology which the clinical evidence is not there to say there is some efficacy but it is in a clinical trial, there is the potential that the CPT panel could assign a tracking code, so then they can measure health outcomes. There are other types of codes, like for vaccines, which was a change in CPT this year, with a mid-year release on July 1. Those are two examples.
MS. TRUDEL: My other question is actually to the panel at large. Obviously, one of the themes that we are hearing here is that timeliness of the assignment of new codes is very important.
While legislation passes very quickly, we obviously, most of us, have some kind of advance warning that we are going to need a code for something. I guess the question is what kind of turn-around time would you believe be fast enough that it would preclude the need for temporary codes? How fast is fast?
MS. DOYLE: That is a very good question. I guess I would like to start out by indicating that a monthly review panel meeting would be preferable to three times a year. I think that from a national Medicaid standpoint, we would feel pretty favorable on that kind of schedule.
It is not just the review process, however. If you have a group of individuals that are a good cross section of health care on a national level meet once a month, I think it has a lot to do with how quickly are they able to make that decision, turn that around, establish a code that we can use. Do we have to wait until it is published the next year. I think it has a lot to do with the timing of all of those things, but we would like to see monthly panel meetings.
DR. MC BRIDE: I can only give you the example. Some of the larger or more what I would call volatile or visible health care services, I actually have to take to our large accounts to get them to buy into it. The commitment I have to the account is that, once they give approval, I can process the claim within 30 days.
MS. RILEY: How long does it take to get the approval?
DR. MC BRIDE: That varies by the account, anywhere from one week to six months.
MS. RILEY: That is the way it is with the coding system. When a request is received -- I had said earlier -- and there is still that confusion, I believe that since HCFA and Medicare and Medicaid are jointly working together and HCFA sort of oversees the two, that when the Medicaid requests would come in, they would not be going to the national panel that meets three times a year.
They would be going to the HCFA HCPCS work group that would make a determination regarding the necessity for a code at their monthly work group meeting. If it is determined that a code is needed, based upon the information provided, they can't just say, I need it, I want it. They have to provide us with supportive documentation to show that this code is -- by number of claim forms, by the frequency of use, by the number of miscellaneous code claims that have come in or something, some legislation that says we have to do it.
That would come to the HCFA work group who would make a decision and establish the code numbers almost immediately. Operationalizing them, of course, takes more time. They go up and they are being posted on the web with the effective dates as they are being established, like the list of C codes for the hospital outpatient prospective payment system are on the web site.
It is not complete yet, and they are not on my HCPCS web site because they are not finalized yet and it is a long way off until activation. Again, it is that continuing misunderstanding of where the codes would come from. HCFA codes would be established for those Medicaid needs.
DR. BRAITHWAITE: I had a comment that I would like to get some response from the panel on. It seems to me that there is a lot of confusion about the value of codes. People confuse the value of a code with how reimbursable it is.
People seem to be confusing the number with some value. That is, if I give you a code, there is some value to that code. From my perspective, the numbers are irrelevant. You can give out as many codes as rapidly as you want. Numbers go up pretty rapidly. We can hand out numbers very quickly.
The real issue and the value of the number is its uniqueness. It would seem to me that the value of the number is providing enough information in your request for a code so that the judgement can be made that, in fact, this thing that you are describing is, in fact, unique.
It shouldn't matter how many of them there are or how many you expect to be or how many are going to get paid for. As Lord Kelvin once said, you can't improve a system if you can't measure it, and you can't measure it if you can't code it in our world today. I would like to get a little response to that.
MR. MUSCO: I, for one, from the ADA, I think we would agree entirely with that. We are looking for an ability to report, for our members to report what services are actually being done as opposed to being reimbursed, for reporting and research purposes.
When new codes are proposed for additions to CDT, for example, that is one of the requirements, that it demonstrates, that the sponsor demonstrate the uniqueness, the validity of the procedure before it is accepted. Otherwise, there are few if no constraints.
While I am on, I would like to clarify that the ADA CDT-3 review process, it was alluded to as a five-year process. The previous process was on a five-year period. It will not be. It will be on a more frequent basis from here on out, so that we will be providing needed codes in a timely fashion.
MR. KILLIAN: Dr. Braithwaite, thank you. You stated what our position is precisely. I believe that the value of the code is strictly its uniqueness. Whether or not you keep it in the long term depends on whether or not that is continued. Clearly, to enumerate a unique position, all you should have to do is to be able to prove that there isn't another number that does that kind of thing.
I have a question for you guys, though. You asked a question about what would be acceptable in terms of not having temporary numbers of interim numbers.
I guess the question I have in regards to that is, how is the rule going to be interpreted as to what is in the specific releases. Is it going to be tied to the implementation guide or can we implement codes within an implementation guide sooner. I think that is really the key.
DR. COHN: I think generally, obviously, codes are handled differently than the implementation guides. There are specific parts, not even so much in the regulation but actually in the law that describe a more or less instantaneous updating process for codes as needed.
Nobody is going to update codes on a weekly basis, I don't think, but it would certainly be able to accommodate anything that we have discussed.
MR. KILLIAN: If you can use them in the time frame, I think 90 days -- I mean, everything knows in advance something is coming down.
You don't know what -- HIPAA is a prime example of that, but something is coming down. If you have got 90 days after that to implement, that is probably sufficient.
MS. TRUDEL: There really are two levels of answers to that, Bart. One is that what we will be adopting is a version, like CPT-4.
That standard would not change until, for instance, we might adopt a CPT-5 instead. Within CPT-4, there are changes over time that happen on a flow basis.
It has nothing whatsoever to do with either the regulations, the standard that is being adopted or the usage within an implementation guide transaction, not constraints whatsoever.
MR. KILLIAN: Then my point of view would be 90 days would be sufficient.
DR. MC BRIDE: I would agree with you that coding has nothing to do with reimbursement. Of the CPT and HCPCS level II codes, there are a multitude of codes that I don't recognize for reimbursement.
MS. DOYLE: I agree with what both of these gentlemen said. You haven't always performed the service yet, so you don't have any data on that.
MS. RILEY: As I said before, coverage and payment are actually separate issues from the actual coding issues. The uniqueness of that coding category is what we look at.
DR. COHN: Thank you. I think we are at about time for a break. I do want to actually thank this panel. I think both the first and second panels have, I think, brought up very important issues that deal with implementation.
I think it has really educated the NCVHS as well as I think HHS staff in relationship to the issues that we are going to be confronting. I believe, based on what I am hearing, that this is going to be an issue that we will be more fully exploring.
This is not an issue that goes away after this hearing, but we will be tracking and I think probably asking for wider comment as we move forward. Certainly there have been a number of issues that we haven't even had time to explore today.
I want to thank all of you. You were an excellent panel. We will adjourn for lunch and meet back at 1:30. Thank you.
[Whereupon, at 12:30 p.m,. the meeting was recessed, to reconvene at 1:30 p.m., that same day.]
DR. COHN: We will get started here in just a minute. Obviously, we want to thank our panelists for coming and joining us. I do just want to take an opportunity -- I forgot to do this during our initial introductions -- obviously one of the things that we do as members of the national committee is that we publicly disclose affiliations and recuse ourselves, as necessary, on issues that are coming before the subcommittee.
I just thought I needed to tell the subcommittee, as they well know, that I sit on the CPT editorial panel for the AMA, which is an area that came up during our last panel. Also, I sit on the NUCC for the AHP, which was an issue that was brought up during the first panel Do other members of the subcommittee have anything that they would like to recuse themselves about or publicly disclose?
MS. FYFFE: I represent HIAA on the national uniform billing committee as a voting member, and also on the national uniform claim committee as a voting member. I also represent HIAA as a payer organization, on the board of directors of the work group for electronic data interchange. Thank you.
DR. ZUBELDIA: I work for ENVOY Corporation and Debbie Meisner is testifying on behalf of ENVOY. I am also a vice chair of AFEHCT Corporation and AFEHCT will be testifying, too.
DR. COHN: Mr. Blair, do you have anything to publicly disclose?
MR. BLAIR: How personal do I get? [Laughter.] I work for the Medical Records Institute, but I am not aware of any conflicts of interest.
DR. COHN: Great, okay. With that, let's open the afternoon panel which is the perspective of vendors and clearinghouses on implementation and what is going to be required. We will lead off with Deborah Meisner from the ENVOY Corporation.
MS. MEISNER: Thank you. I would like to thank the panel for this opportunity. I have been asked, as you indicated, to speak to you a little bit about the impact of HIPAA from a clearinghouse perspective, and how it is impacting our customers and how it is impacting us as a clearinghouse.
We made a commitment to be ready to support the HIPAA transaction sets, codes and everything else to our customers within 180 days after the final laws have been posted. That is our commitment. Our commitment is to help our customers become HIPAA compliant. We have further committed to working with them on any of the transaction sets that we don't do today, to determine what the business needs are, to help them implement those, what tools they will need, and what we can do to facilitate getting those transactions out and in use.
I would like to start out by giving a little history of where we are today. Throughout 1999, ENVOY Corporation, now known as WebMD/ENVOY, went out nationally and did payer seminars, with the intent of educating the payers on what HIPAA means to them, what we would be doing to help them through the process. It was embraced very well by our clients. We had a lot of participation in the work groups. We had a lot of guest speakers come in and talk to them about the security measures, about the transaction sets, and whatever else was going to be impacting them.
We had a lot of participation. As a result of that, many of these payers started participating in the work groups, at X12. That was good news and bad news for us. The good news is they became active in helping us watch what their needs were going to be. The bad news is, they came away with the idea that if they implemented the transaction set, 4010, in that format, they would be HIPAA compliant.
As early as June of 1999, we had customers asking us to implement a 4010 transaction. At that point in time, the final version had not been published. We did go live with several payers using that. They presented their implementation guides to us. We had quite a time explaining to them that that was not the way HIPAA worked, that they needed to use the implementation guides as they were published.
From our perspective, there are two major issues that we are facing to implement HIPAA. The first is the migration and how we will manage the migration when the providers don't have to be HIPAA complaint, but the payers want to say they are HIPAA compliant. We face this -- we have had two national payers, very large payers, want to implement the transaction set with us this year.
The problem is they want to be fully HIPAA compliant with the requirements that are in the implementation guides. However, we don't get that data from providers today. As a matter of fact, it is very difficult for us to present to them an X12 syntactically correct 4010 without filling in blanks with either not present or some manner of saying we didn't get that piece of information.
The main issue that we have been facing is these payers have purchased off the shelf translators that have HIPAA tool kits. So, they are ready to flip the switch. Unfortunately, until the provider community has been brought up to speed with the data content, that is not going to happen.
Some of the other issues that we are having to deal with is the way the transaction code sets and identifiers are being rolled out. With the national identifiers not in place at this time, there is a tremendous amount of additional data that is being carried through the transaction sets for the interim.
For example, some of the secondary identifiers for the providers, their address information which, if the national provider identifiers were in place, we wouldn't need to carry the overhead and storage of all of that data. Print image capture is another issue that we are facing. A large percentage of our volume comes from software packages that take the print image capture from the practice management system and convert it into an EDI transaction.
There is a lot of information that is required in HIPAA that does not exist on today's claim forms. That volume of EDI is at risk at this point. There will be no way we, as a clearinghouse, can take that information and create a HIPAA-compliant 4010 transaction until the claim forms have been modified to take in that extra data.
As an organization, we are participating in the SNIPS group to work through those issues, to try to get the paper claims up to speed, to at least be able to handle the required data content. I would like to get a little bit into the transaction sets. We have been focusing a lot on the claims transaction.
We do, on an average, about 1.4 million claims a night. We are doing a lot of claim volume. In November of last year, we began looking at the 837. We thought it would be about a 180-day analysis period that we would be looking at it to see what the impacts were to us, our clients.
Unfortunately, we are right now getting at the end of it because there have been a lot of changes made throughout that time period to the guides themselves. It has been a very large task. As late as June of this year, there are still changes being made to the implementation guide. So, we are now at the point of looking at what those changes were, to retrofit them into the analysis that we have done.
As a result of this analysis -- and I apologize that the UB50 information wasn't in there, I got that at about 10:00 o'clock this morning, so I will give you those numbers. If you have the paper in front of you, the changes to carry this internal data on our system, which is based on a 192-byte record layout, currently we have 58 records to carry the data that is required.
By adding the additional information in HIPAA, we are going to be adding 98 records. That would equate to approximately 44 NSF records. On the HCFA version 5.0 in the institutional, there were originally 43 to 45 records. We are going to be increasing that to about 78, just to carry the additional data content.
This additional data content is due, in part, to the COB information, but it is also data that was duplicated at the claim level and at the line level or vice versa, for efficiency. What that has created for us and for other people is the need to now look in two places for information, where prior you might have had it in one.
An example would be the place of service code has traditionally been at the line level. In the implementation guides, they have also put it up at the claim level. If all the services were done in one place, you only had to send one place of service code. Although that seems, on the surface, as an efficient way of sending the data, the logic to now look in both places is adding complexity to the transaction processing. I just wanted to make sure you understood that.
One of the things we have decided to do from our perspective is to code our internal system to the NSF sizes, or our best industry knowledge. If you look at the sizing of data contained in an X12 transaction, they are very generic sizes. The example that I give you here is that the tax ID number, for example, in the HIPAA guide is a 30-byte field, when we all know it is a nine-byte identification number. So, we have sized either to the NSF or the NUBC sizes or to the best industry knowledge, rather than to the X12 sizes.
The records that I gave you above would be far more, lots more, if we had sized to the X12 sizing. That is just to give you a heads up. I don't want to be misleading on what we give you for record sizes. We also found, during the implementation, that the guides were not clear in the intent in all places. The example that I give you hear in this write up is that, for example, the telephone number, fax number, e mail segment that was there allows for four and they give you the four qualifiers.
Now, the intent of the work group is they didn't want to tell you what order to put them in, so they allowed for each of the four occurrences to have the four qualifiers. This conceivably could mean that somebody, syntactically correct, could send you four telephone numbers.
We went back in June to the work group and said, I know this isn't the intent, I know the intent was to have one of each of the four, but you need to tighten this up, because if you leave it open, somebody is going to send them and they are going to get dropped on the floor somewhere. They did agree in June to go back and put some semantic notes in to clarify and they did that in several places in the guides.
I don't mean this negatively. I took part in a lot of the work group at X12. This is something, I think, that doesn't come out until you actually start to implement it. Then you say, oh, my goodness, what am I going to do if I get four of them. Do I have to size for four of these, or is the intent one or what was the intent here. We did go back and they were very receptive to tightening up some of those issues.
The implementation guides have required data content that was previously needed by only government payers. This was as a direct result from comments back from Secretary Shalala that if anybody needed it, it should be one claim regardless of who the end payer is. The overhead that that is going to be presenting is, for example, in the ambulance claims, commercial or private insurance companies didn't require ambulance certification and the governments did.
Now the providers are going to have to key that information in on all specialty claims regardless of where it is going. It may be easier not to have to think about do I need it for this payer and not for that payer, but you are also adding overhead to the expense of the claim.
We also found -- and I heard somebody earlier this morning made mention of the fact of the type of service code. That has been removed, and that is used extensively by some of your mid-size payers who use that for edit criteria to make sure that all the information is there.
In our system, we have an edit requiring that if the type of service code is 7 for anesthesia, that minutes are required. So, some of those kinds of edits are going to have to be changed and some of the adjudication systems that can't get down to the procedure code level to determine are going to have to be changed.
One of the issues that we will have as a front end processor for some of these large payers is getting the definitions of things clarified. In the implementation guides they will say, if this is an ambulance or this is an accident claim, for example, then the accident data is required. What constitutes an accident claim? I know in the private sector, even within a company, a policy can have different language regarding what is considered an accident.
Some consider bee stings and insect bites accidents, others don't. So, it is going to be very difficult, as an intermediary, to know when do we require some of those optional segments. Code values, many of the X12 code values have added more codes to them, and our intent is to go in and add them across the board on all of the formats that we support today.
That will help us through the migration period so that people coming in on old formats can still get to 4010 payers and vice versa. Just as an example, this morning, someone was discussing the CDT-2s. We are still converting CDT-2 codes to CDT-3 codes for many payers because they can't take in the CDT-3s.
There is going to be a long time going before all the payers can receive the codes that are mandated. The next phase of our analysis is going to be to share what we have learned with our customers, to determine what the impacts are.
We are going to be starting probably, I would say, in the next two or three months meeting with payer groups to say, here is what we have discovered, here is what we find the impacts are, and this is how we want to start rolling out things during the migration period. Our intent is to first work with the existing data content that we have, add any code values that we need to be HIPAA compliant, look at the formats that we have today and, if there are required data elements that aren't there, add to those formats.
Then, eventually migrate people toward a full HIPAA compliant over the course of the next two-and-a-half years. We have a lot of people who are interested in these focus groups. Hopefully we will get good feedback from them and not step on anybody's toes.
One of my concerns is that NUBC has stepped up to the plate. One of the managers that works for me sits on the NUBC committee as the X12 liaison. They are working to make the flat file format and the paper claim HIPAA compliant, and I am not seeing that with NSF. I am concerned that there are going to be a lot of NSF flat file formats out there.
I did obtain a copy of the Medicare's NSF 4.0 version, and it has not addressed the data content that wasn't in there. If somebody doesn't step up to the plate to take ownership of that, we are going to end up with a lot of versions of NSF out on the street.
Quickly, through the 276, 277 claim status transaction, we do today about 75 percent of our payers participate in some level of claim status in a proprietary format. We did do some initial analysis of the claims status transaction and we have worked with some of our major payers. There is some confusion that needs to be clarified, as to whether claims status is also going to apply to the claims that are received via non-electronic mechanisms, paper or whatever.
There is also some confusion as to whether it is a real-time transaction or still a batch transaction. We are currently doing the analysis to see how we are going to handle this during the migration.
Code values, the claims status reason codes do not have a one-to-one correlation with the status codes that are being used today by these large payers, so the impact is going to be quite significant in making that through the migration period. We are looking to implement it in a real time transaction. We have several payers who are interested in doing that with us.
The 270, 271, we are in production with. Thirty of our 60 real-time payers are in, using version 4010. We do approximately 320,000 real time transactions a month. There is one issue that seems to have surfaced, and this isn't my area of expertise, so hopefully I get this correct. Apparently the Medicaids are notorious for trying to send information about the other payer as far as their benefit determinations and what not, and it doesn't fit well into the 270, 271.
It is really a business issue in how they are using the transaction and needs to be clarified, I guess, in the implementation guide. We are lucky in that respect in that the co-chair and author of the implementation guide does work for us and can work through these issues.
The 278 referral transaction we have implemented in 4010. It is in production, by use by a large national payer for referrals. We do approximately 10,000 278 transactions per month and that is growing.
The electronic remittance advice, we are in production with that in the 4010. We do have to do some tweaking to it to get it up to the final version. We have found that there is the potential of losing data when you are going from 4010 to any lower version, so we won't implement going to providers who are on lower versions of the 835 if it is coming from the payer at 4010.
So, we are trying to get the providers to upgrade, so that there is no problem with the downward compatibility. As I indicated earlier, the other HIPAA transactions that we currently don't have in our portfolio, we will be working with our payers to determine what the business needs are and what the work flow should be. I thank you.
DR. COHN: Deborah, thank you very much. Don Bechtel?
MR. BECHTEL: Mr. Chairman and members of the committee, I am Don Bechtel. I am an advisory analyst responsible for strategic planning at Health Data Exchange. HDX is 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 member of AFEHCT, a board member of AFEHCT, the 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.
In the interests of time, I am going to skip over to the background of HDX. Beginning in 1987, as a direct response to customer requests to help our customers with issues stemming from the expansion of managed care in the health industry, SMS began a research and development effort to determine how the operational improvements of electronic data interchange, EDI, could be made broadly available to all 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 the then-prevalent indemnity care. The resulting increase in administrative costs threatened to consume the savings many felt would be obtained by managed care or managed competition.
To translate our research into operational experience, SMS established HDX in 1991 as an arm's length subsidiary to provide EDI services to all participants in the health industry, those being providers, payers and purchasers. As HDX nears its 10th year, we are now processing over 7.5 million transactions per month, 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 financial issues including eligibility, claims for institutional professional providers, claims for institutional pharmacies, admittance advice and referral notifications and authorizations. The current eligibility service operates in an on- line real time environment using the ANSI X12 270/271 transaction set.
We currently process millions of real-time eligibility transactions per month. Our eligibility services are integrated with our providers' information system, so that the eligibility inquiry transaction is generated as a byproduct of other business functions, those being admission, registration or scheduling.
The resulting eligibility response transactions can then be used to automatically update a patient's account information at the discretion of the clerk reviewing the response. Our remittance advice service is also available to any health plan that supports the 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 for Medicare.
Those rules were implemented several years ago and were very successful in providing more efficient processing of remittance information. By automating payment posting within the accounts receivable application using these transactions, our customers realized savings in clerical time required while posting payments. By having more efficient and accurate postings to accounts, secondary billing procedures can also be initiated sooner, thus improving cash flow.
These benefits encouraged HDX to broaden the use of this transaction to other payers, and we currently support several hundred payers and process more than a million remittance transactions each month. HDX additionally provides a service for authorizations, referrals and notifications using version 4010 of the X12 278 transaction, a service that is particularly useful in managed care organizations.
Like our eligibility service, our implementation of the 278 transaction utilizes on-line real time processing that occurs as a byproduct of existing information system functions, such as order entry for authorization requests and emergency room admissions for notifications to a managed health care 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 processing.
HDX has definitely been on the forefront of this service, but our experiences to date indicate improved and more accurate information flow is allowing savings not only on clerical staffing, but also reducing clinician, administrative involvement and patient waiting times. Claims transaction formats that we transmit today are mostly UB92 for institutional, NSF professional, and the NCPDP for pharmacy claims.
We currently process more than a million claims a month and, in anticipation of the release of the HIPAA transaction standards, we are currently developing an implementation of 4010 using the 837 for institutional and professional claims, and expect to have this introduction later this year.
Regarding 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, 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 applications 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 transaction standards into our clearinghouse business, by upgrading our existing transactions to version 4010 of the X12 transaction standards. SMS and HDX have been working with other 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 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 for SNIP, that is preparing recommendations for national implementation of HIPAA standard transactions. I will make more specific references to these efforts later in my statement.
The AFEHCT organization would like to make the white papers available to members of this committee, but would like to point out that these are draft documents and papers that are work in progress. You can ignore the statement that is in the paper. However, we believe that you should have these documents as you consider this work and these issues in the hearings today.
The white papers cover topics such as the implementation of HIPAA requirements for transactions and code sets, HIPAA testing and certification assumptions and work plan, business front end edits, model contract language and clauses, and HIPAA awareness building and communication plans.
I would like to review some of our conclusions from SMS and HDX' experiences in implementing these transactions. First, EDI can deliver substantial savings to the participants in the health care 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 implemented 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 also receive further business improvements from content standardization and the robust transaction formats that meet the business requirements of all organizations. One of the most important benefits of the HIPAA standardization is data content or standardization of the data content of these business transactions.
I know that this has been one of the issues of much debate this morning, but it is truly what is going to make this an effective process. So, it is really important that we find ways to solve these issues. I have several examples that I am not going to read to you that I will summarize quickly, customer testimonials, if you will, of how these services have helped them improve their business processing.
One example illustrates how work that used to take several weeks is now accomplished in several hours. Another example is illustrating that there is a tremendous increase in available cash and a tremendous decrease in accounts receivable days as a result of implementing eligibility and remittance services, as a byproduct of other applications. So, it is not just these transactions. It is these transactions working together with the applications that allow these types of savings.
We hear from of the Medicaid programs that this is improving their business by eliminating a large number of phone calls that they previously had to deal with on a manual basis, and that this is freeing their staff to work on other perhaps more important issues related to billing questions.
Another organization experienced tremendous improvements in cash flow and increased revenue, freeing of staff hours, and elimination of errors and improving reconciliation processes.
The bottom line is, these transactions work. They are efficient. They reduce the cost of business transactions. They reduce errors in data. They free people to do other more important work and providers will positively be affected in terms of return on investment because of these transaction standards and the efficiencies that they make possible.
Another observation is that we need to have more transactions as we move forward, one of those being external notifications of admission, transfer and discharge, a transaction that did not exist at the time the HIPAA legislation was drafted.
It is now available and could easily be quickly implemented. It is our recommendation that this function should be considered for the next round of transactions under administrative simplification. The ANSI 12X implementation guide for this function is complete and ready for adoption.
Work flow integration is 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. This is best accomplished by integrating the transactions into supporting applications that will use the data being exchanged.
For example, making the eligibility inquiry part of the registration of admission process allows the response to be captured and stored with the patient accounting record. This captured data can then be re-used to complete other business functions for the patient, for example, to determine whether authorization is required, or to execute authorization requests, or to capture authorization and certification numbers that must be submitted with the health insurance claim.
This approach is being done today by several SMS applications which utilizes HDX' services to request and receive information between 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 the integration, most of the benefits just described would not be realized.
Data translation issues require careful planning. Translation issues related to the transaction can 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 some code sets or data values between both business transactions, for example, claims and remittance advice or claim status, or authorization and a claim. If all 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 from many of the business transactions that are being done today, as we have heard from our last speaker.
This additional data is not always required. It will depend on the various business situations, but when these situations exist, the additional data must be added. These new required data elements must be collected by the business application and their user. I don't believe an EDI translator can do this function.
Translation issues exist for codes as well as for data content. For these code sets -- clinical and X12 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 or new to old formats via the translator.
Also, there are cases where data content of the new transaction would not have a place to exist on the older transaction format, or the data sizes on the older formats will not accommodate the new data requirements, thus, resulting in either lost data or truncated information. These concerns are being studied by WEDI and the SNIP project, and it is my expectation that recommendations will be made on how the industry might handle these issues during the implementation phase.
There are concerns related to stored data within many of the 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 the HIPAA data standards and code sets. Both administrative and clinical analysis efforts often look to trends over time, with rather large amounts of data and length of time important to many of these studies.
The current HIPAA approach has been focused on operational interfaces and data content, but there has been a potential for a tremendous disconnect in analysis and reporting capability of the coded historical values, and the identifiers cannot be accurately compared to the new standards. The number of statutory reporting requirements may also be affected by the inability to create accurate comparisons for historical reporting, if identifiers and code sets cannot be consistently compared and grouped.
The transactions should be phased in a logical sequence. The industry should define a logical order and timing for the implementation of all 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 become involved with the work being done by the AFECHT 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 data requirements.
Organizations such as NCHICA, who you will also be hearing testimony from, have put a lot of time and thought into developing their plans to implement these same components in North Carolina. This work should not be ignored, but it 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 -- payers, providers, purchasers, clearinghouses, vendors, states and others -- must work together to have an orderly and successful implementation of administrative simplification. Testing implementation time frames must be improved. Methods used today are time consuming and labor intensive.
Our current method of testing requires that we perform rigorous verification of 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 and received for multiple entities.
In these cases, the validation process is often repeated with one trading partner multiple times, once for each the submitting and receiving entities. Consequently, must work that is being validated has already been validated by other entities.
Similarly, this same testing is repeated with each trading partner, where validation has already been proven by another trading partner. Verification of the transaction format and content is necessary to ensure 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 the approach that we have been using, including our existing trading partners when we convert to these new EDI transactions, that we will be unable to complete the task in the time required to meet our deadlines. Our industry must find a way for trading partners to test and validate only once those features of the system that will not differ from one entity to another, regardless of who the entities are, who the trading partners are for whom the transactions are being submitted.
Then, through some sort of verification or certification process carried from one trading partner to another could assure each trading partner that certain implementation requirements are being met, thus, allowing trading partners to focus on their testing of those features that are unique to the trading partners, business connections or requirements. Simply said, we need to find a way to standardize our testing to reduce the implementation time frame.
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, the industry 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 each contract must spell out these requirements. This will introduce many hours of legal review and interpretation, extending the time needed to complete the 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 the requirement, assuming, of course, that the language satisfies the requirements of the final rules. Thank you for your patience.
DR. COHN: Thank you. Our next speaker will be John Carter. I actually just want to remind you all, what we are trying to do is keep everybody to about 15 minutes, so we will have some time to talk and discuss these things afterwards. So, all of your help is appreciated.
MR. BECHTEL: I apologize, but I was speaking for two organizations. I was speaking for AFEHCT and I was speaking for SMS. I apologize for not saying that up front.
MR. CARTER: My name is John Carter. I am with Healthcare Administration Technologies. I am also chairman of the Oklahoma State Uniform Billing Committee. I would like to open by thanking the committee for this opportunity to share some of our experiences related to HIPAA administrative simplification.
As you know from the introductions, I come from a clearinghouse background. I have worked in the clearinghouse industry for more than 13 years and have been involved in developing both institutional and professional EDI interfaces.
The electronic HCFA-1500 and UB-92 standard formats that are already in use today are both easy to understand and widely implemented. The proposed ruling allowing 24 months to convert the nation's health care EDI pipeline from one forma to another is an overwhelming task. The proposed standards are extremely complex and costly to implement. Like other X12 standards, many of the lists of valid values come from sets of codes used by other industries for other purposes.
Several X12 data elements have ambiguous and overlapping code values for the same concepts. Use or modification of codes for health care purposes may require the approval of another industry. This has already happened and cannot always be resolved.
A two-year implementation schedule may indeed rush several payers to clearinghouses for isolation from compliance issues. Once reliant upon a clearinghouse for translation, payers in particular may put at risk the vision of HIPAA by leaving legacy systems untouched and too far removed from the data reporting capabilities of the new standards.
We have been assisting facilities in the completion of HIPAA compliance questionnaires. They come from a variety of sources, but the questionnaires ask details about formats and EDI standards, which the providers do not understand. The catchall answer has been clearinghouse. Providers have also been asking us to include language in our contacts stating that we will maintain HIPAA compliances. This is difficult to address, since there isn't a consensus on what compliance is or will be.
The term compliance is also confused by its language in both HIPAA and the HCFA Correct Coding Initiative. The committee has already discussed issues regarding the local use codes. What we have been experiencing is variances in national code implementation.
For example, HCPC codes are updated each year and are valid January 1 through December 31. One state Medicaid program we work with implements the same national codes with valid effective dates July 1 through June 30. Similarly, this year, commercial payers implemented HCPC 2000 according to the national standard, while HCFA allowed the use of an overlapping 1999 and 2000 code set until April.
The reason for the exception is irrelevant. The point is, there have always been and will continue to be exceptions. Be it code sets or optional data segments, the X12 can allow payers to implement various interpretations while still maintaining adherence to the standard.
The flexibility of the X12 is magnificent and the complexities of the X12 make it a two-edged sword. Very few payers support the latest version of the 837. The payers that do support the 837 claim have few trading partners submitting data in that format. As long as it isn't required, we, like others, have opted not to use it.
Programmers can typically develop a payer interface in the current NSF or UB92 standard in less than six hours. The 837 equivalent of these formats has taken roughly four times that effort. The X12 formats are time consuming to read and difficult to modify. It isn't cost effective to spend time coding an X12 that is likely to require reprogramming once the final rule is published and payers begin to implement their interpretation of the standard.
This raises my final point on implementation. The entire process is payer driven. If the payers take 20 months to implement channels for receiving HIPAA compliant transactions, then the rest of the industry has only four months to comply. We are at the back of the line. Experience shows that payers appear to be in a wait-and-see mode right now. Until the final rule is published and the implementation guidelines released, there is little opportunity for early implementation.
Despite the obstacles I have outlined, I strongly support the X12 transaction formats as the standard for health care EDI. The sharp learning curve will level off an the flexibility of open standards will provide the interoperability pay off. The one issue, based on experiences so far, is that I believe a 24-month industry-wide implementation schedule is not realistic.
Rushing to implement a standard that will itself change to support the exceptions encountered along the way will risk the legitimate and obtainable goals of HIPAA. Payers should not be forced to toss out legacy systems, overhaul EDI methodologies or call on a clearinghouse. Ideally, payers would be given 24 months to convert 20 percent of their existing EDI transactions to the X12 formats.
Those payers not currently accepting EDI transactions would be required to implement X12 within 24 months. Even the small payers should be able to accomplish this. The payers with existing EDI channels should be allowed to support both standards while phasing out the old. Payers can decide for themselves the most cost-effective way to do this.
The goal, the industry as a whole should be given an additional 24 months to convert to the X12 formats. This would provide a more equitable amount of time for implementation among all trading partners, allow for a more stable implementation of the new standard and bring us as close as possible to 100 percent compliance in four years.
What I am talking about is building the foundation, payers preparing the foundation in the first two years, and the rest of the industry coming on in the next two years. The current plan, which is a three-year plan, when you add 12 months for the small payers, we are just saying a four-year plan should bring everybody, including the small payers, on a lot smoother. Thank you.
DR. COHN: Thank you. Tom Grove?
MR. GROVE: Thank you. Good afternoon, ladies and gentlemen of the committee, Mr. Chairman. It is my pleasure to be with you today. My name is Tom Grove and I am a management consultant with Superior Consultant Company of Southfield, Michigan, where I work with our HIPAA planning and strategy practice. You may be wondering what a consultant is doing here, speaking on a vendor panel.
One of the focuses of our HIPAA practice and, indeed, of our entire company is assisting e-commerce vendors in the health care space. Over the past year, we have had occasion to work with dozens of these small vendors as well as some of our traditional friends, the major HIS vendors. It is the perspective of those vendors that I am here to share today.
Two years ago, some of my colleagues and I were brainstorming about the internet and its role in the health care industry. At the time, very few hospitals even had web sites, let alone participated in any serious e-commerce ventures. If you might thought the need wasn't there, of course, you would be wrong. The need was there, just as it is today.
Three major obstacles were preventing the mass adoption of the internet as a central part of a health care business strategy.
First, there were very serious concerns about confidentiality of patient information. The internet wasn't designed with privacy in mind and no clear answer to protecting patients' information was available.
Second, serious concerns about placing mission- critical data on the internet, where malicious individuals could gain access to the computers, accessing or even changing data, or attacking the computers and denying services that are critical to health care operations.
Finally, a lack of standards -- or in some cases some lack of a clear winner between competing standards or versions of the same standard -- stood as a serious obstacle to the unfettered exchange of information that could provide the benefits we all know and want.
HIPAA, of course, provides solutions to all three of those major obstacles. By addressing security and privacy concerns and by providing standards for transmitting critical data, HIPAA has unlocked the gates, and internet solutions to long-standing health care problems have come flooding in, creating a whole new market sector with brand- new HIPAA concerns.
The e-health market has exploded in the last year. A recent report from Price Waterhouse Coopers put the number of health care services companies that received funding in the last two years at over 500.
Some additional research at the beginning of this year found another 150 companies just entering or about to enter this segment of the market.
Although many of the major market players in health are right now are consumer or supply chain oriented, and may not be very involved with the kinds of transactions and data that are related to HIPAA, that trend will be changing. A significant number of new companies are taking advantage of the application service provider model and will be providing clinical applications to hospitals.
This is a trend that is especially valuable to the smaller hospital, which may soon be able to have a full suite of health information systems, but without needing a full suite of computing hardware and a full complement of programmers to support it.
Another major segment of the market comprises companies focusing on health care as a target for security services, again, a direct result of HIPAA. The number of vendors now offering these specialized security applications to hospitals as a way for them to become HIPAA compliant is expanding at an astounding rate. Many of these applications combine some form of web-enabling technology with a full suite of audit and authentication tools.
A number of new companies have started offering public key infrastructure-related tools and services focused directly at the health care market. My own company, Superior, has recently formed ComTrust to offer PKI and risk management tools and services specifically to the health care industry.
All of this is very exciting, and it is certainly an exciting field to be working in right now, but when my colleagues and I work with these new firms and our more traditional friends, on getting their products tuned and ready to be HIPAA compliant, there are significant issues which arise.
Currently, there is much confusion about how to implement the security measures. Much of this confusion stems from the lack of technical specificity in security regulations. We certainly understand that this lack of specificity is deliberate and we understand that it was done that way to avoid locking the broad spectrum of implementers into a single model.
Many of the newer vendors do not appreciate these reasons, however, and most of them don't really understand how to make the decisions they need to make based on a risk analysis. I can see two options to relieve some of the confusion. One is for HHS to act like the IRS. No, it is not what you think, to issue non-punitive rulings on various situations posed by implementers.
Another perhaps more practical solution for HHS is to publish more examples of working acceptable solutions with the final regulations, or as a separate clarification to them The current examples, that were mostly targeted to small providers, were very helpful for that limited segment of the market. One related cause of the confusion is some outright misinformation that is circulating among the vendor community.
One vendor called to tell us that he recently learned he would be expected to keep all his servers locked inside a vault in order to meet the physical security demands of HIPAA. What is the root of the misinformation? In many cases, the mere volume of the regulations with their associated commentary discourages individuals from reading the complete text.
In addition, some vendors -- with whom we have spoken -- aren't fully conversant with the regulations because they sometimes find the regulations difficult to understand, and because they are trying to interpret the regulations without a clear understanding of the intent.
I would encourage HHS to be very forthright about the intent of the regulations, and the reasoning behind the choices, and to publish that intent as clearly as possible. If the regulations themselves are not the place for this clarification, please feel free to do so in a supplementary fashion, but we would certainly encourage your forthright attention to that.
The next problem, the regulations define data authentication to us as the corroboration that data has not been altered or destroyed in an unauthorized manner. They then go on to give examples of how this may be ensured, like use of a checksum, a message authentication code, or digital signature.
Some questions have arisen among my vendor friends over what will be sufficient to meet this requirement, particularly since the standard seems to apply both to transmitted or stored data. An audit trail, which is not mentioned in the examples, provides critical information about who might have altered stored data.
At the same time, a checksum, which is mentioned, does little to prove that stored data was not modified in an unauthorized manner, so long as the alterer uses the authorized application that will update the checksum at the time of the data change.
More clarity on how to apply this regulation to transmitted vs. stored data would be of great benefit. One area of particular interest to many of our clients, particularly those developing browser-based products, is open networks and encryption standards.
There have been many questions raised about what qualifies as an open network and even more questions about how to go about providing the answers. My colleagues and I are certain that what constitutes acceptable protection will change over time, as computers get faster and current encryption standards become more vulnerable.
I know that some separate guidelines have been published by HCFA defining what constitutes acceptable encryption for them. Our clients are clamoring for more clarification, and more examples of what will be required. One major HIS vendor tells me that because their company has a single product line, the implementation calendar does not represent a problem. For many others, however, the implementation calendar issues are less clear.
Causing some concern among many of my vendor contacts are issues such as the mechanics of implementing various parts of the transaction standards, and in what order, so much concern, that WEDI has formed a working group to address this issue and produce a strategic national implementation plan, which we have already heard about today. This plan views the implementation of HIPAA requirements as nothing less than a fundamental restructuring of the business of health care information technology.
The underlying belief is that two years is not a lot of time to do something as big as this, and that coordination must be the name of the game. Other vendors, however, have suggested that the rules be amended to call for compliance on all parts of the regulations together on one specific date.
I realize that this may be beyond what you are willing to recommend, but keep this in mind, particularly if we begin to discuss deadline delays, as it certainly represents one solution to the problem of how to implement various where the different transaction sets interact with one another.
One thing that my vendor colleagues all will agree on, customers are calling, asking about compliant versions of software. The continuing delays in publication of the final regulations are very frustrating to them. While we appreciate the volume of work to be done, and understand that a rough timetable for the release of all of the information has already been proposed, we encourage you to support as rapid publication as possible of the remaining rules.
There is absolute confusion about business partner agreements, as required by the privacy standards and chain- of-trust agreements, as required by the security standards. The security standards say very little about what these agreements entail, except that the intent is that the same level of security will be maintained as data is transmitted and re-transmitted among business partners.
They don't even define business partner. In contrast, the privacy standards say quite a lot about the restrictions that are in force and who is responsible for meeting them. My lawyer friends tell me that in legal terms, when something is described in two different ways in regulations, it is because it means two different things.
If there is a distinction between what the two agreements require, it is unclear. If there is no distinction, that fact is equally unclear. Part of the lack of clarity here undoubtedly relates to the limitations of the law on who the HIPAA standards can apply to. The rest probably stems from the recommendations coming from different sources at different times.
In any case, we urge two resolutions to this issue. First, combine the two agreement types into one, with one standard of compliance. Second, urge Congress to amend the original legislation to give you the direct power you need to address all your business partner concerns, instead of needing to construct the contractual web of these agreements to make it happen.
A final privacy question I get repeatedly from start-up internet vendors concerns de-identified information. There is much concern about how to go about de- identifying data, since it is getting easier to re-identify data, particularly involving patients with uncommon conditions.
Similarly, some of the de-identification discussed in the regulations may destroy the usability of the data. The reason for all these questions, of course, relates to the potential commercial value of the resulting data sets, an area that, in itself, raises some interesting questions. I urge the committee to recommend clarification of the de-identification of data and the allowable uses of the resultant data set.
In closing, I would like to thank the committee, both for inviting me here today and for their leadership in driving the HIPAA process. I sincerely hope that the information my fellow panel members and I provide today is of great assistance n shaping the direction of great things to come. Thank you.
DR. COHN: Thank you. David Sweigert from Open Network Technologies.
MR. SWEIGERT: I have to really compliment the people who made the seating arrangements. It seems that the people who are right at the people are X12 EDI experts and the people to the left of the projector are the internet guys. So, I am sitting over here today on the internet side.
You know, before I get started, I wanted to thank a couple of people who made my appearance here possible. Gary Anderson from In-Trust Technologies is here. He works closely with Dr. Lumpkin, the chairman of NCVHS, in Illinois on some issues, and I think he was instrumental in getting me here, so I wanted to recognize him.
At the outset, let me introduce myself. My name is David Sweigert. I work with a corporation called Open Network Technologies in Clearwater, Florida. I would like to thank the committee for this opportunity to present lessons we have learned from assisting our customers and preparing for the implementation of the HIPAA final security rule, and that is mainly our focus.
Within the last six months, our firm has enabled nearly 12 organizations within the Blue Cross Blue Shield Association of Plans implement a myriad of security services that we anticipate could accommodate many of the security requirements in the future release of the HIPAA final rule on security.
The first point I would like to make is that the business needs are driving modernization in many of these plans, not necessarily the attention to HIPAA. What do I mean by that? We have found that information technology managers at most Blue Cross Blue Shield plans have ranked internet applications and internet security as the two technology issues that are most important to them.
These issues have pushed these IT managers to implement incremental roll out of internet-based services to their constituency. The constituency would be providers, insurers, administrators, et cetera. These IT managers want to provide relevant access to information for their constituency. At the same time, they are very concerned about the upcoming HIPAA security regulation.
Just as an aside, we want to credit Blue Cross Blue Shield Association. They are having a HIPAA implementation team conference in Denver, Colorado July 25- 27 to address many of these issues that I am going to be discussing today related to HIPAA and security. Such acts of leadership by the association are very welcome by us as a vendor in the association plans.
The organizations that are envisioning the use of the internet from a Blue Cross Blue Shield perspective are many fold, registering new insurers, verifying the eligibility of claimants and even for the submission of claims, they don't want to put these projects on hold while they are waiting to see what the final impact of the proposed HIPAA security rules will be in the final rule.
Rather, they believe -- and we institutionally agree -- that it is better to move ahead with an incremental roll out of their new applications while monitoring HIPAA- related security news and developments. In this sense, the industry is becoming weary of the on-again, off-again nature of the release of these rules.
As an example, current rumor is circulating that the digital signature guidelines will be dropped altogether from the HIPAA implementing rules. However, another rumor is circulating that the digital signature guidelines will, indeed, be released possibly in November 2000, attached to another rule, not necessarily the security rule, et cetera, et cetera, et cetera.
Industry associations and work groups help with building awareness of the new rule releases. To their credit, the Work Group for Electronic Data Interchange -- WEDI -- has commenced a strategic national implementation process initiative for members, and also will be hosting a related security summit in Chicago, Illinois on August 22. Of course, we applaud these kinds of efforts to build awareness.
These efforts are great steps toward helping the vendor community. However, as with Y2K issues, a recently- designated private officer, or HIPAA compliance officer, needs to spend a lot of time and effort to get up to speed on the complexities of HIPAA.
An organization's HIPAA guru has many tasks at hand. Some of them are outlined here. Number one, seeking senior management buy in. We see a lot of that as far as awareness at the senior levels. Number two, building an organizational awareness, no small task. Number three, setting up an organizational education program.
Fourth, putting system vendors on alert that HIPAA compliance will require vendor initiatives. Now, another important point it that market drivers are currently overshadowing HIPAA compliance. What do I mean by that?
A key business driver of many of our customers is to take advantage of the cost savings that internet technology brings to their constituent of users. The cost savings of internet technology is significant. Technologies like the web can increase interaction between a health insurance payer and the insured or providers.
Increasing the frequency of relevant communications between the insurance payer and the insured or provider is the goal. That is the business driver. Doing this in a manner that complies with HIPAA is a secondary, and we believe it is an achievable, goal.
However, this is not to say that these organizations have lost sight of the interest of confidentiality and privacy when implementing an internet application that may be covered by HIPAA. These organizations' desire is to satisfy primarily consumer concerns that information that is sensitive and confidential will be protected, regardless of the future HIPAA standards. This is a consumer-driven demand.
Some industry surveys have reported that each time an individual handles a paper-based insurance claim, the insurance provider may incur an expense as high as $7. One can see that handling of one insurance claim could cost an insurance provider perhaps $50, $60 per claim transaction and difficult claim circumstance. This expensive approach is contrasted sharply with some statistics that report the average EDI or internet- based web transaction may cost the insurance company a few cents. Now, that is an order of magnitude savings.
Now, there are some drawbacks. The internet is a public network and a playground for hackers and malicious web site attackers, et cetera. Consumers are mindful of news reports of hacked internet sites. They want and demand prudent security of such sites that provide convenient access to their medical- related data.
Achieving these goals is confounded by the fact that many information technology organizations within the health benefit administration or claims processing sector lack a sophisticated talent pool of individuals with proposed security standard knowledge and, additional, knowledge of emerging internet technologies.
The HIPAA proposed security regulation is voluminous and complex and difficult for many organizational staffs to understand and comprehend the full impact on their operations.
Additionally, many of these organizations have considerable main frame computer assets and data base systems that are not compatible with emerging internet networking technology and lack some skills in accomplishing this as well. These organizations seem to have a common problem that could be restated in this manner. How can confidential information be moved to the web and remain within HIPAA compliance.
Point number three, attempts to answer this. Vendors need to clearly map their products to the HIPAA regulations to enable IT managers to understand what solutions are being offered and, really, what those solutions provide. As stated above, these organizational HIPAA gurus need to put their vendors on notice that HIPAA compliance will be mandated upon their software solutions of what they are providing. Vendors should begin to map, as we have done, their software solution set to HIPAA regulations, especially in the case of security.
Now, by assembling individuals familiar within an organization of, one, HIPAA regulatory requirements and, two, the emerging internet technologies, Open Network Technologies, my company, has engineered solutions that provide many Blue Cross and Blue Shield plans with the tools that drive business and cross-cutting internet technologies.
Open Network Technologies has experienced much success in this area of addressing the needs of Blue Cross Blue Shield plans, by mapping our product features and benefits to proposed HIPAA security regulations. In this manner, customers understand the requirements under HIPAA and what regulatory relief a vendor's product may provide, while proceeding ahead with their business needs-driven applications.
With this approach, management, operational and technical personnel can all be provided a standardized baseline of information that includes HIPAA security requirements and technology that meets the present business requirements. In this manner, representatives from these communities within an organization can all understand HIPAA impacts and planned application roll-outs, i.e., making decisions regarding the cost of identification, authentication of users, privileged management of users, access control, et cetera.
These organizations have all stated to us their concern to be fully HIPAA compliant. Most have appointed specific compliance officers. Their legal departments of these organizations have also been active in reviewing planned IT applications for HIPAA compliance issues.
We work closely with these dedicated professionals. However, it is not clear what the final HIPAA regulations will look like. In a sense, we are operating with an idea of what we think HIPAA might eventually look like. The general consensus is that HIPAA-covered information must be protected, not matter how the final regulations look.
In summary, I would like to address the clarity in presenting key areas of the proposed regulation and how a vendor can map their software solutions to meet that. That is basically what we see to be the most successful thing.
We encourage all vendors, especially in the new areas of internet technology, to be able to propose how their solutions and customer sets benefit the customer and how they related to the HIPAA proposed regulations and the proposed final rule. A couple of areas to address just briefly, number one, access control. Enterprises are faced with the problem of providing governed access control services.
The solution to this problem needs to encompass a means of defining the users and services ahead of time, a means of associating users with services as a way of explicitly granting access to those services, a mean of identifying the users at run time, a mean of enforcing access to requested resources at run time based on identity. We have identified such solutions within our particular product set.
Number two, role-based access control, initial issues to be addressed by the organization that wants to support the HIPAA security regulation and RBAC, number one. Who owns and administers the information and how many users need to get to it. Such information, location sensitive, who can modify the information.
Does the information need to be replicated for the service level it is anticipated for, or does the information need to be replicated for redundancy and archive purposes, et cetera, et cetera.
We have engineered an RBAC solution that helps organizations accomplish these requirements as well. Authentication, we have engineered product feature sets that allow selective assets to different portions of a record.
For example, administrative personnel get access to only certain fields and medical personnel get access to other fields. Now, this is an area of study that was commonly known as privileged management infrastructure. That is what we hear it commonly referred to.
Mapping it, of course, would require noticing that this is what the proposed security regulation has on authentication in the November 3, 1999 publishing of the Federal Register. You see the 64 volume, page 599-18 and 599-44.
Lastly, comprehensive security. A unified enterprise needs to have the ability to provide inter- connecting, cooperative data bases that interact with clients and among themselves to provide a unified privileged management infrastructure.
Motivation for a centralized PMI is the cost savings obtained by having a centralized privilege manager to control access to various resources. This concept promotes a unified security approach that can control access to many different data bases and many different repositories.
One last idea on how we are viewing the chain of trust agreement problem. Management has the difficulty -- and chief information officers are being hit by this -- how do you effectively manage potentially hundreds of trust relationships within the B-to-B business model.
Not only must chain of trust agreements be in writing, but these agreements must be maintained and enforced by covered entities. We are currently exploring methods and procedures that such agreements could be managed and enforced by software. That is still under feasibility analysis for us right now.
In summary, most organizations that we work with see HIPAA as an overdue necessity to upgrade existing infrastructure and resources. We have attempted to meld software engineering expertise with state-of-the-art internet-based technologies -- software and protocols -- with familiarity with the regulatory constraints mandated by HIPAA to provide relevant software solutions. I really would like to thank the committee for allowing us to present these ideas, and I appreciate all the other panelists and thank you very much.
DR. COHN: Okay, I want to thank the panel. We have, I think, about 15 minutes for questions. I was going to ask, before we move into the questions, that maybe Dr. Braithwaite will just answer your question about digital signatures, since you brought that up as a substantive issue. Do you want to address the security standard on that?
DR. BRAITHWAITE: Of course, the final rule is still in formulation. It is our sense at the moment that, since HIPAA requires us to adopt industry consensus standards where they exist, and we look around for an industry consensus standard for electronic signatures in health care, we don't find one.
It is unlikely that one will exist before we issue the final security rule. In that likelihood, we will actually be hearing hearings on that topic in October.
DR. COHN: Do we have any questions from the panel? Kepa, would you like to lead?
DR. ZUBELDIA: Just one question, and I want to thank the whole panel, because we have not only an excellent panel, but also different points of view. My question, I would like to address it to both groups, but separate. The question is simple. Why wait.
We have, in this group, in the transaction group, from one end that says we are doing it now, we started doing this in 1999 when the guides were still preliminary guides, we are doing it, things are still changing but we are still doing it and we are learning from it, to John that said, this is not enough. We are waiting for the final rules. We need more time because we are not going to have time in two years.
Let me remind everybody that HIPAA was required to have implementation guides in 1998 and we should have been in compliance in what, in a month? August of 2000 should have been the compliance date. I think we have had the two-year extension already. The same thing on security.
The Blue Cross Blue Shield Association is doing a lot of things and you are saying that it is driven by the business needs, not necessarily by HIPAA but by the business needs. Is there a reason to wait for HIPAA to start doing this or should everybody be doing it already?
MR. CARTER: My point was -- you are right, we have coded ANSI standard formats for different transactions.
The 835 has been used widely by Medicare and has become stable. The 835 came out in, what, 1991, and it has only been in the last two years, from our experience, that we have seen some of the large hospital management system vendors actually providing a module that can cleanly post the 835. It took them eight years, practically, to produce something of value that they didn't also bundle with some megasystem upgrade that the provider had to buy, the hospital had to buy.
It wasn't just a module. They had to move a complete system conversion to be able to get this one module to be able to make use of this technology. Yes, we want the same two years that you had to put it together. My point was, as payers have waited for the final rule to put out the price tag to develop this, that has made everybody else wait.
Payers, some here and there, have provided capability for 837. I can tell you one payer in particular in the state of Oklahoma that has absolutely no support for any ANSI standard formats of any kind. A payer in Arkansas supports an 837 claim but has only three trading partners using it. As they have waited, the rest of us had to wait, too, because there was no channel open.
When they do open the channel, they will open it with their interpretation that we have to code to. I am just saying that the two years allows for the building of a foundation and then two years for successfully building on top of that foundation. Much like HCFA and their future date testing with Y2K, they required the fiscal intermediaries to perform future date tests with a certain percentage of their providers, and the payers were required to do that.
What we are saying is that the payers should be required to take a certain percentage of their transactions and convert them over to the HIPAA compliant transaction set. Once they have proven that, then the rest of the industry can come on without having to stumble over their learning curve.
DR. COHN: Other questions on this particular issue?
MR. SWEIGERT: Just a quick follow up. I think the real opportunity is that there is unbridled growth right now on web sites being thrown up together.
If the Federal Trade Commission can monitor web sites for consumer protection laws about, you know, deals being made and crack down and file lawsuits and all that, you know, the health information or confidentiality right now on an internet web site is just a free for all.
I think a real opportunity is, when the HIPAA security regulations come out, building the awareness that, even though these web sites may not necessarily fall underneath HIPAA because they are not handling EDI transaction sets, for instance, but you know, the patient confidential information is there and there needs to be a sensitivity that there is some federal regulation over this.
I think that is the opportunity for the HIPAA security regulation, is the awareness building. Some of these internet entrepreneurs aren't paying any attention to this at all. They are just gathering money and they are going out and doing things.
We think that is a very dangerous practice and somehow it needs to be regulated.
MR. GROVE: I certainly don't think that I am necessarily advocating major delays in anything. My perspective was purely that, given the difficulties of implementing different transaction sets at different times in the development process, or implementing different identifiers at different times as their rules become final, the difficulties for both the payer and, for that matter, a provider who now has a bunch of interlinked information systems, with programs passing data back and forth between them, updating those interfaces at different times as updates become available and then updating both the applications and changing the interfaces between them each time a new segment needs to come on line, could prove to be rather messy.
I don't know that I am suggesting long term delay on the schedule so much as bringing everything up to the last date at one time, to make the implementation cut over that happens all at once, rather than a bunch of piecemeal implementations.
MS. MEISNER: The approach that we have taken on this, I think, is a reasonable approach, in that you can do the transaction set if you understand that the data content is not going to be available to everybody. If you can, as a payer -- which by the way, we have both sides of the spectrum coming in to us as a clearinghouse -- the payers are definitely coming on board much quicker than the vendors and the providers. The impact is probably not as great, because they will take the information that they need to adjudicate, where in order to do a HIPAA-compliant transaction, the providers are faced with the issue of providing that data.
I think if people can implement the transactions, the X12 transactions, in an X12 mode, and not look to be HIPAA compliant right away until the end of the migration period, then it can work. I think it is the data content that is going to be the issue. If you can roll that out a little at a time and get people to become HIPAA compliant in the data content over the migration period, the format that they use is really not that important.
MR. BECHTEL: Actually, you have said precisely where I was going to go, except that I would say the experience has been finding payers that are willing to do the transactions has been more our issue than finding other providers. Then, we also enable the providers, so that may make it a little easier.
I agree, there are two aspects to this. There is the aspect of implementing the transaction and then there is the aspect of being compliant with data content codes and so on, the identifiers. It is that second piece that we have to wait for, before we can really begin to implement.
We have been doing X12 transactions for years. Getting to 4010, in some cases, we are already there and in other cases, we are on our way. That is not so much the issue as data content and finding willing and ready trading partners.
MR. BLAIR: We have folks listening in on the internet, and I just wanted to make sure terms were correct here. It is my understanding that the proper name is ASCX12N, which is accredited standards committee X12N. I thought I heard a few references to it as being ANSI.
ANSI is the accrediting agency, but ANSI accredits many different standards organizations and standards, including the HL7, ASTM, in addition to X12. Somebody correct me if I am not stating this correctly. I think this is of use to the folks listening to us on the internet.
MR. SCANLON: I wonder if we could ask the panel a sort of overall readiness question. All of you know the different entities that will be subject to comply with the HIPAA transactions and securities regulations. In your estimation, if you looked at the institutional providers, the individual providers, the labs, the pharmacies, clearinghouses and so on, who do you have a sense as sort of further along than others in readiness and capability to comply versus others that are less ready. Do you have any ideas about what sort of efforts might be needed to inform the group and help them along.
Mr. CARVER: From my standpoint, it appears the clearinghouses, because that is our business, are probably the most prepared right now and have tracked it the most.
Second would be some of the larger, more innovative payers. I mean, there are definitely payers, like I have mentioned, that just haven't touched it, anything. There are payers that have been implementing even the 837 in some of its earliest versions. So, I would say that payers are second and institutional providers are probably coming on.
There is a very big difference between the institutional and the professional claim. I mean, the institutional is a summary bill still. The extended claim is kind of migrating away from that, but the institutional bill is a summary claim. It is very different to go right from their main frame system down to the summary bill and then to the standard transaction.
DR. COHN: Other comments?
MR. BECHTEL: I would concur with what was just said.
MS. MEISNER: I agree.
DR. ZUBELDIA: Jim, one comment that I would like to make is the pharmacies are already there. It is 100 percent compliance today. We are talking about the rest of the industry.
MR. SCANLON: Just one follow up. The professional providers, individual providers as opposed to the institutional providers, do you think that may be the group that is least aware and ready?
MS. MEISNER: I think that is going to be left up to the practice management systems. A lot of the information that they will need to provide is going to have to be added to those PMS systems. Just to follow up on what Kepa was saying, I think most of these comments, at least that I have been making, have been related to the claim.
The eligibility transaction, the 278 transaction, anybody that is implementing that, is implementing that in the X12 standards, from our perspective. There is not too much proprietary going on in those transaction sets. Migrating from the versions of X12 that they were using to the 4010 has not shown that to be that big of a deal.
DR. COHN: I just wanted to ask a question just to sort of follow up on this. I think as I am listening to all of you, the area that I find the biggest concern in terms of being able to do all of this is actually I think it is something Deborah has alluded to a couple of times, which could probably be said nicely as the paper-to-print image, electronic transaction -- primarily the professional encounter submission. I was reminded there is obviously a fairly significant disparity between the HCFA 1500 form and what we are asking for in the ANSI 837.
There was a discussion a while ago about modifying the 1500, which seemed to have not a lot of interest. My timing may have been wrong on his. How are we going to handle this? We have people who are printing things on paper, sending them to practice management companies for final formatting, coding them electronically to send off to people, and what is going to happen?
MS. MEISNER: A lot of the additional information today is not available on the print form that is required in some of the electronic formats. It is kept in profiles, provider information. There are various identification numbers, their addresses, their specialty or taxonomy codes. Those things don't necessarily have to be on the print image as long as they are available in the practice management systems, or their print image grabber, whatever they are using. So, some of the information will not need to be on the claim form itself, but will need to be in the practice management systems. Some of it will have to be on the claim forms. I believe SNIP is looking into that.
MR. CARVER : I agree with that. Most of the data to make the claim payable is there already. We are just talking about putting it in a different format. A lot of that data we have dealt with on the managed care side. A managed care contract may require information that is not a UB92, and our system, it is the same kind of a thing. We can grab an itemized bill and pick up that information.
DR. COHN: Larry Watkins, who is with SNIP, among other things, is in the audience. I thought he might just want to make a comment on this before we move to the next question.
MR. WATKINS: Yes, other things is exactly right. Actually, it is not SNIP that has taken up the print image issue. It is AFEHCT that has taken that up. SNIP is under WEDI.
We have got a group called ASPIRE within AFEHCT. It stands for Administrative Simplification Print Image Research Effort. We came up with the acronym before the words. So, ASPIRE is about looking at exactly what ENVOY has mentioned a couple of times here today, and that is that there is a disparity between the print image, which is what generates many of the electronic claims. More than most folks realize, of the claims that go through clearinghouses particularly, they are generated initially from a print image. The question is, how do we fill those gaps in.
Our question in ASPIRE is really, well, the fact is the HCFA 1500 and the UB92 paper form don't have all the information that is on the flat files that are in use today, such as the NSF and the UB92. So, we are already filling a lot of these gaps. So, how is that getting done. So, this is not just a mental exercise. We are actually going through the actual process. We have vendors taking what we are calling our kit, our ASPIRE kit, and filling out and answering the questions for each element where gaps exist.
They are going through and telling us how they are filling those gaps today for their implementation. In some cases, that will be to 4010, but in some cases, it will be to the NSF, and that is okay. We just need to find out how it is occurring today and whether that is appropriate under HIPAA, given some of the requirements in terms of passing on the full data set.
I think the key issue is that the full data set is passed, not necessarily that it is all passed at the same time.
So, that is where we are. We are very early in the process. There are very few 4010 implementers today, and obviously a higher priority right now is implementing for HIPAA than implementing for this project. Things are moving like molasses right now, but we are making progress and we would certainly invite your participation.
DR. COHN: Thank you very much. I think we have time for one more question -- one more question and one comment, Jeff and then Bill Braithwaite.
MR. BLAIR: I have a little bit more involvement in the provider community than the payer clearinghouse community.
While it was very clear that compliance or focus on implementing the financial administrative transactions for HIPAA really took a back seat during 1999 as many provider institutions were focused on containing or reducing their risk for Y2K, beginning with this year, when I look at the trade magazines, when I attend the conferences, when I wind up seeing the seminars, there seems to be equally atop the list with e health and internet is getting ready for HIPAA.
Many trade articles wind up saying it is equal to or even greater than the focus that is needed on reducing the risk for Y2k. I am delighted that the payers and the clearinghouses have taken the lead in implementing these transaction standards.
The question that I have is, while you may be in the lead in implementing these, do you not see the attention in the provider community coming on board pretty quickly, their awareness and their intent to comply coming on during the next several months or the rest of this year?
MR. GROVE: That attention is certainly there, there is no question about that. I spent a lot of my time working with provider organizations of various sizes. That attention is definitely there.
As sort of the conclusion to your question of earlier, do you want to know where the providers are. They are somewhere behind the vendors. The reality is that a lot of them recognize that most of their compliance issues, specifically related to transactions, is dependent on the vendor to provide them with software.
Some of them have major, major efforts, once the vendor gets the client software, to get compliant interfaces between systems and so on and so forth. There is no doubt about it that they are a step behind the vendors in waiting for those answers. The awareness is becoming. The preparedness isn't there quite yet.
DR. BLAIR: Any other folks who have an observation on the readiness or vendors or providers?
MR. BECHTEL: I think from the vendor perspective, we are working very hard to be ready. I noted in my comments, we have some of these already operational, including some of the security requirements. We are very close to rolling out even more. So, readiness from the provider vendor perspective, I think, is moving along quite well. You are absolutely right in the comment that the providers themselves need the vendors to get there. So, that is true.
DR. BRAITHWAITE: I was just noticing, there seems to be a bit of conflict in a couple of the testimonies about the success of X12's attempt to make the 4010 implementation guides written in such a way that there weren't a lot of choices.
If a pair of trading partners got things going, it would not take any effort at all to hook up another trading partner, because the standards are now specific enough to make one compliant transaction work with all trading partners who wanted to connect using that. I heard some differences here. I wonder if we could get some comments on that.
MS. MEISNER: I think they came a long way.
DR. BRAITHWAITE: But not quite?
MS. MEISNER: Before implementation guides, there was definitely a lot of ambiguity in how you could use the guide. There are still some holes that need to be filled. Again, there was a lot of work for that group to do, and I think they did a tremendous job.
As we started going through it and trying to implement it, there are still some holes that need to be covered. The phone number incident that I cited for you was particularly one of them. There are also some reference numbers that they needed to go back and put the semantic notes in there to say what the intent of the use is.
It is more in just adding some semantic notes so that there is no guesswork. Unfortunately, I think one of the things that did happen is there are two places for keeping a lot of the information, either at the claim level or at the service line level. That is going to add a lot of overhead to storage, and I don't know that it was necessary. But we have got it, we have got to live with it.
DR. BRAITHWAITE: Are you comfortable with the X12 process for making corrections in those implementation guides? Are those things going to be fixed?
MS. MEISNER: Yes and no. Yes, you can go and you can present -- which we did in June -- here are some of our issues trying to implement this. No, if you don't happen to be there at the time to argue your other side of the story -- I have seen that happen several times where I went in and asked for something that our payers absolutely need.
It was voted in and it was there and the next meeting it was gone. So, either conversations, phone conversations or you don't happen to be at the next meeting or you had to go to a different meeting while you were there, and it gets voted back out again. So, hopefully with the finalization and the final guides put out where no one can change them, they will prevent some of that.
MR. BECHTEL: I pretty much agree with what was just said. I think where we have some disparity is in the area of situational fields. The situational fields that are in the guide do not always give good guidance as to what the situation is that you are trying to allow for, or how you are going to code the transaction under what circumstances.
I think that is where I am seeing a lot of different interpretations of what is meant or what is intended. I do believe that there is a process at X12 that will allow us to make this better. We are fine-tuning that process through the implementation guide task group.
I think one of the other issues we have is consistency between the transactions, that we are doing things in the same way for each transaction. I think there are some areas for improvement. Again, I think we are beginning now to take a much closer look at that. We are doing a lot of modeling. I think the opportunity is there to make it better and we are all working to that end.
DR. COHN: So, in summary, that effort has been a qualified success and there is some process in place to refine it to a better result?
MS. MEISNER: There is more work to be done.
MR. BECHTEL: More work to be done and there is a process in place to work on it.
DR. COHN: Kepa has a question and then Richard Landen had wanted to respond to an issue that was just brought up and then we take a break for 10 minutes.
DR. ZUBELDIA: Since we have a couple of the transaction experts here, I would like to ask, what is the situation with local codes and the transactions. Could the K3 segment -- and tell us a little bit about what that is -- could that be used to take care of the local code issues we heard this morning?
MS. MEISNER: I think it could. I think if each of the code sets -- the CPT-4, the ICD-9 code sets -- had one code that just said, I am using a local code, and then they could look at the K-3 segment, which has been defined in all the transactions as used for state and local use, the person receiving that transaction could certainly look to the K-3 segment for the code that they wanted to use, if it was understood that that was going to be a temporary use. Then that code would be identified in the national set as soon as possible. Each of the transaction sets does have a K-3 segment in it.
MR. CARVER: I agree with that. There are things in the X12 that include code sets that are mutually defined between trading partners.
I haven't seen content so much as an issue as format in the X12s.
DR. COHN: I think Richard just wanted to make a comment, I believe.
MR. LANDEN: I am Richard Landen and I am commenting wearing my X12N health care task group co-chair hat, to Dr. Braithwaite's question.
I just wanted to point out that X12 process, prior to HIPAA, was very different. X12 did not do implementation guides. This is something brand new to health care in X12. So, this is our first attempt at it. I think we have done a real good job so far.
We have had three major iterations of cleaning up the guides but you are right, they are not there yet. Prior to HIPAA, X12's policy was that the industries would voluntarily get together outside of X12 and develop their own implementation guides.
MR. CARVER: I would like to add one more thing. The accreditation that I have seen is looking at, or proposing, the possibility of being able to submit an X12 test for accreditation or 837 and have it balance against their standard for being an acceptable transaction set.
I would submit that possibly if there was the same thing for payers, to be able to take the same kind of a file from an accreditation committee and say, your system should be able to read this file, this is the bench mark.
DR. COHN: Okay, with this, I actually want to really thank the panel. The good and bad news is that we are 15 minutes late. The good news is that we are only 15 minutes late.
We will take a break for 15 minutes and reconvene at 3:30.
[Brief recess.]
DR. COHN: This is the last panel of the day. The focus of the panel is on the provider perspective on implementation and early implementation issues. We are going to start with Rita Aikins from Providence Health Systems in Oregon. Rita, would you like to begin?
MS. AIKINS: Thank you. My name is Rita Aikins and I am the information privacy security officer for the Providence Health System, Oregon Region. You have a handout that talks about Providence as an early implementer. You can read our statistics that I applied there.
I think the first point that Providence would like to make is that we do believe that the standards are reasonable. As far as the transaction standards, the medical code sets and the identifiers, those all have very specific requirements. We believe that the implementation and the compliance around those standards are adequately defined from our perspective as a provider.
When we talk about the security standard, because it is scalable and it is technology neutral, it is going to require that each provider develop, document, implement and maintain appropriate security measures to meet business requirements. Each provider is going to have to have a process to be able to assess risks and devise the appropriate mitigation for identified threats to health care information.
I think that is where, from a provider perspective, it starts to get a little messy, because I think some providers are not real sure about how to go about doing that. I would like to talk a little bit about our experience with HIPAA and what we have done so far to comply with the standards, even though the final rules are not published. These are some things that we are doing.
First of all we believe that you must have a complete asset inventory of all applications, interfaces, data bases and hardware. We feel that you need that for several reasons. One, you are going to need it for vendor communications. You need it for partner communication. You need it for risk assessment, compliance, surveys, et cetera. So, you really need a provider needs to know what they have operational within their organization.
Secondly, we have gone ahead and developed a risk management methodology to identify and assess risk, to identify and accept the mitigation for risk, and maintain an acceptable level of risk. The methodology we are using we developed ourselves. It took us about six months to develop this methodology and put it in place. We will be using it across the entire Oregon region, and we believe that this assessment is definitely a requirement for compliance.
If you were to look in detail at our risk assessment, what we have done is, we have developed a process which will evaluate organizational and departmental practices against the standard, which will then give us kind of a gap analysis. So, we are looking at our business practices, comparing those back to the regs and seeing what kind of falls out in the middle.
We are also using some compliance surveys as part of the risk assessment. Again, to do the compliance survey, you really need to know your applications, your interfaces, et cetera, that are operating within your organization. All the information from the risk assessment is being loaded into a data base, and then we will use that for analysis and reporting purposes.
Because we are an early implementer, we are taking the opportunity with the risk assessments to go back and change business practices and really make this more than saying we are doing this because HIPAA requires it. We want to do it to better our business practices. I believe that the cost of HIPAA really cannot be truly spoken to until a provider has gone through and looked at their risk assessment.
Until you do that, you really don't know where you stand as an organization. So, when we are continuously being asked, well, what is it going to cost, there is just no way until you. What it is going to cost for me is going to be different than what it is going to cost for other organizations.
You know, I think, speaking directly to the security standards, that standard really requires an organization to look internally at themselves. I mean, that is how it has been developed. From Providence's standpoint, we think that is good. We don't want government telling us how to do business.
Just to send a couple more minutes on the security standard, because its primary focus is on administrative processes, we have gone through and identified the policies, procedures and processes that we believe we need to be compliant, and we have identified 70 so far.
Now, we did that by basically taking the security rule and then reading that in detail and then applying that back to current Providence security practices.
From that, we were able to come up with a list that I call the three Ps, that we feel, again, that we are going to need to be compliant.
One thing that this did, it motivated us to review our process for the identification, development and the approval of policies.
We are taking existing policies that are either in a service level or in departments, and any policy we feel we need to be compliant with the security standard is being pulled out and moved to an Oregon region level. So, we will have one set of policies that speaks to the health record and then everything, the disposal and everything around that. Some of the policies we already had in place, but we still needed to redo them from a regional point of view.
I have to say that policy development and approval is a very, very slow process for large health care providers, because you have a very large audience that you need to have buy-in from and that need to be part of that approval process. From our perspective, we feel that we have gained value from the asset inventory, from the risk management methodology and assessment that we are going through, and from the development of the Oregon regional policies.
I am going to spend just a minute talking about some concerns that we have from the work that we have done so far. We are heavily dependent upon software vendors for software modifications. One of the questions that we continue to ask is, should vendors be required to comply with the requirements.
Some vendors are proactively going ahead and making modifications to their systems, but other vendors are not being so proactive. As we learned, with year 2000 work, you don't really know truly where a vendor is until it is time to receive their code and actually implement that.
Again, from the year 2000, some of the code that we received from the vendors that was supposed to be compliant we tested before we installed, and some of the code had errors, it really wasn't compliant, and some of it introduced new bugs into the system. So, from our perspective, we would like to see maybe some verbiage or something that addresses vendors and what is the vendor relationship with these standards.
Also, I think if we knew a little bit more about the monitoring and the enforcement of the standard, that that would be helpful. We are questioning, how are we going to be audited for compliance. Is it going to be something similar to a joint commission survey?
I just think that if we could understand that, it would assist providers in their preparation for compliance. Also, a point about the security standard. It addresses electronic health care information. From our perspective, we are not distinguishing between electronic information and paper.
I really think you need to look at the two the same, because providers that take HIPAA word for word and only look at electronic information, I think, are going to get themselves in trouble.
So, maybe a suggestion that, as providers prepare, don't distinguish between electronic and paper information. Then they are costs. As I mentioned earlier, the costs associated with implementing the standard is still a question.
Then because the final publication of the rule has not occurred, I think some providers are losing momentum and not perceiving the delay as an opportunity to get started early, but going ahead and moving HIPAA down the list of things to do and working on other projects. That is it. Thank you.
DR. COHN: Thank you, Rita. Gary Levine?
MR. LEVINE: Mr. Chairman and members of the committee, good afternoon. I would like to thank you for the opportunity to present to this panel from a pharmacy providers perspective, implementation issues related to the final rule of the HIPAA legislation of 1996.
I am Gary Levine, executive vice president of marketing for Medicine Shoppe, International, the nation's largest franchisor of professional community pharmacies with over 1,100 pharmacies in 46 states, as well as over 200 locations in 10 international countries. Medicine Shoppe International is based in St. Louis, Missouri, and we are a subsidiary of Cardinal Health, a diversified health care company located in Dublin, Ohio.
I am a pharmacist and have been active in the standardization process of pharmacy information over the last 10 years, through my involvement in the National Council for Drug Prescription Programs, NCPDP. As a previous member of the NCPDP board of trustees, and as having served as chairman of the drug utilization review work group, this work group created the on line real time DUR component of the NCPDP 3.2 telecommunication standard, which is now in use throughout the industry.
I would like to add that the formation of this DUR work group was in response to another very important legislative directive as set forth by the standards for drug utilization review, outlined in the omnibus budget reconciliation act of 1990, OBR90. The pharmacy community has benefitted from NCPDP's leadership in creating telecommunication standards for interactive on-line prescription-related processing between providers, clearinghouses, switches and third party administrators.
The adoption of their standards by provider pharmacies and claims processors has resulted in significant efficiencies and cost reductions for all parties involved. Standards developed by NCPDP have facilitated and provided great efficiencies from both a business and health care delivery system, supporting communications among a large and diverse number of parties within a third party prescription environment.
NCPDP's EDI standards are used and account for upward of 70 percent of an average pharmacy's business transactions and annually amount of billions of on-line prescription health care transactions today throughout our industry. It is my belief that NCPDP's telecommunication standard satisfies the necessary requirements mentioned under the HIPAA legislation for pharmacy including:
Improving the efficiency and effectiveness of health care systems by leading to general health reductions and lower operation cost;Meeting needs of the health care data standard user community; Being consistent and uniform with other HIPAA standards; Having low additional development costs relative to the benefits of using the standard; Being supported by an ANSI-accredited organization; Having timely development, testing and implementation and updating procedures in place; Being technologically independent of the computer platforms and transmission protocols, being precise and unambiguous but as simple as possible; Keeping data collection and paperwork burdens on users as low as possible, while improving the overall quality of the data; Incorporating flexibility to adapt more easily to changes in the health care infrastructure.
I feel that I can offer a unique vantage point to the committee, due to the fact that our pharmacists utilize many different pharmacy computer hardware/software platforms, which mirrors what is seen in the industry at large. Lack of standardization within our industry would place undue burden on pharmacy providers, making it difficult for software vendors to develop a product that would support our business needs.
It would be extremely difficult to develop any kind of operational efficiencies, and providers and payers alike would not realize the savings. Adopting a national EDI standard like NCPDPs would greatly decrease the burden on health care providers, by eliminating the need for us to continually reprogram our pharmacy computer systems to support multiple formats.
From a patient care standpoint, the benefits of standardization are enormous. Standardization within the industry will enable pertinent patient and medication usage and information to be exchanged and captured. It will allow for the screening of potentially dangerous drug conflict, drug therapy compliance, and delivery of disease management.
EDI standardization would result in timely and accurate health information, supporting the delivery of superior levels of patient care, better interaction among health care providers and improved health outcomes.
Conversely, uncaptured or unknown data may create a situation where the patient may be vulnerable to therapeutic conflicts or admissions without detection. Additionally, standardization will enable health care providers to document the services and value they contribute to the health care system and provide the basis for compensation for professional services.
With the intent of the HIPAA legislation, the work of this committee, aimed at improving the Medicare and Medicaid programs, by encouraging the establishment of standards and requirements to facilitate electronic transmissions of certain health information, the pharmacy community will be prepared to meet this challenge, using NCPDP's 3.2 telecommunication standard, which we as an industry already support and have made the investment of time and money to utilize.
This approach would also support the administration's desire to work closer with the private sector, in managing public sector programs. Furthermore, this would ensure citizens served under the public sector's programs would receive the same level of care as seen in the private sector.
I would like to share with you a number of the issues and concerns that are being discussed in the pharmacy industry, should we be required to move to a new version of the telecommunication standard, such as going from NCPDP's 3.2 to 5.0. Will pharmacy software vendors be able to complete the upgrade in sufficient time. What will be the cost of the upgrades in transferring existing data and patient history files to a new system. Will the complexity of prescription filling and processing times increase, thus affecting customer service and increasing cost. Will there be sufficient time to educate and train pharmacists on the software and process their help desk personnel on claim submission procedures and required data fields. Will trading partners develop user implementation guides, tutorials and educational seminars. How will the vendor and provider certification process take place. Who will be responsible for the vendor and provider certification? Will certification protocols be developed and utilized. Will the benefits of this new version be used by the industry. Will pharmacies be able to get a return on their investment after upgrading their system, and will the use of the new version of the standard be utilized by PBMs and switches to administer commercial business. Will implementation take place in an orderly fashion with adequate lead time.
Some of the current and future benefits and advantages of the pharmacy industry moving to NCPDP's version 5.0 standard are: Expanded dollar fields, HIPAA-supported fields, including employee ID, payer ID, and prescriber ID, new clinical fields including expanded diagnosis code, patient height and patient body surface area; Surface transactions for expanded professional pharmacy service support; expanded coordination of benefits support; expanded response messaging including preferred product support and approved message codes; pricing uniformity; Controlled substance reporting, including alternate ID and scheduled Rx ID; consistency within the NCPDP telecommunication standard; variable length transactions that allow for trading partners to transmit only the data required for doing business; and support of partial fill indicators.
In conclusion, I would like to commend the efforts and work of this committee and hope that you found that the information that I have provided you with is of value, and you will take it into consideration as you assist the Secretary in publishing recommendations and adopting standards. Thank you.
DR. COHN: Thank you. Robert Tennant?
MR. TENNANT: Mr. Chairman and members of the subcommittee, the Medical Group Management Association, or MGMA, is pleased to submit our testimony to the NCVHS from the perspective of the group practice. My name is Robert Tennant and I am the government affairs manager at MGMA, where I lead the association's HIPAA implementation efforts. I am on the board of directors of WEDI and the NUCC, and on the executive committees of the HCFA security summit and SNIP, the strategic national implementation process.
MGMA is the nation's largest group practice organization, representing some 7,100 physician group practices, in which over 185,000 physicians practice medicine. In my testimony today, I will be outlining some of the implementation issues, concerns and expectations that medical group practices have concerning HIPAA.
I will first outline some of the general obstacles to HIPAA implementation from the group practice perspective. I will also discuss roadblocks to implementation stemming from several of the specific HIPAA provisions in the transaction and code sets and PI, security and privacy NPRMs. In addition, I will then discuss the role of the Federal Government, how they can play a more important role in the implementation process.
Finally, I want to add a few of MGMA's recommendations that may help to speed HIPAA along. We are all well aware of the potential benefits of health care standardization. In the group practice setting, full implementation of HIPAA will result in more efficient office administration, consistent reporting, improved coordination of benefits, a simplified referral system, improved security of health information, faster reimbursement and, most important, improved patient care. Similarly, HIPAA standardization will encourage e health, particularly in the areas of improved bench marking capabilities, enhanced communication, accurate identification and, again, very important, reductions in medical errors.
However, it is important for us to note some of the general impediments to HIPAA. We have highlighted several of them. The first one I want to talk about is interoperability issues. There are countless proprietary systems currently being utilized within the industry, creating problems when these various systems attempt to interact or talk to each other.
Full interoperability between systems will take many years. All efforts to assist those seeking to identify and resolve interoperability issues should be supported. I just wanted to mention, an excellent example of that is the project with WEDI and AFEHCT, the internet encryption interoperability pilot under the leadership of Dr. Zubeldia.
Security and confidentiality issues. Obviously, this is perhaps the most public of all the implementation concerns, maintaining the security and confidentiality of personal health information. Many consumers are very apprehensive about having their personal health information sent over the internet, and many providers are equally concerned about their corresponding legal liabilities.
There is also a problem with the lack of a unique patient identifier. There has been a great deal of concern about the implications of privacy and security that the proposed use of a unique patient identifier might produce. However, providers must identify their patients, and the most common identification systems now are either a proprietary number or, more commonly, the patient's social security number. That, of course, has its own inherent security issues. Tracking patients electronically across disparate internal organizational systems and, as they move from one location to another, will be a critical factor in the expansion of e health.
Implementation periods and tracking. Twenty-four months may appear to be ample time, and for many in the industry that will be fine, especially for the larger ones with substantial budgets. However, those who either do not have existing vendor contracts, or whose vendors have left the scene, the two-year period may come and go very, very quickly.
A lot of our smaller members have very limited resources. For those who are initiating e health well into the compliance period, they may fail to meet the proposed deadlines. The NCVHS has been mandated to track and report on HIPAA implementation in the industry. That in itself will not be an easy task.
Self reporting and survey data are likely to be overly optimistic, even more so than much of the Y2K data received in the months prior to January 2000. This is due, in part, to the nature of HIPAA as a legal issue, with the potential for civil and criminal penalties for non-compliance. It is critical, however, to monitor the implementation progress of the industry.
Another general problem is security provider buy- in. Many providers, especially those in smaller office settings, have not yet merged onto the e health highway. HIPAA may be viewed by many of these organizations as strictly an electronic issue and, thus, not pertinent to them as they submit paper claims and maintain a paper-based patient record system.
HIPAA may be seen by these individuals as a reason to avoid moving to an electronic billing and records system. There must be educational outreach to explain the benefits of HIPAA, specifically, and e health in general.
Finally, it must be explained that HIPAA regulations -- primarily security and privacy -- apply to many aspects of their current system, and that HIPAA compliance is not optional. There are few reliable cost/benefit analyses of HIPAA. The tables included in several of the NPRMS are believed, by most observers, to grossly underestimate the costs of HIPAA. With accurate costs and benefits, and if this information could be given out to the group practices, they could begin to budget for implementation.
However, if the statistics indicate that there is the potential for enormous costs, that might be, again, a stumbling block to these practices moving toward HIPAA and e health. There is also a problem with staggering the roll- out of the regulations. By most accounts, the cost to upgrade practice management systems and claims software will be substantial. These costs will increase significantly if the necessary changes cannot be undertaken at the same time by a single vendor.
Again, we have been hearing that problem from a lot of our members, that staggered roll out would be a real problem. In terms of specific roadblocks, I want to talk first about electronic transactions and code sets. There is concern that the implementation process for electronic transactions will move faster than the corresponding electronic and paper forms can be modified, and that was discussed in the previous panel.
We have all heard that the NDC codes are coming to be the national standard, and that J codes are to be deleted from alphanumeric HCPCS. The switch to NDC codes for electronic transactions would naturally be used for paper claims as well. However, the 1500 paper claim form does not accommodate 11-digit NDC codes.
We on the NUCC HCFA 1500 subcommittee have been wrestling with various prototypes, trying to come up with something to accommodate the new HIPAA standards. As you heard from Larry, we are a long, long way away from that. There is also a concern that fines for non- compliance will be levied prior to full implementation and testing of all the electronic transaction standards. Many providers support deferring enforcement until there is wide experience using the proposed standards, and all future requirements subject to monetary penalties should be explicitly identified by HCFA.
HIPAA should not be a deterrent for those wishing to move their current administrative systems from paper to electronic. In the transaction NPRM, HCFA discusses the potential of temporary waivers for the purpose of testing new standards. They have suggested that an expensive cost/benefit analysis be undertaken by an entity proposing new standards.
HCFA should forego this requirement and promote all new techniques that lead to a better process of exchanging health care data. Road blocks, specifically, with the NIP. Concerns exist within the provider community that HCFA may attempt to offset their administrative costs of enumerating providers and developing the national provider system by charging providers to obtain an NPI or to update their information on the NPS.
We intend that HCFA should not institute user fees to enumerate these providers or update information, as we believe this policy would slow the dissemination of NPIs and deter those seeking to update their information. Should the transition from the unique physician identification number, better known as UPIN, to the NPI not proceed smoothly and quickly, there could be a substantial implementation set-back.
Many providers are worried with the potential of long delays in their receiving their new number, especially for those providers who are not currently enrolled in Medicare or Medicaid. This concern is a result of HCFA's repeated claims regarding their lack of administrative funds to disseminate the NPI.
HCFA's recommendation in the NPRM that providers be enumerated through a combination of federal and state registries is thought by many in the industry to be a cumbersome and inefficient method of registering providers, and would probably result in higher costs and a slower rate of provider enumeration. One of the concerns of the MPS that group practices have is HCFA's plans to capture more information, primarily demographic, from providers than was needed for legitimate business purposes.
We maintain that only the minimum amount of information should be collected, stored and disseminated. It is highly unlikely that the provider community will support the registry and update their information in a timely manner, should this data base be used for other purposes. Road blocks to implementing security and privacy.
DR. COHN: Mr. Tennant, I don't mean to break in, and I think your work is excellent, but since you have 22 pages of testimony, are there ways for you to potentially pick and choose a little bit, what you think are the most important aspects? We would appreciate it. We can have some discussion afterwards.
MR. TENNANT: Why don't I move to the recommendations? We believe that HCFA and HHS should be more involved in the HIPAA implementation process. The Federal Government should adopt a similar approach to HIPAA as they did with Y2K. MGMA contends that HCFA should institute a toll free number for providers with questions on HIPAA.
They should have outreach programs that include awareness bulletins, national conference calls, a speakers' bureau for conferences, an enhanced web site dedicated to implementation, and HIPAA jump start kits to assist providers in compliance. We believe that the electronic claims attachments and electronic medical records proposed rules should be released as soon as possible. They are important aspects of HIPAA and should not be delayed any more than they are already.
We should also move forward with the unique patient identifier. As I mentioned previously, that is a critical piece of the HIPAA puzzle. We should disseminate the NPIs as soon as possible, and try to get a single national registry and use the data bases from Medicare and Medicaid to initially populate the registry.
We should insure the flexibility and scalability of the security regulations. We are very happy to see that scalability is part of the proposed rule. We are confident that it will be in the final rule as well. State preemption should be the standard for all HIPAA provisions.
The Federal Government should comprehensively assess industry implementation levels at the 12 and 18 month milestones. This will be important to the industry and it will be important for us to get back to our members with a sort of state of the industry account every six months into the process.
We should also support industry efforts to facilitate implementation. While HIPAA is mandated by the government, the majority of implementation assistance is expected to come from industry sources. Such things as the security summit and SNIP are important, but they need to be encouraged and supported by the government.
There also should be federal support of the development of new standards. Right now, it is left to the six SDOs. Having just signed the memorandum of understanding, there is no funding for a central portal to deal with requests coming from outside to change, modify or delete any of the standards, and this should be funded by the Federal Government.
We should encourage the adoption of HIPAA and e health through supporting prompt payment initiatives. One important incentive to move the provider community toward HIPAA and e health is the adoption by private payers of the current Medicare 14-day window for paying a clean electronic claim. HIPAA should be seen as one step toward the overall goal of administrative simplification of the health care industry. With that, thank you very much.
DR. COHN: Thank you. Helen Guilfoy is our next speaker. Thank you, Robert. I do appreciate your extensive testimony.
MS. GUILFOY: I am Helene Guilfoy. I am with the health care consulting group of Insource Management.
We have been on the road since around January, performing readiness assessments and getting several of our clients ready for HIPAA implementation. This first slide I want to show you is our concept of a reliable HIPAA implementation. We have divided the phases up into an awareness phase with both us doing an awareness to our clients of what needs to be done, what HIPAA is all about, and then having them do their training and awareness within their institution.
The next phase, which is the phase that we are in right now is a readiness assessment. We look, after that, for remediation, followed very quickly by implementation, at which point they can have a benefits realization out of the changes that HIPAA affords them.
Surrounding all of these pieces and parts of HIPAA implementation is the concept of what needs to be done for the standardized transactions, what needs to be done for the code sets and identifiers, and all of that is wrapped in the security and privacy loop. Some people have suggested to us that this looks like a race track, and it probably does, and perhaps we are racing toward HIPAA implementation.
I want to give you a sense of what our clients are realizing with HIPAA. These are statistics straight out of the readiness assessments that we have already concluded. As a matter of fact, some of these statistics I was doing on the airplane last night. These are hot off the press. What we have visioned with our clients is, as far as security policies and procedures go, they have got about an 18 percent overall compliance rate.
That means that 18 percent of the information, the requirements that are in the HIPAA current NPRM, they are ready and ready to go with. They have got about a 30 percent compliance rate on some of the rest. The one that is more important is that about 52 percent of the requirements of the policies and procedures of HIPAA are not currently addressed within our client population.
Technical security is at an 11 percent compliance rate. Just so you know what is meant by these, when we talk about the technical security, we are talking about integrity, we are talking about the access controls, we are talking about alarms and events reporting, so that we have got a distinction between what is going on in the regulation and what is actually in effect in our provider community.
We are looking at provider communities from -- we have done the readiness assessment in communities from academic medical centers to large national health systems, to IDNs, so that you have a sense that this is across the board and this is also across the nation. This is not a geographic snapshot, if you will, of what is going on.
The next thing that we looked at were applications. We went into each and every one of the applications. When I am talking about applications, this is software applications. This is not the network. This is not their RAC-F, which I didn't even know what RAC-F was until I started working with the person who is our security expert. Now I can spell it, even, which is a major change.
What we did was, we have developed a tool to be able to do these assessments. We have looked at whether or not the individual systems store individually identifiable health information.
If they do, do they have individual IDs and passwords? Do they have audit controls? If you look on here, you will find out that less than 10 percent of the applications that are currently on the market -- this does not imply that they are out there but they have decided not to use them.
This is if the application has the ability to use individually identifiable -- to use IDs and passwords. Less than 10 percent of the applications that are out on the market today pass the test of being able to have full HIPAA security requirements as they are mandated in the MPRM.
The conditional score that you see here, which is over 50 percent but less than 60 is talking about those systems that have perhaps individual IDs and passwords but they don't have audit controls, or they have audit controls and they don't have individual IDs and passwords, et cetera, et cetera.
So, there is a mishmash of things in here, but the point that I want to make is that less than 60 percent of the systems that we have evaluated are ready to comply with HIPAA. Then the last thing that you will see on here is that about 32 percent need everything, as far as the HIPAA requirements go. I said that we developed some tools. What we did -- and I am sorry, I think the young lady from ENVOY just left, I would have liked to have discussed this with her.
What we did, we developed a tool that went into all the implementation guides and listed every single data element that is in the implementation guides. We divided them up by which piece and part was applicable. Now, you will notice that the dental claim is not on here. We didn't reflect the dental claim because none of our clients right now -- we don't have a lot of dental services.
We have evaluated some of the dental services, but not enough to be able to report back to you with what I feel comfortable with being able to report. The other thing that is not on here is NCPDP. As someone has pointed out earlier, retail pharmacies are already compliant, so there is not an issue with them.
If you look on here, what you see is that the lowest percentage of compliance for the institutional claim is 50 percent. The highest percent of compliance is about 62, 63 percent for the institutional claim. This means that they can, today, file a claim that this about 60 percent -- have about 60 percent of the data, if they are working full tilt.
Now, you heard in the earlier panel a discussion on content. This is content. That is all this is. We didn't look at format. We haven't gotten to that point yet. That is in what we look at as the remediation phase. This is simply, can you file the claim with what you currently store.
What we are seeing is between 52 and 60 percent of the content that is required on the X12 837, institutional, is available in today's systems that we have been able to evaluate. As far as the professional claim goes, between 20 and 50 percent --
MR. BLAIR: Helene, let me interrupt, because I am really eating up the data that you are giving us. Before we go further, about how many clients were surveyed, that are represented in this case?
MS. GUILFOY: We have looked at about 150 hospitals in that context that I have told you about. We have looked at over 220 systems. To date, we have looked at over 220 health care systems. On payment and remittance, again, the highs and the lows. The low is about 12 percent of the data is collected to be able to do the 835.
Highest ratio is about 40 percent of the data is collected currently on the systems, on the HIS systems that are available today in hospitals. You can go on down the line. Jeffrey, for your edification, I will go on. Eligibility is about 17 percent on the low scale. On the high scale, it is about 28 percent. Claim status, there is a little over 30 percent on the low side, and a little over 40 percent of the data is collected to be able to file the claim status.
As far as referral and certification, a little over 42 percent of the information is currently collected on the low side and, on the high side, about 89 percent, 88 or 89 percent of the data is collected. Now, this is data that is collected. Somebody spoke, in the last panel they were talking about the code sets and the distinction between what we currently collect on the UB and what is going to be required on the X12. I know I have spoken to this committee before about the differences in the variability of those code sets. They don't match.
We have not found a hospital yet where the code sets of the information that they currently store matches what X12 requires. What they are doing is, they are running it through translation algorithms or whatever in order to be able to get the information as it is required currently on the X12.
Now, I want to look with a little bit more specificity toward the institutional claim detail. What we did, as most of you know, as all of you know, I suspect, on the committee here, the institutional claim is the life blood of the hospital.
If, on August -- or now I guess it will be a little bit later, won't it, Bill -- in September or October of 2002, when we have to convert from the UBs to the institutional claim, if we can't file them electronically, we are going to be in trouble, all of us that sit on the provider side.
What we did was, we went into the 837 and pulled out the specificity of the different data elements. You heard several people in the previous panel talk about things that were required and, because of the variability of the 837, that there were things that were out there that weren't there before and things that were out there before that are not there now.
What we did was, we went into the actual implementation guide of the 837 and pulled all of the data elements together into groupings. These are pretty evident if you review the implementation guide. The first bar here that you will see is, these data elements are required for all claims, regardless of any variability. All claims must have this information.
Currently, today, the hospitals that we have reviewed and the systems that we have reviewed collect about 72 percent of the information that is required on the claim. So, this is not -- the variability, you have got to have it or you are not going to get a claim out there. That is why I was referring to the information with ENVOY.
This is exactly what they said. They can't make it up. There are going to be holes in that claim when they get it, because the providers are not able to collect the information. Coordination of benefits information is interesting, because we got about 82 percent of the data for coordination of benefits is currently collected.
Home health information -- frankly, I didn't expect, because we were looking primarily at business office systems, and usually home health sits off by itself, I didn't expect a lot of compliance here. We got about a 32 percent compliance rate on the home health data elements. Now, I want to point out also that these people, even though they can collect the home health information, they still have to collect all the rest of the information, too. I don't want you to think that 30 percent of the information and they are going to be okay. Special applications, as expected, it probably about an 18 percent compliance rate. What do we mean by special applications?
The way I divided that information is the auto accident, it specifically requires information for an auto accident to be collected differently on the X12 837. For some of the other information for the special information is information that would be required on a capitated claim.
Again, we are looking at about an 18 percent collection rate of the information. Remember, this is information that is collected electronically. Our first question is, do you collect this information electronically. If you don't collect it electronically, they have got to find some way to get it.
Either somebody in medical records has to sit down there and key it, or somebody somewhere has to get that information electronically so that they can get onto an electronic claim. Medicare information is about 18 percent collected currently, and this is again specific information that is required for Medicare adjudication. Information that is required for inpatient only is about a 68 percent collection rate of the data elements that are required on the 837-I.
Now, the last column you see on here are the ifs, and I call them ifs because they are, if required, if known, if needed. I love that one, if needed. If you need to have this, you have got to send this to us electronically. On that one we are getting about a 40 percent collection rate. So, this does not look good for a two-year time frame.
However, what we have done, what we are doing at this point to assist our clients is, we are sending letters to their vendors, asking them for their HIPAA compliance, what their plan is, is it going to cost the client any more money, when they expect to have this information out.
The thing that our client needs to understand and the vendors need to understand is, they can't start to do any training or testing until the vendor delivers the software. It is only at that point that they can start doing the data collection and doing the training.
As I said before, these code sets are different, sizes are different on the data that is being collected. So, this is going to be a real retraining job for the registration people in the hospitals. As far as the identifiers go, we have looked at two identifiers so far. We had originally started looking at the plan ID, and thought that that may be too far out to even look at.
So, we have narrowed our search down to the national provider ID and the national employer ID. As you can see on here, about 40 percent of the current HIS systems that are on the market -- not HIS, all health care systems that are on the market that we have been able to survey can store the new size and the new format of both the NPI and the national employer identifier. This is going to mean that they are going to have to get either a whole new field, they are going to have to expand their field that is currently out there, whatever, but they have got to do it for 60 percent of the systems that they have got in place.
Code sets. What we looked at with code sets, given the concept that the diagnosis code, currently we are using ICD-9 and the NPRM requires ICD-9 CM. There has been considerable discussion amongst this committee early on that we would be going to ICD-10 CM within about two years.
So, what we looked at, and what we have posed to our clients is, since this is going to be about two years hence that this stuff is going to be available, let's look at it now. Why go back in and hit all of these systems all over again. If we are going to go in and expand field sizes, if we are going to do testing, let's do it all at once. Let's bite the bullet and get it done.
What we have found is that between 36 and 43 percent of the systems today will be able to collect the new size for the ICD-10 CM. On the procedure code, we are looking -- we use the size of the ICD-10 PCS, because that would be larger than CPT-5.
Between 43 and 75 percent of the systems on the market today will be able to accommodate the ICD-19 PCS, and I want to point out the disparity here. You are looking at a high side on the diagnosis code of 43 percent. On the procedure code, you are looking at 75 percent. I suspect it has to do with the two panels that were early this morning on the local codes. If you look at the sizes of the local codes, they are all over the sheet. I suspect that this accommodation of the procedure code, being able to accommodate a larger field size, is because of all the local codes that are out there.
The NDC code, it is collected in all of the pharmacy systems that are out there, but it doesn't get to the billing systems. Nowhere, nohow does it go to the billing systems. It never leaves the pharmacy. It does not pass go, it does not collect $200. It stays there.
Now, the other problem with it is the storage size for HCPCS is a five-position field. The storage size for NDC is 11 positions. So, somewhere our vendors are going to have to find a way to get 11 positions into the claim form, or the claim format, excuse me. I keep using that word.
What is it going to go? Is it going to go into the CDM, which is where the HCPCS goes? Is it going to go just directly into the patient account record? We don't know. We are struggling with that internally in our own company to make some recommendations to our clients.
The other thing that is particularly critical with the use of the NDC is that the maintenance of the code within the individual pharmacies is that it is not collected, not maintained either with any consistency or with any timeliness. If you know anything about the NDC, you know that the first two positions of the NDC indicates the manufacturer of the drug. Now, the pharmacies are very up-to-date with all of the other information, but they may not be up to date with the manufacturer. They change contracts or they have run out of a particular drug from one manufacturer, one manufacturer's truck broke down or whatever and they have got to use another manufacturer. That means a different NDC code.
I think we need to look at that and that problem and determine -- with J codes, it didn't make any difference, because it was so generic that nobody cared. With NDC codes, this is going to be a real issue for hospitals. How specific do they have to get with that NDC code. It is just not maintained. This is every single one of our hospitals that we have looked at.
Where do we go from here? Well, I am not going to beat you up about the final rules. You have been beaten up sufficiently all day long. I think that one of the problems is that the impact of the transaction standards is not generally known or understood within the provider community. There is a large disparity between the current status of all of the health care systems and the compliance issues. There was a very recent report that came out that talked about compliance issues, but it only mentions privacy and security.
Even at that, it still says that about 20 percent of the respondents -- these were health care providers -- 20 percent of the respondents said, oh, we are going to look at that in the next 12 months. Twelve percent of the respondents said, oh, we will get around to it sometime.
This is a major understanding issue. It is a major awareness issue for providers to understand that the transactions and the code sets are going to come out and they are going to hit them hard. If they can't get claims out the door, they can't go back to paper. That is absolutely untenable. It is going to require a major coordination between the providers, the vendors and the payers completely.
The last thing I want to show you, the light at the end of the tunnel is not a train. It is the sun. We have a lot of work to do, but if we all work together and we all understand the work to be done, we can get there. I just wanted to leave you with that thought.
DR. COHN: Helene, than you very much. Patrice Kerkoulas.
MS. KERKOULAS: I will go very quickly. Thank you again for the opportunity to testify today. Unfortunately, many of my comments will mirror what you have already heard, so I will go as quickly as possible. I am Patrice Kerkoulas. I have been in health care 16 years, and I currently work at Memorial Sloan- Kettering Cancer Center in New York City.
These are some of our statistics. At Memorial, we have four standards in production today with Medicare, which is about 34 percent of our payer mix. Basically, this is HIPAA at MSKCC. We implemented the 835 with Medicare in 1995. After the HCFA proof of concept testing in 1998, we actually moved the 276, 277 and 997 into production in January of 1999.
We are currently in the middle of a proof of concept project with Empire Blue Cross on the hospital outpatient therapy, 277, 275 request for ADRs. Basically, most of my slides have comments about our initial proof of concept testing, but I have some additional proof of concept testing comments.
Again, that was the initial 276, 277 was in 1998. These are some of the other providers that we participated with, the list of other providers and payers and integrators. The scope of the project was actually to prove if the implementation guides were ambiguous or not to move ahead.
What we found is that there were some ambiguities left, even at that time. We have seen that they have definitely improved over the last two years, and I will give you some examples. Primarily, we saw that there were unforeseen complexities of implementation that warrant beta testing prior to the implementation, and I will give you some examples of that also.
With the 276, 277, primarily it was interpretation issues. You have heard that already this afternoon. The data elements were as standardized as you could make them, but there was a lot of room between the payer and provider, as to what does provider number mean. Is it billing provider, rendering provider, group practice provider. Could any of these three inquire on the other, as we moved into security and privacy.
On the hospital side, there were a lot of date of service issues. If we sent a from and through date, would they need to return only exact matches, anything in between, anything that matched admit dates, discharge dates, and those were just agreements that we made with the payer. Also, we had the end user issue of going from a very nicely customized, proprietary status code into the national status codes.
That was mostly a hurdle for the end users, because they really liked that customization and specificity, and it translated from one Empire code into maybe six or eight national codes. You got the same information, but it was a learning transition. We are in the middle now of the 277, 275 pilot. Empire and HCFA have asked us to work with them on the 277.
Just a few things, and again, this has to do with the fact that it is a draft implementation guide. On the WPAC web site, it doesn't specify the Adobe version or whether you need zip or unzip. That took a little bit of end user issues to overcome them. We couldn't find annotations for a while. They have released a new guide two weeks ago, and now everything is there. LOINK codes also were not there initially.
I guess my only point here is, we were really trying to be on the cutting edge and the information that we needed to do all of our programming was not available yet. Unfortunately, we did have hard copies and they are released now, but it delayed our programming slightly.
Finally, just another ambiguity that we are working with. As you know, the Medicare APCs are currently in roll out, moving toward the line item date of service, which has recently moved into production.
This is something new on the hospital side to actually look at the 997, which is the acknowledgement of the transaction, whether we are going to do that for files, claims or actually down to a service code level. How far do we actually need to use 997s with this particular transaction set. So, it is something completely new that we have to evaluate.
Just a few words about testing. Again, I am just echoing things you have already heard this afternoon. We find that it is very important to do complete testing. We don't like to take on a project, even a pilot project, unless we know we can move it into production. So, we try to really identify complete test scenarios.
We try to get test files out there for the programmers so that, until they get their initial file from the payer, which has been the case with our two previous proofs of concept, they would have something to work with to get started. Then we also have to start to align all of our business office resources, to get them ready for the testing and the implementation, which was bigger than just the implementation guide or the transaction set.
We were also looking at networking, any interface issues, hardware, resources. We store things on our document imaging system, so that group had to be brought into the picture. It was a larger scope than just looking at the guide.
As far as our test scenarios, we would recommend actually developing -- this may be part of SNIP -- but developing a testing checklist that could be used by all payers and providers. There is no point in every payer developing their own checklist. That could be provided on the web.
We actually, for the 276, 277 prepared 89 different test scenarios. There is a list of different things with different bill types, age of claims, volume testing, and other things that are just basic test scenarios that we felt would need to be done before we moved something into production.
Moving onto the network and standards issues, which is our second major, I guess, comment about the implementation guide, was that looking ahead toward production implementation, we really weren't ready, from a networking standpoint, to move everything in. So, all the testing went beautifully. We moved ahead. We were ready to start doing that day to day, either batch or on-line interface.
We found that our standard of FTP was not readily available at Empire at that time. We actually moved to a PC modem workaround, which we hope this year we will eliminate. All those things really need to be taken into account. You can't have people transmitting and going back and forth from PCs. It just adds too many layers to the interfaces and too many things to go wrong.
Within our 276, 277 project, and now in the 277, 275, we are anticipating that there are going to be versioning issues. Currently we are testing on a 4020, but we have 4010 live in production. So, just looking ahead, again, at phasing all of the versions, we really need to look ahead to see, are all the different transaction sets going to always stay on the same version.
You have to allow some window of overlap. How will the providers and payers deal with that during that three to six-month period, where every transaction set, and every provider payer, payer, may have a different version. We won't know unless they really stay up to date.
We actually have approximately 400 plans set up, since we have patients from all over the country and all over the world. It becomes very complex for just maintaining who is on which version. We also had a difficult end user transition, as I mentioned before, going from that really customized, proprietary software into the standards.
This may primarily been for Medicare, because Medicare has historically really been ahead in automation. They are our most highly automated payer. So, Empire has really worked ahead there, whereas the other payers are not quite as automated, so it may be less of a transition.
We have a dedicated line, the SNI link, with Empire. That has made it difficult for us as a hospital to really think strategically as to how we are going to do these interfaces, not only with the hospital billing but also professional billing.
Financial transactions have been on ANSI standards for years, and they already have all of that automation set up. Because of cost, we chose to stay with our proprietary network line. That is still something that we will have to overcome in the future.
Really, when we look at it, when we look at timing versus cost, we are really looking at maximizing both, moving ahead, being very frank. Looking at response time considerations, again, we really applaud both the Empire and serious programmers. We had excellent transaction throughput, which was wonderful.
As far as the centralization, that is what I just meant or spoke about, about reorganizing and technology buy in, by our different divisions within the hospital, to try to standardize and get the lowest possible transaction fees, unless we are going internet-based. A few people have mentioned internet. That is another hurdle for us, because everyone sees the internet as free and some type of a van as transaction based.
It is hard for us to move ahead with vendors that are not internet enabled, because of the thought that it will cost us more money. I also mentioned open network integration, actually moving from the SNI link to more of an FTP environment. That has continued to be delayed. So, all of these are delays in our implementation.
As far as the 276, 277 time frame, we had actually planned five months. The actual testing was less than eight weeks, but because of these other network issues and just staff coordination issues, it was actually nine months from beginning to end.
The 277, 275 time frame, we are actually planning four months for project completion. The 275 was tested earlier this year by Empire, so that is not part of this, and we are planning production implementation of the unsolicited 277 following the proof of concept testing. That would be later this fall with Empire.
Looking ahead at some of our recommendations on phasing the implementation, we had recommended to HCFA, during the 276, 277 project, to actually implement the standards that are one way transaction sets first, to try to get those out of the way and let the payers and providers get a lot of experience.
Allow some type of a phased implementation time frame by transaction sets, maybe six to 12 months for the first ones and then a shorter period as people gain the experience. During that project, we exchanged 19 sets of files that identified 26 interface issues, and that was for those 89 test scenarios that I mentioned.
Here, just looking ahead and hind sight, it is really a phasing versus procrastination. Again, you have heard this several times this afternoon. Originally, Empire had given all of their providers, all of their Medicare providers a three-year window to move to the 835.
We started the project about seven months before the due date and implemented 11 days before the due date. Part of it was -- some of it was the early implementation. Some of it was the fact that we had other pressing projects, and we had that window. We knew that we could get it in and we wanted until the last minute.
So, thinking about that, we don't really think that should happen with HIPAA. If everyone is waiting for the last minute, all the providers, all the transaction sets, it is going to be worse than Y2K, moving ahead. At the same time, we started formally requesting 835 from our private insurance in 1995. We do not have any 835 live with private insurance at this time. Again, we would recommend actually phasing the sets, not making all 10 sets due at the same time, because everyone will put them in the last month.
Just two general comments, and then I will close. These are provider-specific considerations. One is just the work flow analysis, and the next few slides just to through the work flow analysis we did with the 276, 277. Our director, Mr. McBride, really insists on streamlining the reengineering for cost elimination. We both plan for that and prove it to him by doing before and after flow charts.
So, we identify everyone who will be involved to plan out the projects. We actually flow out the projects and where things are going to be automated, including all of our various support systems. I had already mentioned document imaging. Then, how the interactions with the payer are coming in and how automated transactions will be posted. As a result of this, we could actually also map out when we would process our 276 transactions automatically.
We found that we could actually transmit and resolve the bulk of them a few days after initial billing prior to the Medicare payment. That has significantly reduced our receivable days. In the outpatient area, we had actually done our claim status at a 30-day cycle, and volumes at that time prohibited shorter cycles.
On both in and outpatient, originally we required a phone call for provider services. All of that has been eliminated with the claims status transaction. Looking at the claim status, the actual cost analysis, we saved 92.5 hours a week. Again, that is for Medicare alone. We reduced our claims aged over 30 days by 18 percent in a one-year period of time.
We really felt that was a good cost analysis. We had previously given to HCFA some other statistics. That equates, for us in New York City, to over $100,000 a year, and we would anticipate about three times that for the private payers and other payers. Again, looking ahead with the HIPAA roll out, for the other transaction sets, because Medicare has historically been highly automated, we really anticipate minimal cost savings with Medicare.
Minimal to us, we have already demonstrated with one set, was over $100,000. So, the other payers, we anticipate significant cost savings. Again, we have provided some of that data to HHS a few months ago. The data that we did provide for the 276, 835, 837 and 270, totaled to about $500,000 to $600,000 a year, and that was a very conservative figure.
With our 277, 275 pilot, we anticipate that that automation which was just addressed of the medical documentation is going to be the most expensive. Even with the 277, we won't have any changes in the current way that we handle that Medicare 700, 701 form. We won't have any cost savings there at this time.
Just to conclude, I want to give special thanks to Steve Barr, who is now retired, Chris Stahlecker, who will be speaking in the morning, and Susan Ryder, who took her place at Empire, Dan Holmes, Norm Branbutt at MSKCC, our programmer, and my director, John McBride, and also to the committee for letting me share this information. Thank you.
DR. COHN: Patrice, thank you very much. Fred Urbanek?
MR. URBANEK: Hello. My name is Fred Urbanek and I am a manager for Premier Sourcing Partners, which is the wholly-owned information technology services subsidiary of Premier, Inc. I have been asked to address the committee because of my involvement in Premier Sourcing Partners' efforts to facilitate collaborative solutions for HIPAA among Premier's alliance hospitals and health systems.
Premier is a strategic alliance of approximately 215 independent not-for-profit health systems in the United States. Collectively, our systems operate or are affiliated with about 1,800 hospitals and other health care sites across the nation.
Premier includes some of the nation's largest and best known not-for-profit hospitals and health care systems, as well as strong community hospitals generally mirroring the composition of the hospitals and health systems industry in the United States.
Hospitals and health care systems come together in Premier primarily to gain advantages of scale for purposes such as group purchasing of supplies and services, but recently our alliance members have been asking a lot more from Premier, to just tap into some of the synergies of the group that are listed here, that I won't go through.
Obviously, the implementation of HIPAA represents a common challenge for Premier Alliance members. Due to personnel and financial resource constraints within the provider community, it is of vital importance that compliance activities associated with HIPAA regulations are performed in an efficient and cost-effective manner.
At the request of Premier Alliance members, Premier Sourcing Partners has launched an initiative to facilitator collaboration among Premier Alliance members, to leverage the synergies of individual HIPAA efforts and identify opportunity for co-investment in HIPAA solutions.
The key component of Premier Sourcing Partners HIPAA initiative includes the formation of a member-driven HIPAA working group. Although the HIPAA working group is open to all Premier Alliance members, the group is currently composed of representatives from approximately 15 Premier Alliance organizations.
Once per month, our working group comes together via conference call to discuss current HIPAA-related topics and share experiences, insights, challenges and lessons learned. Currently, the CIO of the Alliance members is the primary participant in the working group conference call.
The information I wish to share with the committee today is primarily based on my interaction with the Premier CIOs who participate in Premier's HIPAA working group. I will also be sharing some information and other interactions I have had with Premier members at different points within the organization, through my efforts to try to gain buy in for our initiatives.
The topic of discussion today is HIPAA early implementation. My experience to date indicates that there is no organization within the Premier Alliance that wishes to be a HIPAA early implementor. In fact, I have found that even those organizations that appear more proactive at addressing HIPAA issues than their peers take offense when I describe them as HIPAA early implementors.
This is mainly for fear that they are going to lose funding and support from management because they are doing too much. This moniker tends to imply that the organization is doing more than is absolutely necessary to address a challenge where there appears to be very little benefit for those who finish ahead of schedule. Overall, it appears that little progress has been made toward addressing HIPAA, beyond general HIPAA education and awareness.
The majority of our alliance members that I have interacted with indicate that their organizations continue to struggle with the uncertainty of how to manage the HIPAA project. Similar to year 2000, the chief information officers are typically trying to raise organizational awareness regarding the issue. However, they are reluctant to assume responsibility for the overall project, due to the impact that HIPAA is expected to have on the organizational business processes.
In some larger organizations, I have seen instances where corporate legal counsel has been delegated responsibility for HIPAA. However, in these situations, they tend to result in a very legalistic result in addressing related issues. In these organizations, there appears to be more time spent interpreting and analyzing the regulations but very little tactical action. The challenges associated with organizing a HIPAA project team and securing an executive sponsor are the direct result of an overall shortage of qualified personnel resources within the provider organizations.
Considering the impact HIPAA will have on clinical processes, one would assume that a member of the clinical management team would assume leadership responsibility for HIPAA. Unfortunately, these personnel shortages in the clinical departments require a clinical staff to focus efforts exclusively on patient care needs.
There have been a few organizations within the Premier Alliance that have done varying levels of security assessment. If such organizations used an external vendor for the assessment, the vendor would claim that the work constituted a HIPAA assessment.
However, when I talked with the CIO of the organization, he or she typically indicates that the work was performed to assess the level of business risk associated with the organization's use of technology. Feedback regarding the level of HIPAA compliance with the proposed security standards has been seen as more of a byproduct of the business risk assessment mitigation process.
Limited financial resources represent the greatest barrier to addressing HIPAA. The most common reaction I receive when I discuss HIPAA is, here comes another unfunded mandate. At first glance, one would wonder if individuals making these comments fully understand the goals of administrative simplification and the potential return on investment.
Overall, I have found that most of the individuals within the Premier Alliance appreciate the basic tenets of HIPAA, recognizing that security the privacy and confidentiality of individual health information is good for health care. Unfortunately, there is a perception that compliance with these rules will require expensive system upgrades or replacements.
Many hospitals are currently struggling to finance operating costs as a result of the balanced budget act and year 2000. As such, there are few financial resources available to make any investment that it may take several years to recognize a return. This is especially true in investment in controls, where return on investment is realized through cost avoidance.
Other barriers to HIPAA implementation include dependence on system vendors. There is an estimate that 90 percent of the software in our provider organizations come from a third party, and we have heard several people discuss about the concerns regarding that, and dependency on them.
We have talked about implementation of solutions. They are assumed to be problematic due to the level of business process change expected to occur to meet HIPAA compliance requirements and the inability to gain support in the clinical areas. Then the ambiguity regarding the requirements just seems to be a general uncertainty regarding the impact HIPAA will have on proven cost effective processes.
With respect to HIPAA implementation solutions, Premier Sourcing Partners of HIPAA working group has suggested that incentives be created that would better motivate provider organizations to migrate toward HIPAA compliance in an expedient way. An obvious example would include increased reimbursements for organizations achieving compliance before the deadline.
It appears that the current approach of punishing those who do not comply by the deadline promotes just-in- time compliance activities. Accordingly, organizations will develop their own compliance plan in light of a specific level of risk tolerance of the organization.
Another viable solution includes extended or staggered compliance deadlines based on the type of covered entity. Extended or staggered compliance deadlines could help address the implementation issues resulting from dependencies on third parties such as system vendors and trading partners.
AFEHCT, which we have heard earlier, had authored a white paper sequencing the implementation of HIPAA requirements, transactions and code sets, which really identifies many of the implementation issues associated with dependencies among payer systems, vendors and providers. As the paper indicates, providers are dependent on both payers and system vendors in order to achieve compliance. However, all covered entities are being held to the same compliance deadlines under HIPAA.
A third potential solution suggests extended and/or staggered compliance deadlines for processes and systems within the provider environment. Many organizations propose using some type of grand-fathering approach to compliance for various business processes and systems.
This solution is intended to eliminate the need to replace and upgrade clinical systems for the sake of HIPAA compliance. Rather, HIPAA requirements should be mandated for new business processes and related systems that will result from the natural migration to e health.
Capital dollars are simply not available to replace proven, cost-effective processes and systems. In summary, early implementation of HIPAA has been interpreted in the provider community to mean achieving compliance any time prior to the compliance deadline.
Limited financial and personnel resources have limited provider efforts to raise organizational awareness regarding the challenges associated with HIPAA. In fact, many organizations have not yet initiated efforts to assess the scope and breadth of the HIPAA project.
Provider dependencies on third parties exacerbate the challenges associated with achieving compliance, and viable solutions from a provider standpoint will involve financial incentives or rewards for achieving compliance and/or extension of compliance deadlines.
DR. COHN: Thank you very much for the presentation. I want to thank the panel. We are obviously getting a little close to 5:00 o'clock. Does anyone have any questions for the speakers?
MR. BLAIR: Helene, the survey data that you gave was very enlightening. Actually, I would really like to thank all the folks that testified. Everyone gave great insight. I just happen to have my first question related to Helene's survey.
When you are working with clients, a survey like that could be extremely helpful for an individual client. I am wondering if it might be helpful on a broader scale, and that raises different questions. You have been evaluating, did you say 120 vendors?
MS. GUILFOY: No, over 200 vendors.
MR. BLAIR: Over 200 vendors, and you have made an assessment of whether they have the ability, with their systems -- I guess options that may be put in place -- for example, to support 835 specifically or 277; is that right? It is at that level of granularity?
MS. GUILFOY: Yes, that is correct. I want to point out, though, Jeff, that of the 200 vendors, not all of those are vendors that provide billing systems. There is a lesser number that provide billing systems. We are also looking at systems like clinical documentation packages and so on and so forth.
When I use that 200 vendor figure, or system figures, that is across all of those questions. That includes providers being able to store the provider ID if they need to store the provider ID. That can be simply a physician credentialing system needed to store the provider ID, but they have nothing to do with collecting an 835.
MR. BLAIR: Okay. The gist of my question is a slightly different purpose than the purpose you have designed that survey for. You have designed it as a tool to help your clients evolve, and to identify which vendors might be helpful to them.
The question that I have gets to whether or not the data that you are gathering -- and I am assuming it is on an ongoing basis -- would be of value for certification, either for you as a consultant to indicate that you have certified that certain vendors have this capability and publicize it that way, or for you to make that information - - is it the kind of information where you or your consulting firm would have a comfort level indicating that this could indicate that these vendors are certified or have these capabilities?
MS. GUILFOY: What we intend on doing, Jeff, with the data in the near future is, as we develop the information on the specific vendors, we will be putting it on a web site that will be a subscription web site. The idea is that if somebody was looking to purchase a particular system, they could go out to the web site and find their potential for compliance. I want to point out that there are not vendors today that are compliant.
MR. BLAIR: Across the board or any?
MS. GUILFOY: We haven't found any.
MR. BLAIR: With any transaction at all?
MS. GUILFOY: No, the maximum that we had was 80- some percent or something, and that was on one particular transaction type.
MR. BLAIR: You have been feeding this information back to the vendors, I assume?
MS. GUILFOY: What we are doing right now is, we are surveying the vendors to determine their awareness of HIPAA, what their compliance plans are, what their time table is. We haven't gotten much data back from the vendors yet. Some of them are still trying to spell HIPAA. We keep getting health information rather than health insurance.
MR. BLAIR: Let me save the rest of my questions until others have asked theirs.
MR. SCANLON: I was thinking, as I listened to the surveys and the assessments, have you come across any of the sort of best practices that actually are -- other than Memorial Sloan-Kettering and probably we have two of them here today that actually seem to be moving readily on all of these things. What is it that separates those who seem to do it and save money and do it effectively from the others, and are these the best practices in these cases, could they be used to stimulate others.
MR. KERKOULAS: I think part of our success is just having a visionary senior executive management staff that supports the efforts, they recognize there is a national need. They make sure that we have staff and funding to do these projects. They are constantly asking, have we volunteered for the next project. By volunteering, we get all of our needs heard. It really makes it a win/win situation.
MR. SCANLON: And they believe, apparently, that it is paying off.
MS. KERKOULAS: Yes.
MS. GUILFOY: Those were pretty dramatic figures that you had on your time saving and stuff. In fact, I wrote them down to present them to some of our clients.
MR. SCANLON: So, there is a business case that can be provided.
MS. GUILFOY: Absolutely. I think what Patrice said is the visionary at the top. Obviously, the clients that we have been dealing with have that vision, because they are the ones that are out there saying, what do we need to do to get ready to implement HIPAA.
They are the ones that, if we are looking for best practices, they may not today have the best practice, but they will and they are willing to move in that direction. I think Providence is probably another one that has the same kind of visionary environment.
MR. SCANLON: Is that the major factor, enlightened management, visionary management?
MS. KERKOULAS: I think it is. Also, I think it is just structuring the right team, getting started and having a positive spin on it, to be able to bring value back to the organization.
DR. ZUBELDIA: Following up on that question, Jim, I remember from the HIMS meeting in April that all the vendors at HIMS came to be HIPAA compliant.
MS. GUILFOY: Did they get a gold star?
DR. ZUBELDIA: I asked one of them and they said they had been certified to be HIPAA compliant. I don't know by whom. Helene, I think your charts were very illuminating. I would like to comment you for that and encourage you to continue. I would like to see something like this for the payers.
MS. GUILFOY: We are starting that now. In fact, with this very last client, the one that I was on the airplane finishing up the numbers on, we started doing that with them. They really are sort of pushing the envelope and we have done a similar letter that we sent to the vendors to say, what is your time table for readiness. We have done that to their payers at this point and said, what are your readiness plans to implement HIPAA.
What we want to work with the client with at this point is where are they going to get their biggest bang for their buck? Where should they put their energies? If they are at 80 percent and they only have to collect 20 more percent to be able to do a particular transaction, perhaps they can impress that upon their payers to say, we are almost there, how about you guys.
DR. ZUBELDIA: I think that gets to the point of what I would like you to do, unfunded. Look at the payers and find out how much of the data that is required in HIPAA is either needed by the payer, how much is not needed, and how much of the data is thrown away to the meat bucket because the payer not only doesn't need it, also has no place to put it, nowhere to store the data that the HIPAA transactions may require. If we find a lot of that, then we need to go back to implementation guides and say, hey, these requirements are too strict.
MS. GUILFOY: I think that is a real good point, Kepa. I think some people on the last panel spoke specifically to that issue, that this thing has just exploded exponentially in the amount of data that we have to collect now.
It is almost like an HL7 transaction, where you collect everything and you send it all to the lab, and they need about three fields out of that entire ADT record, but they are going to get it all anyway and they just take off what they want. That is pretty much -- that is the way I have sort of described the HIPAA transaction, that the closest equivalent is HL7.
I think you are quite right. What is it that the payers need to have actually.
MS. KERKOULAS: I just want to add from the provider standpoint, whether you eliminate data elements or you leave them, by making them optional, then the payers, we would anticipate, would turn around and say, since you didn't provide that the first time, we need to resend the claim. Now that we have seen that data, we need some additional data.
From a provider standpoint, we would rather send everything at once and then say, New York State, you have 45 days to pay. We have given you everything.
MS. GUILFOY: That is our recommendation to the client. Whatever is out there, you have got to collect it and send it. Don't you try to be discriminatory, for this exact reason.
DR. COHN: Let me make a comment or two. I guess I am left scratching my head a little bit, only in the sense that, Helene, I saw your data. I am not quite sure whether I either believe it or know what to do with it.
MS. GUILFOY: Thanks, Simon.
DR. COHN: What I am hoping is that we can have HHS take a fuller look at it. The reason I say this is that I am just reflecting on what Deborah Meisner from ENVOY was sort of commenting on earlier, that, geez, not everything is here, but by adding this from this area and X from another area, we get very close to being able to fully deal with it.
As I say, I don't know what to do with it. I don't know whether what we are doing is looking at a billing system where we know, to send a transaction in the billing system we need stuff from demographics and out, or whether there are more systematic issues.
MS. GUILFOY: One of the issues is that there is a lot more clinical data that is now required. That information, in a lot of situations, is not yet automated, number one.
Number two, if it is automated, it doesn't pass through to the billing system. It may pass through to a decision support system, but it doesn't pass through to the billing system. That is one of the things that needs to be addressed. You are quite right. There are buckets -- there are island of information -- how many times have we heard that -- that need to get into the billing, and we are looking at that, too.
DR. COHN: Great. That is the sort of stuff that I think becomes actionable and helpful. Beyond that, I was actually hearing a couple of things sort of loud and clear and I am just going to -- you can all nod your heads if you sort of agree.
One was -- this is some work done that Robert Tennent did. While I made him abbreviate some of his testimony, I actually did hear most of it. I thought that his comments about the need for comprehensive assessment of the industry implementation over the next 12 to 18 months is going to be very, very critical.
I think I heard that better from this panel than anything else I have heard. We have been hearing about tracking implementation, but I think as we go along here, I am just sort of hearing from all of you that there is going to be a tendency in the industry to not do anything until we publish the final regs.
Once that happens, it is going to be sort of a horse race and we are going to have to be following it very, very carefully. Is that sort of something that everybody is sort of thinking? I am seeing all the heads sort of nod, I think. The other piece is that there probably needs to be some work with HHS to get more funding for HHS to begin to help some aspects.
I mean, I don't think they are going to take care of everything that needs to happen, but clearly, implementation is not going to happen just by going to sleep and waking up in six months. I think we have a lot of facilitation that HHS is probably going to have to do, and it is going to have to require some relatively dedicated resources. I guess I was hearing that also from the group.
Robert, am I hearing you pretty well in terms of some key recommendations?
MR. TENNENT: Absolutely.
DR. COHN: Do others have comments about this?
MR. URBANEK: As part of our program to facilitate collaboration, one of the things that our alliance members have asked us to do is help them through the development of common tools. One of the tools that has been strongly recommended and that we are working on is a self assessment/project tracking mechanism tool.
Part of it is intended to avoid being the early implementer. Our alliance members, through their collaboration efforts, more important to them than saying here is where we are currently and here is where we need to be is, here is where we are and here is where our peers are. They want to be in the pack with the peers.
So, we are in the process of trying to develop such a tool and implement it among our Premier Alliance members, so that we can track that kind of information. We would be certainly happy to, and intend to report that back through this committee, if that would be appropriate, to kind of track the progress. That is what is very important to everyone is, what is everyone else doing.
Everyone seems to be currently standing around going, what is so and so doing, what is so and so doing. That is why Premier stepped forward and is trying to facilitate that collaboration.
MR. BLAIR: Mr. Tennant, I was also impressed with the information that you shared with us from the standpoint of group practices, MGMA.
I do understand that is group practices, not solo practices. Nevertheless, I would have thought that many of the entities within MGMA would fall below, is it 50 practitioners that would qualify to be a small practice and would have three years to implement instead of two? Is that correct?
DR. BRAITHWAITE: No, Jeff, it is only small health plans that have three years. All providers have to be compliant within two years, according to the statute.
MR. BLAIR: That answers my question as to why you didn't figure you had three years. Okay.
MR. TENNANT: It is interesting to note, in the privacy NPRM, it does state specifically that small providers will have three years.
I think it is a mistake, but it is in there in writing.
DR. BRAITHWAITE: Thank you. We intend to correct that error.
DR. ZUBELDIA: I have a question. Maybe we should get the vendor panel back and ask both panels together. It seems like Fred said that 90 percent of the provider systems or the providers are in the hands of the vendors, and there is nothing you can do about it, the vendors have to implement it.
From what I have heard from this panel, that is the situation across the board. The vendors have to do it.
The vendors are not required to do anything under HIPAA. So, how do you see that? How is it going to happen when the vendors, the only vendor requirement is the requirement from their clients, financial economic requirement, to do something.
MS. GUILFOY: There is usually a contractual requirement for the vendor to implement federally mandated legislation.
DR. ZUBELDIA: There are no penalties on the vendor.
MS. GUILFOY: It depends on how astute the client is in writing the contract. There can be penalties on the part of the vendor in not delivering the appropriate code.
MS. AIKINS: I think the other concern is, will some of the vendors just say, this is too much and, at the end, decide to close their doors. That is what we did see with the year 2000. I think from our aspect, as a provider, we are very dependent on the vendors to deliver a code that we can then take it and start testing to see if we really have what we need to be HIPAA compliant.
Of course, a lot of the health care vendors are running very old technology that I think, for some of the vendors, it is going to be a bit of a challenge to get some of the identifiers added and to meet with the EDI portion of it. I don't know, but that is definitely one of our biggest concerns, is the vendors.
MR. BLAIR: I would imagine that the vendors for the ambulatory sector would be the most vulnerable. Would you comment on that? Do you feel that that is true? Rob Tennant, do you feel the same way, that that is an issue?
MR. TENNANT: Yes, I think Rita is correct. I think it is even more apparent for the small and medium- sized group practices. A lot of them, as Rita has said, have contracted with vendors that are no longer in business. The turnover rate in that sector is enormous.
There is not much you can do if you go to your vendor and they say, I am sorry, that is just not in our plan. I mean, you will meet each other in jail, one being sued and one for non-compliance with HIPAA. But that doesn't solve the problem.
What we have been doing with our members is trying to get them to contact their vendors as soon as possible, to find out what their contract is and, if it doesn't read the way they want it to, to find out what their options are. You are absolutely right. I think it is a major problem.
MS. AIKINS: Some of the vendors, even in contract negotiations, are very reluctant for any type of HIPAA verbiage to be added to the contract.
MS. GUILFOY: With Y2K, some of our clients experienced vendors saying, this is enhanced capability and we are concerned about that with HIPAA, that they may say, this is enhanced capability and therefore you have to buy this new release at big bucks. That is one of the questions we are asking on the survey back to the vendors.
MS. TRUDEL: I would just like to follow up with Rita and Rob and ask whether you think that vendors' performance level on Y2K would be a reasonable indicator of potential success in HIPAA.
MS AIKINS: I think so, but the added-on concern is, I think we had some vendors who spent a lot of dollars and people power on becoming Y2K compliant. Are they now in a financial state to do it again. I think that is where the big question is for us.
MR. TENNANT: I think it is and it isn't. I think with the claims transactions, probably, but HIPAA goes far beyond that into the business practices. You can't just have a vendor come in and tell you how to run your security when all they know are claims. So, it is a much broader problem, I think.
DR. FITZMAURICE: A quick question. Rob Tennant, in your testimony, you give us some very specific directions. You say, disseminate the national provider identifier as soon as possible. Don't impose fees -- I can understand that. Populate the provider data base. Adopt a single federal registry to assign NPIs.
Do you have a best way you think that would happen, to assign national provider identifiers? One way is to simply put out, here is the information we want, everybody write it down on one sheet of paper and then mail it in to this one address. I suppose there are better ways.
MR. TENNANT: Mike, I think you are right. I think the problem with any of these data bases is not just getting the numbers out, but getting the updated information back. Providers move from group practice to group practice. They change locations, phone numbers, fax numbers. Things change in a hurry.
Especially if there is any kind of fee, it is going to be a disincentive to get that information. Even if there is no fee, it is going to be an incredibly difficult data base to maintain. I think our concern is that there is absolutely no money given by Congress to HCFA to either populate the data base or maintain it. If, for example, we have a two-year implementation phase-in period, but it takes five years to get everybody the NPI, we have problems.
MS. KERKOULAS: We haven't really evaluated this formally, but it seems conceptual to us that you would just assign like the tax ID or social security number or something. I am sure there are barriers to that, but that seems to simplistic to people when they first hear about the law. It seems to hard to find out why you would assign a different number.
DR. COHN: I think we need to begin to wind down here. Jeff, do you have a final question?
MR. BLAIR: Patrice, if I heard you correctly, I think you said that once the resources were committed, that you were able to implement -- I didn't recall which of the transaction standards -- within about six months?
MS. KERKOULAS: Yes, actually 835 and 276 were both -- 276 was about nine months elapsed time.
MR. BLAIR: And you did that with the existing implementation guidelines which are now in better shape?
MS. KERKOULAS: Yes, which existed at that time.
MR. BLAIR: Did you use a vendor to help you?
MS. KERKOULAS: That is the other question. We actually got a consulting group because the vendor, at the time we did the implementation, was not ready or we did not want those transaction fees. We have actually done that with all three.
MR. BLAIR: What I am trying to get a feel for here a little bit is, to be able to do that in six months is, it seems to me, fairly reasonable. I would think that things would be in place six months from now and a year from now for providers to be able to implement it in that time frame or even in a lesser time frame, especially if, by that time, some vendors are better prepared and consultants are available to help. Is this a reasonable reaction for me to have, based on your experience?
MS. KERKOULAS: I would say by transaction set, possibly. Again, we are working with limited staff. Our staff can do some multi-tasking, but we are really looking at the transaction set by transaction set, payer by payer. We haven't overcome, for example, our network hurdle. We are still using existing SNI links directly with Empire. That is some start-up that we would need to do for all payers.
I haven't really answered your question, but it is reasonable once the network infrastructure is in place, once we are confident the payers are ready for testing. We have staff lined up for testing and we really have the transaction sets prioritized. I wouldn't anticipate that, with my limited staff, I am going to try to do all 10 at once.
DR. COHN: I actually want to thank the panel. We have gone about a half an hour over time and I want to thank you for your indulgence in joining us. It has been a very fascinating discussion. We will adjourn in just a second. I do want to remind everyone that we reconvene at 9:00 o'clock tomorrow morning.
What I think we have been hearing this afternoon very clearly are the problems and I think tomorrow morning we will be beginning to hear some of the industry solutions to assist with implementation. Then we will be hearing from some of the states and other areas about some of the geographic perspectives of all of this.
Hopefully, by the end of the morning, we will be beginning to have a slightly grander and greater perspective on all of this. Once again, I really want to thank you all. With that, the meeting is adjourned for today. Thank you.
[Whereupon, at 5:28 p.m., the meeting was recessed, to reconvene the following day, July 14, 2000.]