Public Health Service

NATIONAL COMMITTEE ON VITAL AND HEALTH STATISTICS

Subcommittee on Standards and Security

July 13-14, 2000

Washington, D. C.

- Minutes -


The Subcommittee on Standards and Security of the National Committee on Vital and Health Statistics held hearings on July 13 and 14, 2000, at the Hubert H. Humphrey Building in Washington, D. C.

Members:

Absent:

Staff:

Others:


ACTIONS

1. Ms. Trudel will draft a letter based on these discussions for the September meeting.

2. Ms. Trudel volunteered to have her group look at the divergence between the 4010 data requirements and what is being captured today to do the same function.

EXECUTIVE SUMMARY

The Subcommittee on Standards and Security held two days of hearings on July 13-14, 2000 in an ongoing process focused on HIPAA administrative simplification. During the two days, the Subcommittee heard 34 presentations and talked with six panels populated mainly by early implementers from various health care industry segments, to learn the problems that they are encountering with early implementation and tools and solutions developed to address those issues.

PANEL 1: Discussion of Local Codes Issues: Delineating the Problem

Jean Narcisi, American Medical Association

Jerry Zelinger, MD, Health Care Financing Administration

Stan Rosenstein, California Department of Health Services

Richard W. Landen, Blue Cross Blue Shield Association

Tom Musco, Health Insurance Association of America

Ms. Narcisi, chair of the National Uniform Claim Committee, summarized the NUCC's view regarding the use of local codes and the magnitude of the problem. She discussed industry facilitation and recommended approaches for efficient elimination of local codes. Dr. Zelinger discussed Medicaid procedure and coding requirements from a federal perspective, explained statute regulations and policy, and addressed the question: Are special unique procedure codes needed? Mr. Rosenstein conveyed how the proposed elimination of local codes will impact on Medicaid's ability to perform its business function, provide care to beneficiaries and reimburse providers. He provided an overview of how some codes are used in California and offered global comments on problems associated with imposing standard coding. Mr. Landen detailed ways the Blue plans use local codes and described how they are a de facto part of proper contract administration. He contended legitimate business purposes require them and urged development of a user-friendly way to create unduplicated national codes. Mr. Musco explained how private insurers and other health programs depend on local codes to meet many needs not adequately advanced any other way. The panelists discussed the need for timely processing of codes and considered ways local codes might be consolidated in the interim.

PANEL 2: Panel Discussion of Local Codes Issues - Examination of Tools and Processes that could lead to a Solution

C. Kaye Riley, Health Care Financing Administration

Lisa Doyle, Wisconsin Medicaid

Allen McBride, MD, Blue Cross Blue Shield of Michigan

Bart Killian, Utah Health Information Network

James Y. Marshall, American Dental Association

Ms. Riley provided an overview of the alphanumeric Health Care Financing Administration Common Procedure Coding System process. HCPCS 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. Lisa Doyle described efforts taken by the National Medicaid EDI HIPAA Work Group, detailed difficulties with current procedure code review and approval process, presented recommendations to address problems created by the elimination of local codes, and discussed potential tools and processes that could lead to a solution of the issue. Dr. McBride, the senior associate medical director for Blue Cross Blue Shield of Michigan, presented an overview of what one plan accomplished. Mr. Killian explained that UHIN (a private/public partnership of state government agencies, provider organizations within Utah, major corporations, and all but one of the domicile payers) determined early to eliminate as many codes as possible; the providers mandated it. The state Medicaid agency established Y codes and brought UHIN through the process. Mr. Marshall stated that ADA fully supports the goal of eliminating local codes by HCFA as soon as possible and recommended that it have input along with other data maintenance bodies in this process. The panelists considered that talking about local codes involves talking about a multitude of things from diverse, sometimes disparate, perspectives and that there appeared to be a profound blurring, anomaly or breakdown in communications.

PANEL 3: Discussion of Early Implementers -- Vendor/Clearinghouse Perspective

Deborah Meisner, WebMD/ENVOY

Don Bechtel, HDX and Association for Electronic Health Care Transactions

John W. Carter, Healthcare Administration Technologies, Inc.

Tom Grove, Superior Consultant Company

David Sweigert, Open Network Technologies, Inc.

Ms. Meisner described the impact of HIPAA from a clearinghouse perspective: the effect on both customers and the clearinghouse. Mr. Bechtel shared concerns and advice as an early implementer of administrative simplification. As HDX nears its 10th year, it processes over 7. 5 million transactions per month for some 600 provider customers and more than 300 payers. One of the most important benefits of the HIPAA standardization, Mr. Bechtel said, is uniformity of the data content of business transactions. Mr. Carter shared experiences from his more than 13 years in the clearinghouse industry developing institutional and professional EDI interfaces. Despite obstacles he identified, Mr. Carter supports the X12 transaction formats as the standard for health care EDI. He predicts the sharp learning curve will level off and the flexibility of open standards will provide interoperability pay off. Over the past year, Mr. Grove has worked with dozens of small and major e-commerce vendors in the health care space. He shared their perspectives, noting there is uncertainty about how to implement security measures and recommended options for relieving confusion. Within the last six months, Mr. Sweigert’s firm has enabled nearly 12 organizations within the Blue Cross Blue Shield Association of Plans to implement services that accommodate requirements in the HIPAA proposed rule on security. He presented lessons learned from assisting customers prepare for the implementation of the HIPAA final security rule. The panelists commented on implementation procedures, sequencing and time frames and what needs to be done to bring everyone into compliance.

PANEL 4: Discussion of Early Implementers – Provider Perspective

Rita Aikins, Providence Health System, Oregon Region

Gary Levine, Medicine Shoppe, International

Robert Tennant, Medical Group Management Association

Helene Guilfoy, IMG Healthcare Consultants

Patrice Kerkoulas, Memorial Sloan-Kettering Cancer Center

Fred Urbanek, Information Technology Association Services, Premier, Inc.

Ms. Aikins, the information privacy security officer for the Providence Health System, Oregon Region, presented Providence’s experience with HIPAA and outlined what they have done so far to comply with the standards, emphasizing the importance of a complete asset inventory and a risk management methodology and assessment. Mr. Levine presented, from a pharmacy provider’s perspective, implementation issues related to the final rule. He stated issues and concerns that are being discussed in the pharmacy industry, should they be required to move to a new version of the telecommunication standard. Mr. Tennant, who is on the board of directors of WEDI and NUCC, a member of the executive committees of the HCFA security summit and the Strategic National Implementation Process, spoke from the perspective of the group practice. He discussed implementation issues, concerns and expectations, general obstacles and roadblocks stemming from HIPAA provisions, and discussed how the Federal Government can assist more productively in the implementation process. Ms. Guilfoy reported on how providers are implementing HIPAA, based on statistics readiness assessments of over 220 health care systems, including 150 hospitals, academic medical centers, large national health systems and IDNs across the nation. She outlined how a reliable HIPAA implementation consists of four phases: awareness of HIPAA, what needs to be done, and in-house training; an initial readiness assessment; remediation; and implementation. Ms. Guilfoy described the disparity between the current status of health care systems and the compliance issues and stressed that the solution requires major coordination between providers, vendors and payers. Ms. Kerkoulas emphasized the importance of complete testing. She emphasized: identify everyone involved and plan out the project together; develop a workflow analysis, determine how the interactions with the payer will occur and how automated transactions will be posted; streamline the reengineering for cost elimination—both plan for and prove it with before and after flow charts. Mr. Urbanek discussed his involvement in efforts to facilitate collaborative solutions for HIPAA among Premier's 215 independent not-for-profit health systems. He noted the necessity, due to personnel and financial resource constraints, for compliance activities to be efficient and cost-effective--and observed that no organization had “wished” to be an early implementer. He suggested incentives to motivate provider organizations. The panelists discussed the issue of vendor compliance and the need for a comprehensive assessment of industry implementation.

PANEL 5: Discussion of Early Implementers - Industry Solutions

Christine Stahlecker Blue Cross Blue Shield Association

Larry Watkins, Per-Se Technologies

Jon Zimmerman, HDX

Lisa Gallagher, Exodus Communications

Mary E. Kratz, Internet2

Gary A. Beatty, Washington Publishing Company

Ms. Stahlecker discussed from a payer perspective the need for leadership in the implementation of HIPAA standards, outlined the role undertaken by WEDI strategic national implementation process, and requested the support of NCVHS. She presented “lessons learned” in a proof of concept project conducted by a virtual project team made up of Medicare contractors, contributing authors of the implementation guide, partner providers for each contractor and vendors supporting those providers. Ms. Stahlecker discussed steps taken to initiate a collaborative effort surrounding HIPAA implementation. Mr. Watkins explained that WEDI formed the Strategic National Implementation Process task group (SNIP) to assess industry wide HIPAA implementation readiness, and bring about the national coordination necessary for compliance. He mentioned major concerns that SNIP can help mitigate: (1) a deployment schedule for the transactions and code sets that will bring about industry-coordinated ordering, timing and grouping of transaction implementation, and leverage to encourage trading partners to adopt this schedule (2); coordination on definitions, clarifications and work-arounds (ambiguities and gaps exist in the X12N implementation guides and data dictionary) to bring solutions for implementation (3) indicate appropriate levels and methods of testing for trading partners.

Mr. Zimmerman, as senior manager of HIPAA initiatives for shared medical systems, has engaged in over 100 provider, payer or industry forums or discussions: many working directly with the health systems senior management team to kick off HIPAA preparation initiatives. He discussed how the industry can cope with HIPAA's mandates in an economically challenged, highly fragmented, complex, technologically and culturally diverse environment. Ms. Gallagher spoke for the Forum on Privacy and Security in Health Care and advocated the use of the common criteria (ISO standard 15408) as one approach to the specification, evaluation and certification of health care solutions. The forum is working to have the common criteria technology and methodology recognized by accrediting organizations, insurers and others. Ms. Gallagher encouraged HHS to proactively participate.

Ms. Kratz, manager of the Internet2 health sciences, discussed the need to ensure that the Internet becomes a suitable, ubiquitous medium to support health applications. Internet2 Health Science initiatives work collaboratively with academia, government and industry to ensure that emerging technical capability are suitable for health and biomedical applications. Kratz noted issues faced by early adopters of new technologies including Quality of Service, strong authentication (IP Security, Public Key Infrastructure), medical middleware (authorization and directory services), and distance education. Early adopters of HIPAA regulation seek not to solve problems, but to recognize opportunities that will serve to transform our industry. The fundamental limitations won't come from technology, but from the medical care system's ability to adapt to new technical capabilities. The Internet2 community serves to ensure that the needs of academia, government and industry are addressed through advanced technologies. Internet2 Health Sciences provide an active role in defining HIPAA conformance to advanced technologies.

Mr. Beatty discussed compliance verification (a process to ensure standards are implemented in a uniform manner consistent with the implementation guides) and tools available to the health care industry for testing. He recommended that implementers coordinate with trading partners, everyone doing their own testing using a neutral third party first, so they can validate the ability to generate HIPAA-compliant transactions. Then go into a parallel stage and parallel testing, conducting business both by established means (paper, phone) and the electronic environment. Then, finally, go live between business partners. The panelists observed people are still doubtful and that the economic value in implementing the transactions needs to be communicated clearly in order to elicit the level of involvement and cooperation necessary to bring about deployment.

PANEL 6: Discussion of Early Implementers – Geographic Perspective

Walter, Suarez MD, MPH, Minnesota Health Data Institute

W. Holt Anderson, North Carolina Healthcare Information and Communications Alliance, Inc.

Elliot M. Stone, Massachusetts Health Data Consortium, Inc.

Eric Bartholet, Computer Science Corporation, Worldwide Healthcare

Mark Gordon, Thomas Edison State College

William O’Byrne, Department of Banking and Insurance, State of New Jersey

Bart Killian, Utah Health Information Network

Dr. Suarez described stateside workshops and user groups in Minnesota and how early implementers help newcomers begin. As a community, payers and providers strive to reach consensus on a standard guide. Groups work on different activities, then exchange experiences and share results. The goal is to begin full implementation of the transactions by 2002. Mr. Anderson discussed how focus and work groups facilitate implementation. He explained that contractor resources in North Carolina had been lined up based on when issuance was expected; delay on the final rules has everyone locked out of budget cycles and resources. He recommended phasing in the rules; stating they cannot be implemented locally all at once. The lack of resources is a real issue. Mr. Stone emphasized the importance of providing information and tools for project leaders at the provider groups. MHDC utilizes a CIO forum, Web site and weekly e-mails. Its library researches members’ questions about HIPAA and builds materials around the answers. MHDC has fostered two collaborative organizations: the New England Health Care EDI Network and the Community Health Center Network. Mr. Stone encouraged the Committee to prompt HHS to develop partnerships with regional and local organizations striving for compliance with HIPAA standards. Mr. Bartholet discussed technical and process-related issues that had to be overcome in implementing the HIPAA transactions for NEHEN. One of the biggest challenges, he noted, is that few vendors fully support the HIPAA transactions. He urged the Committee to explore ways of encouraging vendors to make their products HIPAA compliant “sooner, rather than later. ” He suggested HCFA might compile and disseminate information on vendor compliance efforts.

Mr. Gordon discussed New Jersey's proactive approach to health care administrative simplification. The Healthcare Information Networks and Technologies (HINT) study (which found that EDI technology and national health care transmissions standards could result in $760 million in annual cost savings/avoidance) suggested pilot projects and legislation to achieve healthcare administrative simplification. As a result of the HINT study's findings and recommendations the New Jersey State legislature, with bi-partisan leadership support, the HINT legislation (S-323/A2119) was unanimously approved. Governor Whitman signed the HINT legislation into law on July 1, 1999 (P. L. of 1999, Chapter 154). The HINT law promotes EDI technology, prompt payment of healthcare claims along with HIPAA national standards. Representing the New Jersey Department of Banking and Insurance (DOBI), Mr. O'Byrne, a regulatory officer responsible for drafting the rules and regulations, discussed New Jersey's implementation of HINT. The law requires DOBI to set dates for the implementation of a system for the electronic receipt and transmission of health care claim information by payers who do business in the state of New Jersey. Unless excused or extended, 12 months after the adoption of DOBI's rules, all payers will be expected to handle claims transactions electronically.

UHIN’s coalition includes every hospital, about 99 percent of the physicians, and all payers but one in Utah. Gaining initial trust and buy-in was difficult, Mr. Killian said. UHIN strove for consensus and put itself at the center as everyone’s ally and arbitrator. Mr. Killian emphasized the need to position a process to identify and resolve issues quickly. UHIN also leveraged the synergy of the group, took small measured steps, and experienced successes. With every step, UHIN demonstrated that its partners could recover their initial investment in less than six months. The panelists discussed how employers, who largely pay for the health care process, are the driving force with venders, and that, financially, smaller group practices are most impacted by implementation.

DISCUSSION: NEXT STEPS

Dr. Cohn summarized what the subcommittee had learned. Among the issues were problems with the external code sets, enabling a timely process for getting codes, the need for ongoing comprehensive assessment of the industry’s progress towards implementation--including closely tracking a number of issues and obstacles, finding ways to make information available to the providers and the payers so that they can make intelligent choices about compliance testing and other essential matters.

Dr. Cohn noted the need to ask the Secretary to secure adequate funding in HHS to facilitate implementation occurring in an expeditious fashion. Dr. Fitzmaurice discussed alerting the Secretary that delaying publication of final HIPAA regulations had reduced credibility and lost resources budgeted for HIPAA implementation in 2000--and, quite likely, in 2001.

It was noted that the problem of proliferation (local codes) might be surfacing again with implementation guides. A process--MOU--had been agreed to, but states were developing their own variations. The data requirements were changing: the 4010 asked for more data than is being captured today to do the same function. Ms. Trudel volunteered to have her group look at what those gaps exactly are. A discussion about a work plan outlining next steps for the PMRI standards was planned for September.

Participants discussed possible agenda items for the October hearing, including input from the vendors regarding their issues and how far they are in terms of HIPAA, a panel on ICD-10 with a discussion on the standards for digital signature, updates from this hearing’s panelists offering industry assistance, and a discussion about the first report of injury (should anyone come forward). An upcoming letter to the Secretary was also placed on the agenda. Time will be reserved for inquiring about anything else to be recommended.


DETAILED HEARING SUMMARY

Day 1: July 13, 2000

Dr. Cohn convened this hearing of the Subcommittee on Standards and Security of the National Committee on Vital and Health Statistics (NCVHS) to track implementation of the administrative simplification provisions of HIPAA, identify issues and barriers, and recommend ways to possibly mitigate those issues. Dr. Cohn stated the purpose of this hearing: to talk with early implementers from various health care industry segments, learn about problems encountered, and tools and solutions developed to address them.

Dr. Braithwaite gave an update on the progress of the final regulations. HHS succeeded in having the first final regulation, the transaction and code set rule, ready to publish by the end of June. Bureaucratic “stumbles” still must be balanced before it can be put out in the Federal Register. Publication is imminent. Other regulations are stacked up behind it, several drafted and ready for the publishing process. HHS is working hard to bring out the privacy regulation.

Dr. Cohn introduced the first panel.

PANEL 1: Discussion of Local Codes Issues: Delineating the Problem

Jean Narcisi, American Medical Association.

Ms. Narcisi noted that the difficulty of converting Medicaid local codes to national procedure codes was raised at NUCC’s February meeting; members stressed how the issue of local codes also affects private payers and providers. NUCC contends the development and use of local codes is in direct conflict with the intent of the standards addressed by the administrative simplification portion of HIPAA. Ms. Narcisi asserted the need for a reliable national process for recognition, establishment, and maintenance of local or regional codes and their conversion into a national system. She suggested that NCVHS and DHHS might survey payer and provider groups regarding current uses of local codes.

NUCC’s recommendations include: (1) if local codes are adopted as part of a standard national code set, modifiers should also be included, (2) if temporary codes are established for local or certain other codes, a mechanism should be in place to move them into a national code set--temporary codes should “sunset” within a specified period of time, (3) code sets should be technologically independent of computer platforms and transmission protocols. Any proposed modifications to the national code set should be handled through the respective committees maintaining the code sets; the review process should include appropriate affected parties.

HHS proposed that NDC codes become the national standard code set for drugs. Ms. Narcisi conveyed NUCC’s view that this could create extensive system changes for providers and payers without sufficient benefits.

The issue of the J codes versus NDC codes needs more evaluation. NUCC recommends that NDC codes 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 NDC codes exclusively is further researched.

NUCC supports HIPAA’s position that those receiving electronic transactions covered by the transaction standards must be able to receive and process all standard codes, without regard to local policies regarding reimbursement, coverage policies, or need for certain types of information that are not part of a standard transaction. However, NUCC believes that the final rule should 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. The final rule should also declare that the version of the code set applicable to a calendar year is the version specified by the developer. Ms. Narcisi noted that an effective national maintenance process needs to be established for five other code sets used in electronic transactions: place of service codes, the claims adjustment reason codes, claims status codes, remittance advice remark codes, and provider taxonomy codes. Ms. Narcisi observed that the maintenance process is not consistent for POS codes. HCFA maintains these codes that identify the location where services were performed.

The code set for claims adjustment reason codes is maintained externally from the HIPAA transactions and implementation guides. The committee (individuals from the X12 community) has no formal governing protocol. Third-party payers greatly outnumber providers who have difficulty getting changes in nomenclature to a code approved. The same committee maintains the claim status code set. Remittance advice remark codes are maintained by HCFA but may be used by any health care payer when they apply. One individual at HCFA manages all maintenance of the code set. The original purpose of the provider taxonomy external code set was to codify provider type and area of specialization for all medical related providers; however, the provider taxonomy code list is inconsistent. Again, there is no formal governing protocol and the process for maintenance is not consistent. NUCC believes all five code sets should be considered data content and maintained by the key parties involved in health care electronic transactions, payers and providers.

In summation, Ms. Narcisi stated that a reliable process must be established in order to effectively manage a national system. The utility of these local code sets may go beyond HIPAA transactions. Utilization in the public health community is likely if they are broadened to include codes for maternal and child health, prenatal care and other community health services. The public health community is separate from HIPAA, but there is a desire to standardize transactions and code sets for public health reporting. It would be more efficient and cost effective if the same code sets were used for HIPAA and public health transactions.

NUCC, which includes representatives of standards development organizations, regulatory agencies, public health and the National Uniform Billing Committee, contends that it would be the appropriate committee to oversee the maintenance of these five code sets. 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.

Jerry Zelinger, MD, Health Care Financing Administration

Mr. Zelinger presented an overview of the Medicaid program, explained Medicaid procedure and coding requirements from a federal perspective, discussed statute regulations and policy, and considered whether, from the federal perspective, the Medicaid program needs special unique procedure codes.

The Medicaid program consists of 50 quite different programs with wide state-to-state variation. States have considerable flexibility in developing program eligibility criteria, designing benefit packages and determining payment for covered services. Minimal federal guidance is given on the procedure codes Medicaid providers use on claim forms. Neither the Medicaid statute nor federal Medicaid regulations specify coding requirements.

Federal policy is that states use HCPCS codes in their transactions. Updates are sent annually. States have been encouraged to create local codes to meet their own unique needs. Most state Medicaid programs use local codes to identify services for which they pay. An estimated 40-50 percent of state Medicaid fee-for-service transactions use local procedure codes. Some states only use local codes.

HIPAA will require state Medicaid programs to eliminate local codes. Mr. Zelinger raised three questions. How different and unique are the services covered by the Medicaid program?To what extent do state Medicaid agencies need special unique codes to run their programs? Will standard sets of codes used by other insurers be sufficient?

States frequently use local codes that replicate national codes; these can be eliminated under HIPAA. Other local codes reflect services covered by Medicaid and other payers where no national code describes the services. Examples: (1) 17 state Medicaid and Medicare programs provide services via telemedicine, (2) new and emerging procedures and technologies covered by state Medicaid programs and other payers.

A substantial number of local codes are used to describe special and unique services covered by the state Medicaid program, but not generally covered by other health insurers: (1) Some 250 Medicaid home and community-based waiver programs operate in all but one state. They provide coverage for a wide range of non-medical type services including air conditioners and home and vehicle modifications. Companion and attendant care for the elderly, disabled, mentally retarded and developmentally disabled individuals are also among these programs. Medicaid home and community-based programs are expected to increase dramatically with the Supreme Court’s Olmstead decision. (2) School-based health services provided to disabled children under the Individuals with Disabilities Education Act, enable them to receive an appropriate public education. (3) Other services commonly covered only by state Medicaid programs include: transportation to and from health care providers, case management services, and health education and counseling services that are part of Medicaid enhanced pregnancy-related services. Procedure codes to describe these unique services enable state Medicaid agencies to run their programs.

· Stan Rosenstein, California Department of Health Services

Mr. Rosenstein stated that the proposed elimination of local codes under HIPAA would impact on Medicaid's ability to perform its business function, provide care to beneficiaries, and reimburse providers.

As the predominant payer of health care services for the country's most vulnerable populations, Medicaid provides services generally not recognized by commercial insurance or other public-supported programs. Such programs require services and supports not currently identified in Level I or Level II of HCPCS. These non-traditional services, provided to avoid more costly and less desirable traditional services and allow for payment ordinarily provided by family members, are a growing critical issue with the Olmsted decision.

In addition to creating codes for non-traditional services, state Medicaid agencies rely on local codes to support unique business needs. Mr. Rosenstein discussed how local codes: (1) enable agencies to manage the care provided to patients with case management and care coordination fees, (2) provide the ability to bundle services, such as a well child exam, appropriate to provide in a single visit, (3) provide specific information about the items requested (individual parts for durable medical equipment) enabling fast replacement, processing and automation, (4) provide detailed information necessary to implement the appropriate anti-fraud and abuse edits and audits, (5) provide a level of detail that simplifies the fee calculation by eliminating the need to manually price claims and enables faster payment of services.

Mr. Rosenstein emphasized that state Medicaid agencies rely on local codes to conduct business. Services provided under Medicaid have multiple funding sources and varying levels of federal reimbursement. Local codes allow states to link payments to funding sources and determine the percentage of federal reimbursement for individual services. States must be able to meet requirements imposed by state and federal legislatures. HCFA requires states to submit numerous federal reports that can be generated only if specific levels of detail are available. State legislatures mandate coverage of specific services, which often have no corollary in the commercial market. When state laws are passed, some responsive mechanism is needed to provide a coding structure for new services; deadlines are tight for implementation of legislation.

California is a heavy user of local codes. Local codes: (1) provide better patient access to providers of care, (2) allow providers quicker, more consistent pricing and payment for services, (3) enables automatic claims pricing, saving the time and cost of manual review, (4) provide the capability to pay some providers a different reimbursement rate than the generic CPT 4 HCPCS codes, (5) allows better tracking of service utilization and greater control on fraud and abuse, (6) help motivate providers to offer care for MediCal beneficiaries--California has significant access problems and codes are used to promptly pay providers and maintain access, (7) enable faster response times in providing new treatments. As recent changes in cancer treatment come on stream, the agency has been able to establish local codes and pay for them as they hit the market, (8) are critical for effective use of waiver programs that have a wide variety of requirements mandated by state legislation.

Mr. Rosenstein emphasized that providers and consumers frequently initiate the need for local coding. Recently, emergency room doctors asked for increased reimbursement rates for on-call physicians. No existing coding structures could enable that. Local codes made it possible for California to reimburse on-call physicians and offset a critical shortfall.

Prohibiting Medicaid agencies from using local codes would preclude the ability to respond to providers and consumers and hamper the ability to process claims and data effectively. Provider reimbursement would cease to be available for many existing services. States would not be able to adopt new services or program developments if there was no code to acknowledge that program or service in the EDI world.

Major changes in the claims processing system would be needed by the states and by the providers. Additional processing steps would have to be added to accomplish what the local code accomplished in one step. It would be costly in terms of implementation and operation. These changes would affect the performance of claims processing and cause delays in payment to providers.

Standardization may create barriers to designing systems best suited for the state, and undermine the state's ability to administer the Medicaid program. States are particularly concerned about the impact the elimination of local codes would have on closed loop transactions: business arrangements created and operated by state Medicaid agencies that pay for the provision of services to certain limited populations by certain limited providers. Medicaid is the only source of payment for these specialized services.

Richard W. Landen, Blue Cross Blue Shield Association

Mr. Landen stated that the Blue Plans use local codes for five major reasons: new technology, new drugs, reporting compliance with private contractual arrangements, fraud and abuse protection and detection, and services not otherwise classified. For the latter, BCBSA negotiates or requires use of proprietary codes. As national coding systems create codes for services not currently classified (example: infusion services), local codes could be migrated and deleted. If not incorporated into national systems, those codes will still be needed to achieve business purposes and requirements.

As CPT tracking codes are successful, they can be used for new procedures and quality measures, assuming tracking codes will be fast enough for the Blue plans. If national drug codes are used, they will be on hand as new drugs become available. In theory, NDC codes could replace local drug code. Volatility and frequency of update issues will impact all code lists under the HIPAA administrative simplification.

Mr. Landen emphasized that local, regional and proprietary codes are a de facto part of proper contract administration: (1) Codes that are too generic may present loopholes for fraudulent or abusing billing practices, (2) Services and supplies are negotiated as part of specific contracts; negotiated situations or conditions affect payment rates. Such plan-specific contractual arrangements do not necessarily lend themselves to national coding. (3) HIPAA legislation does not outlaw contractual relationships. HIPAA transactions must be capable of transporting the information required to properly administer those contracts.

BCBSA actively participates in major efforts focusing on industry standardization in health care administration, both inside and outside HIPAA. BCBSA agrees with the problems as defined by NUCC, but doesn’t view the NUCC code solution as the only viable solution. BCBSA remains committed to working with all organizations in finding 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.

HIPAA and non-HIPAA electronic transactions utilize codes from hundreds of independent sources. Those sources are not collectively exhaustive. There are needs for codes not found on any current list. Legitimate business purposes require the creation of new codes for many reasons and uses.

A user-friendly way to create unduplicated national codes must be established. Creation of codes must (1) meet state, local, regional, private business contracts and other non-national business purposes and (2) move new codes into the HIPAA-approved code list and transactions for national use. Mr. Landen offered the single Web site model of the HIPAA change request memorandum of understanding as an appropriate model for code requests.

Mr. Landen suggested that the new infrastructure would most likely involve a consortium of coding bodies that expanded on the five specific code lists Ms. Narcisi cited. It would include a centralized virtual library and verification of a unique business purpose before any new code was issued--preventing duplicate or multiple code assignments. It would also assure 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 within weeks. Codes could be used immediately in non-HIPAA transactions and proposed for inclusion in the next round of HIPAA transactions or HIPAA code lists.

Tom Musco, Health Insurance Association of America

HIAA represents a diverse group of private insurers and health plans. Its 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. Mr. Musco stated that all express a consistent need to accurately identify the nature and timing of different services, and who renders those services—even if, as frequently happens, no code exists to express them.

Local codes meet many needs: most often to describe non-physician services, supplies, equipment and drugs not yet accurately described through another system. Examples include: (1) serving as administrators for state Medicaid agencies; arrangements with groups of providers offer unique services that must be coded,(2) often the state Medicaid agency or the plan administering a program wants to know detailed information about services provided their members,(3) complying with state-mandated benefit laws, varying from state to state, that require their own codes, (4) state agencies have developed many codes to describe the kinds of services that they need to collect for their enrollees,(5) administering programs or extensive plans for large employer groups with specific needs and demands; specific codes must be developed to accommodate client’s needs,(6) covering variations of a service at different levels of reimbursement; these variations must be tracked separately. Example: a code exists to describe an air ambulance service, but a particular company faces a large cost difference between vehicle types; so a code was developed to differentiate between propeller-driven and jet-driven aircraft. (7) when there is a high volume of claims for a particular service not routinely described in an existing code level, codes or unique modifier describe the service, supply or specific type of equipment (example: durable medical equipment. )Insurers may want to pay at a negotiated price, avoid manual review, or identify frequency and volume of billings.

State mandated benefits for privately insured populations also create a need for coding that cannot be met with the existing levels of code sets. In Georgia, the state mandated coverage of fitness trainers; Indiana requires coverage for surgical procedures related to morbid obesity; California has mandates for the coverage of PKU formula and food. Many states have implemented mental health parity laws that require coverage of a range of non-physician providers, including social workers, marriage and family counselors and other providers.

BCBSA developed a detailed list of codes (a subset of these temporary national non-Medicare codes was published in the HCPCS 2000 book) utilized by its member plans to describe services that are not currently coded. 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, more private insurers are using them. Mr. Musco noted that the NDC codes might replace the J codes in the HCPCS system. He suggested that these and the temporary codes for new technology would expand the ability of private insurers to code for new services.

If local codes are eliminated, the providers and payers will lose the ability to effectively communicate and efficiently process claims or bill for certain services that most private insurers are willing to pay. Claims for hundreds of types of drugs, services, equipment and supplies would have to be processed under a miscellaneous code, clearly an effective and inefficient means of billing and payment.

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. 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.

Discussion

Dr. Zubeldia led off with two questions: (1) How long does it take to put a code in place, and (2) How might local codes be consolidated as an interim measure?Mr. Rosenstein urged that there could be a lot of consolidation, but observed that local codes will still be necessary. A lot of codes are not in any of the code sets. He added that it had been possible to get a new transaction set through committee and approved in a matter of weeks. Ms. Narcisi explained it could take up to a year for the assignment of a HCPCS code at the national level when there are appeals. Without appeals, it could take a few months. Mr. Landen noted that HIPAA creates a distinction between code sets internal and external to the transaction set. Codes that are internal need a very different implementation and approval process. Lead-time is the same, but the internal HIPAA code sets also require the NPRM process, a minimum of another 12 months.

Mr. Landen observed that everyone had acknowledged that diverse coding needs were not being met on a coordinated national basis and emphasized the need for a coordinated system to avoid duplication. Dr Cohn mentioned that he was hearing basically three issues: (1) other code sets and how to best handle them. (2) timely process for getting codes, (3) things that are not part of agreed-to code sets--where are the boundaries?

The committee discussed whether specific code sets were internal or external and how to maintain them. The full transcript is posted on the NCVHS Web site. Mr. Rosenstein explained how working closely with providers added a level of detail to coding that avoided manual pricing. For example, wheelchair codes are generic. Because CDHS serves a different population, the need was more definitive. HCPCS code and Medicare have a generic code and pay $6,000 per chair; CDHS pays up to $27,000. More detailed codes enable computer pricing.

Dr. Zubeldia cited concern about the orthogonal explosion of codes and the need to combine different types of service within the same code set. The fact that CDHS pays $27,000 for a wheelchair might not preclude a national code, Dr. Zubeldia suggested. Other states could deny or pay at a lower level.

Members discussed whether some local codes express private contractual relationships and if promoting those codes to a national level would impact on relationships with competitors.

It was pointed out that states could need a specific code because legislation requires payment of a service. Ms. Narcisi advised that emergency relief is available through the MOU process, if there is a legislative need for a change to a transaction set. She cited a legislative mandate that went through the National Uniform Billing Committee. There was no way to report in the transactions the patient's reason for visiting the emergency room. Code was added to a code set NUBC manages. It took a couple of months for review. How long depends on the meeting schedule. There was no need to change that transaction, which was finalized in preparation for the release of the final rule.

Mr. Landen responded to the question: Who establishes codes?Private industry negotiates. The federal programs issue a set of regulations: “Thou shalt use these codes. ”From the National Uniform Billing Committee perspective, NUBC has a series of state level advisory bodies called SUBCs, state uniform billing committees. Recommendations from the states go to the national committee. States vary. Some have their own SUBC. Representation and voting balance vary. Some states are payer, provider, or state agency dominated. The NUCC does not have these kinds of state organizations. Mr. Landen urged that the challenge in this HIPAA environment is to bring structure and coordination to this process.

Dr. Zelinger stated that if there is a state mandate or a state Medicaid program or a private payer decides they want to cover a product and there is not a national code, there has to be built in a mechanism so that they begin coverage as soon as they need to. Dr. Zubeldia asked if temporary local codes could be an interim solution. Mr. Rosenstein responded they could be. “It means two sets of changes for our provider and us, but it could be workable.”

Mr. Rosenstein mentioned that MediCAL, working with consumers and providers to add AIDS resistance testing as a benefit, “brought up” a code quickly. They had a mandate and program up in one month. Dr. Cohn noted what he was hearing from everyone was a need for a timely process.

PANEL 2: Panel Discussion of Local Codes Issues - Examination of Tools and Processes that could lead to a Solution.

C. Kaye Riley, Health Care Financing Administration

Ms. Riley presented an overview of the alphanumeric HCPCS process. HCPCS includes three levels of codes, as well as modifiers. The code sets include the modifiers.

Level I HCPCS, or current procedural terminology codes, consist of five position numeric does and associated terminology that describes specific professional services and procedures. Developing and maintaining the CPT codes is the responsibility of the American Medical Association.

Level II 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 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.

The HCPCS 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. Information about the process and a copy of the recommendation format may be downloaded from the Internet at www. hcfa. gov/medicare/hcpcs. htm.

The HCPCS database (except for the D codes) is updated annually. The D codes are updated by ADA every five years.

The G, C, K and Q code sections have been designated for HCFA to establish codes needed to identify professional services, procedures, products or supplies to implement specific Medicare or Medicaid policies. C code section permits implementation of Section 201 of the Balanced Budget Act of 1999. C codes identify items for the hospital outpatient prospective payment system, are product specific, and only valid for Medicare on claims submitted by the hospital outpatient departments. The durable medical equipment regional carriers or the DMERCs established the K codes. The G codes are assigned by HCFA to identify procedures and professional services. The Q section contains codes for drugs, biologics, and other medical supplies not identified by the national permanent codes, but needed based on Medicare internal operating needs. 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 I sections have been designated for use by the private sector by the HCPCS national panel. S codes, first published in the 2000 HCPCS update, 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 was altered by some specific circumstance but did not change the original description or its five-position code.

The level III HCPCS 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 not represented in Level I or Level II codes.

Several years ago, Medicare contractors were asked to review local coding practices and eliminate as many local codes as possible. Code sets targeted for elimination include all local codes: duplicating national codes; not used in the last 18 months; representing specific brand-name products; established strictly for internal operating needs; never published; never submitted on a claim form; coded through other fields such as place of service, by ICD-9 diagnosis codes, or by changes in the units columns. In 1995, the printout of the local codes filled a four-inch binder. The 2000 local code HCPCS printout is less than a quarter-inch thick.

The regional offices are petitioning Medicare contractors to reduce or eliminate remaining local codes and use national codes or modifiers. Contractors will be asked to review the update and eliminate as many remaining local codes as possible. If any codes remain, contractors will be instructed to prepare and submit national coding modification requests and supporting documentation. Regional offices will determine if the code is needed. The HCFA central office and the HCFA HCPCS work group will review final coding request and make a coding decision or recommendation to the national panel.

Requests are placed on the next available work group agenda. A work group agenda is usually scheduled every month. There is a three-week lead-time. If a decision is made to establish a HCFA code, that code could be established within a couple of days. It then has to be made operational, reviewed, and then recognized by the data systems.

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. The HCPCS Internet Web site was established, 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. The HCPCS national panel agenda, the tracking numbers and all the coding requests as received are posted, providing an opportunity for public review and comment. The 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. A direct electronic link, HCPCS@hcfa.gov is provided for anyone with questions or comments regarding the alphanumeric HCPCS coding process.

Lisa Doyle, Wisconsin Medicaid

Ms. Doyle provided an overview of the efforts initiated by the National Medicaid EDI HIPAA work group. NMEH was formed by the National Association of State Medicaid Directors to give states a forum to assess the impact of HIPAA's administrative simplification on the Medicaid systems. Some 40 states are actively involved. A subgroup is tasked 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.

NMEH maintains a strict criterion for local code research and what is to be done prior to submission to New York State. First, find all local codes. Determine if there are any existing national codes. Third, eliminate any codes not billed in either calendar year 1999 or 2000. Submit the rest. Submissions received by July 31, 2000 formed the basis of a national local code database.

Local code and procedure code modifiers are prioritized by volume per category. All procedure and procedure code modifiers are submitted in priority order, to HCFA, for inclusion in the appropriate national coding structure.

Ms. Doyle discussed difficulties with the current procedure code review and approval process. If all the Medicaid processes currently being supported by local codes must be included in the Level II HCPCS, she asserted the demand on the HCFA HCPCS work group would be immense. NMEH questions whether the existing quarterly review process and the HCFA resources will be adequate to meet this demand. Ms. Doyle expressed concern 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.

The process for adding new procedure codes does not accommodate the numerous rapid turn-around requests that states have. A basic concern is that state Medicaids have a different time frame than the HCPCS review process in regard to state legislated services and the two won't mesh in the review process time frames.

Ms. Doyle acknowledged that the goal of standardization is logical in today's electronic world, but added that it may not make sense in all situations. NMEH believes there is little value in imposing national codes on the closed loop business of Medicaid.

Ms. Doyle presented recommendations that address problems created by the elimination of local codes under HIPAA(1) she noted that it is critical that Medicaid agencies become part of the process. The business needs of Medicaid differ from those of commercial insurers and Medicare. NASMD should be offered a direct voice on NCVHS and the HCPCS alphanumeric editorial panel. Both already include representatives from the commercial insurance sector. (2) timing is critical in establishing procedure codes and related nomenclature, but it should not drive effective dates of policy. State legislation and approval dates for federal waivers drive effective dates, which, in turn, create the need for local codes today, Level II codes in the future. (3) The alphanumeric editorial panel that advises HCFA meets three times a year. This is not adequate for the needs of the states. (4) 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. (5) 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.

Ms. Doyle reiterated that elimination of local codes under HIPAA presents a challenge of huge proportions. It will take a great deal of collaboration between HCFA, the state Medicaid programs and the entire health care industry.

Allen McBride, MD, Blue Cross Blue Shield of Michigan

Dr. McBride presented what one BCBS plan has been able to accomplish within the field of local codes. BCBSM historically has used four different code sets to report and process professional claims: HCPCS Level I and II codes, the BCBS Association's S code system--and, when these could not meet coding needs, BCBSM’s own local X, Y and Z codes.

There was always a need for Michigan-specific codes: (1) state mandates,(2) local business coverage not covered elsewhere, (3) newly recognized health care services where coding structures had not kept up with technology--BCBSM recognized eligible coverage, but had no way to report it, (4) needing a way to automatically process claims for NOC codes currently in CPT and not classified elsewhere, (5) processing claims for services defined by group contracts, (6) a substantial amount of national account business, with subscribers across the country, (7) specific reimbursement mechanisms with the local provider community due to market share and other relationships.

BCBSM faced problems over several years that constrained the ability to service national accounts and relationships between BCBS plans: (1) Providers did not know what codes to use out of state; claims got denied and tied up in administrative hassle. (2) BCBSM itself had difficulty providing sufficient benefits across state borders. (3) BCBSM had difficulty analyzing utilization trends because of local codes, which may or may not survive from year to year.

About a year ago, BCBSM began to examine the need for local codes, and determine its position in light of the HIPAA implementation. National replacements, HCPCS Level I or Level II codes, handled cross over claims with Medicare and coordination of benefit issues when BCBSM was the secondary carrier. BCBS replacement codes or S codes also helped. When these failed, BCBSM tried eliminating the code. Some 532 local codes (many created because of a group-specific request) unique to BCBSM were identified and are scheduled for “the block. ”Some 236 codes unique to Michigan were eliminated without replacement. Another 216 were replaced with a HCPCS Level I or Level II code. BCBSA S codes replaced 41 local codes.

Dr. McBride reported that the cost in benefit pay out is estimated at less than one percent. There were some administrative costs up front for “going back into a hard coding claim system and removing those codes. ”Once accomplished, he said, the administrative savings, (no manual review or unnecessary suspense of claims) will benefit the plan and the provider community.

The reaction from the provider community has been positive. At first, Dr. McBride noted, some accounts were concerned about what this would do to their claims payout. Now they bill the same way they bill everyone else and the reaction is favorable.

Bart Killian, Utah Health Information Network

The Utah Health Information Network is a private/public partnership, a not-for-profit organization made up of state government agencies, the provider organizations within the state, all but one of the Utah domicile payers and the major private corporations. Mr. Killian described UHIN as being cross payers, cross entities, and very “HIPAA-like:”

UHIN determined early to eliminate as many codes as possible. The providers mandated it. They felt there was a greater area for fraud by mistake on their part with codes that meant different things to different payers. UHIN went with Level I, Level II. As a multipayer, UHIN looked for the next level they could use to keep their codes smaller, but still cover everyone’s problems.

UHIN and their Blue plans decided not to use S codes but went to the state Medicaid, which is part of the coalition, and used Y codes. They standardized areas and used Y codes as a temporary coding structure while seeking national exceptions. They spent about 11 months fitting all commercial areas into them.

Mr. Killian explained there are certain areas at UHIN where it was hard to get codes at the national level. UHIN was unable to get some national codes either because they are not physician-based codes or Medicare doesn't pay for them. Home health is an area where there are no national codes. In Utah this is a big industry, not only for Medicaid but also for commercial payers. UHIN wanted to create something in the Y code area to do what they needed to do in home health. Another area was state-mandated dietary supplements. Standard codes were necessary so that providers got paid within a specified time. The state Medicaid agency established Y codes and brought UHIN through the process.

James Y. Marshall, American Dental Association

Mr. Marshall stated that ADA fully supports the goal of eliminating local codes as soon as possible. ADA recommends that it have input into any process established by HCFA to review requests for temporary local codes in order to help eliminate duplicative codes and identify suitable existing codes that meet payers’ needs.

Mr. Marshall expressed ADA’s view that temporary codes should not be used as a means of bypassing code sets named in the standard, defeating the intent of the original legislation. He pointed out that a mechanism already exists for submission of suggested revisions to ADA's code on dental procedures and nomenclature known as CDT-3. Details can be found on the ADA's Web site. Codes will be reviewed by the ADA on a regular basis with revisions made in compliance with HIPAA.

As part of the most recent revision to the dental procedure codes, ADA agreed with a request from 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. HCPCS and CDT will merge into one code set for dental procedures.

ADA’s Dental Content Committee coordinates 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 not related to dental procedures but used in electronic transactions to and from a dental office should be referred to the committee.

Discussion

Ms. Riley clarified that the national panel meets to review requests for national codes three times a year. If needed, they will meet more often. The HCFA work group meets every month if there is an adequate schedule. This year the HCFA HCPCS work group met nine times.

Dr. Cohn observed that there appeared to be a profound lack of communication. One of the main issues confronting them, he noted, had nothing to do with policy or practices or procedures -- but “letters were not being answered, people did not know where to go. ”Dr. Cohn asked for comments. Ms. Riley noted that information about the process was posted on the HCPCS Web site (HCPCS@hcfa. gov). Messages could be sent directly to her. Dr. Cohn observed that the establishment of a Web site did not solve all communication problems. Awareness was needed about the site and the whole process.

Dr. Zubeldia commented that HCFA “had the status of a favored nation” when it came to getting HCPCS codes. If HCFA did not see a need or determined there were not enough claims, the code was not given. Dr. Zubeldia emphasized that the process must be open to the needs of other people and that Medicaid should also have representation in the national panel.

Dr. Zubeldia observed that talking about local codes is talking about multiple things. Except in a situation like Utah, where an organization coordinates the local codes at a state level, local codes come from multiple sources. The issue is much bigger than any one entity. Dr. Zubeldia asked for comments. The issue was not local code process or standardization, Ms. Riley responded, but the use of national codes. She added that Medicare and HCFA did not make the decisions; decisions are made jointly by private sector. HCFA oversees Medicare and Medicaid and both are represented on the work group. The work group and the national panel are not a barrier to the coding issue, she responded. From her perspective, the Medicaid agencies have not participated in the program.

Ms. Doyle described Medicaid as a group who has been very proactive in consolidating nearly all the states in coordinating a database for national codes. When requests are sent to HCFA, “everyone has done their work”--categorizing, consolidating, and checking for duplicative services. These proactive steps, Ms. Doyle suggested, indicate Medicaid’s cooperation. She noted the scale of the feat. “It isn’t a matter of, ‘Has everybody found their codes?’--It’s ‘Did they really find all of them?’”

Mr. Killian stated the need for a methodology that allowed plans and/or geographical areas to use codes to determine how medicine should be practiced. When a number of small western rural states got a waiver from Medicare to pay for telehealth services, he noted not a single payer would pay. Two years later, half of them pay some form of telehealth claim.

Dr. McBride introduced the concept of a tracking or provisional code for reporting mechanisms, utilization trends and health outcome analysis. One example discussed was how the CPT panel could tie a tracking code to a clinical trial of an emerging health care technology.

The panel responded to the query: “What turn-around time would preclude the need for temporary codes?”Ms. Doyle stressed the importance of monthly panel meetings, but added that timing encompassed not only a decision but also establishing and publishing the code. Dr. McBride stated that his commitment to some accounts was, once given approval; he could process the claim within 30 days. He said turn-around time on account approvals is anywhere from a week to six months. Ms. Riley responded that, since HCFA and Medicare and Medicaid work together and HCFA oversees both, the Medicaid requests would go to the HCFA HCPCS work group for determination at their monthly work group meeting. If approved, the work group would establish the code numbers almost immediately. Making them operational takes more time.

Dr. Braithwaite observed there is a lot of confusion about the value of codes. People confuse value with how reimbursable a code is. He said the real issue and value is uniqueness. Mr. Killian agreed, adding that to enumerate a unique position one should only have to show that another number is not doing the same thing.

Responding to a question about how specific releases will be interpreted, Dr. Cohn stated that codes are handled differently than the implementation guides. Not so much the regulations but the law, he said, describes a more or less instantaneous updating process for codes, as needed. Ms. Trudel added that what was being adopted was a version, like CPT-4. That standard would not change until the adoption of, for instance, CPT-5. Within CPT-4, changes over time happen on a flow basis.

PANEL 3: Discussion of Early Implementers -- Vendor/Clearinghouse Perspective

Deborah Meisner, WebMD/ENVOY

Ms. Meisner reported on the impact of HIPAA from a clearinghouse perspective. WebMD/Envoy’s commitment is to help customers become HIPAA compliant and ready to support HIPAA transaction sets and codes to customers within 180 days after final laws are posted.

She remarked that two national payers wanted to implement the transaction set this year. They wanted to be fully HIPAA compliant with the requirements in the implementation guides. The problem, she explained, is that data is not yet available from providers. It is difficult to present an X12 syntactically correct 4010 without filling in blanks with “not present. ”Payers purchased off the shelf translators with HIPAA tool kits and are “ready to flip the switch. ”But first, the provider community has to be brought up to speed with the data content.

Other issues to be dealt with are the way transaction code sets and identifiers are being rolled out. Without national identifiers in place, a tremendous amount of additional data is being carried through the transaction sets.

A lot of information required in HIPAA does not exist on today's claim forms. Ms. Meisner stated that volume of EDI is at risk. A clearinghouse cannot create a HIPAA-compliant 4010 transaction until the claim forms are modified to take in that data.

Additional information in HIPAA added 98 records to WebMD/ENVOY’s system, which is based on a 192-byte record layout. The increase is equivalent to about 44 NSF records. The HCFA version 5. 0 in the institutional had originally 43 to 45 records; about 78 will be added just to carry additional data content. This additional content is due, in part, to the COB information. But it is also data duplicated at the claim and line levels for efficiency. Place of service code, for example, traditionally has been at the line level. The implementation guides also put it up at the claim level. Looking in both places adds complexity to transaction processing.

WebMD/ENVOY also found, during implementation, that the guides’ intent was not always clear. The telephone number, fax number, e-mail segment, allows for four responses and they give four qualifiers. The intent of the work group was to not dictate any order, so they allowed for each occurrence to have the four qualifiers. Conceivably somebody, syntactically correct, could send four telephone numbers.

The implementation guides require data content previously needed only by government payers. Now there is only one claim regardless of who the end payer is. Previously, commercial or private insurance companies did not require ambulance certification with ambulance claims. Only the governments did. Now all providers must key that information in on specialty claims. It may be easier not to have to think about whether or not you need it for this payer, but it adds overhead to the expense of the claim.

The type of service code has been removed. Some mid-size payers use it extensively for edit criteria to make sure all the information is there. Ms. Meisner indicated some 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.

Another issue front end processors will have is getting definitions clarified. What constitutes an accident claim?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. ”It is going to be difficult, as an intermediary, to know when optional segments are required.

Many of the X12 code values have added more codes. WebMD/ENVOY’s intent is to add them across the board on all formats they support. People coming in on old formats will still get to 4010 payers and vice versa through the migration period. Ms. Meisner said it will be a long time, though, before all the payers can receive the codes that are mandated.

The next phase of WebMD/ENVOY’s analysis will be to share what they have learned with customers and determine what the impacts are. Staff will meet with payer groups, explaining what they have discovered, what the impacts are, and how they want to start rolling out things during the migration period.

Ms. Meisner concluded the intent is to: (1) work with the existing data content, (2) add any code values that need to be HIPAA compliant, (3) look at the formats that exist today and add any required data elements that are not in those formats, (4) and then, eventually migrate people toward full HIPAA compliance over the next two-and-a-half years.

Don Bechtel, HDX and Association for Electronic Health Care Transactions

Mr. Bechtel shared his perspective as an early implementer of administrative simplification. HDX was established in 1991 to provide EDI services to providers, payers and purchasers. HDX processes over 7. 5 million transactions per month, serving over 600 provider customers and more than 300 payers, including commercial and BCBS indemnity and managed care health plans, Medicare and Medicaid. The bulk of the transactions 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.

Eligibility service operates in an on-line real time environment using the ANSI X12 270/271 transaction set. HDX processes millions of real-time eligibility transactions per month. Eligibility services are integrated with providers' information systems, so that the eligibility inquiry transaction is generated as a byproduct of other business functions: admission, registration or scheduling. Eligibility response transactions are used to automatically update a patient's account information.

Initial implementation was provided to meet requirements for processing electronic remittances for Medicare. Those rules were successful in providing more efficient processing of remittance information. HDX’s remittance advice service is now available to any health plan that supports the ANSI X12 835 transaction for institutional and professional health care providers.

One of the most important benefits of the HIPAA standardization is uniformity of the data content of business transactions. Mr. Bechtel acknowledged that this was an issue of debate among the panel, but asserted that it was also what was going to make this an effective process--“So, it is important that we find ways to solve these issues. ”Bottom line, he said, is these transactions work. They are efficient. They reduce data error and the cost of business transactions. They also free people to do more important work and positively affect providers in terms of return on investment.

Workflow integration is key. To reap the benefits of EDI, it is important to integrate transactions into the customer’s business operations. This is best accomplished by integrating the transactions into supporting applications that use the data being exchanged. 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: determine whether authorization is required, execute authorization requests, capture authorization and certification numbers that must be submitted with the health insurance claim.

Data translation issues require careful planning. Translation issues related to the transaction can be seen as a sequencing problem. The concern is that several transactions operate in coordination with another transaction. It may be necessary to move some code sets or data values between both business transactions: claims and remittance advice or claim status, or authorization and a claim. If all transactions are not converted to the new X12 4010 standard at the same time, there can be translation issues between the new and old transaction standards.

HIPAA transaction standards do sometimes require additional data content from many business transactions. When called for, the business application and their user must collect these data elements. Translation issues exist for codes as well as for data content. For these code sets (clinical and X12 alike) there can be a many-to-one translation concern--it is not always possible to move from old to new or new to old formats via the translator. There are also 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, resulting in either lost data or truncated information. WEDI and the SNIP project are studying these concerns.

Mr. Bechtel noted there are concerns, too, related to stored data within many of the data repositories and data warehouses kept today for institutional studies, local, state and federal reporting and research. 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.

The current HIPAA approach has been focused on operational interfaces and data content, but there has been 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.

Transactions should be phased in a logical sequence. The industry should define a logical order and timing for the implementation of all individual transactions. There is need for 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 required features ready at once instead of approaching the implementation in small steps.

Mr. Bechtel remarked that “a big bang approach” would undoubtedly raise the cost of development and implementation as everyone deals 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. Many smaller regional implementation plans are being developed across the country and it is possible they will choose to implement the transactions in a different sequence or with different dependencies. This will create more confusion during the transition from current business practices to the new HIPAA established EDI transactions. Mr. Bechtel is 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. 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.

Another concern shared by many clearinghouses and vendors is the need for a chain of trust. The industry needs to find a way to establish that chain without renegotiating the thousands of contracts that exist today. At a minimum, the industry should establish simple model language, which would reference the rules where such requirements are defined and provide the necessary protections of data integrity and confidentiality. Model language could shorten the contractual process. Each contract should spell out these requirements.

Work is being considered within AFEHCT to develop such model language. Mr. Bechtel stated that, if this language were developed, it would be helpful if HHS would reference these models as good examples for completing the requirement.

John W. Carter, Healthcare Administration Technologies, Inc.

Mr. Carter described the proposed ruling allowing 24 months to convert the format of the nation's health care EDI pipeline as an overwhelming task. Proposed standards are extremely complex and costly to implement. Several X12 data elements have ambiguous, overlapping code values for the same concepts. Like other X12 standards, many lists of valid values come from sets of codes used by different industries for dissimilar purposes. Use or modification of codes for health care purposes sometimes requires the approval of another industry and cannot always be resolved.

The two-year implementation schedule may rush payers to clearinghouses for isolation from compliance issues. Once reliant upon a clearinghouse for translation, Mr. Carter stated, payers in particular might 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.

Mr. Carter discussed assisting facilities in the completion of HIPAA compliance questionnaires. The questionnaires ask details about formats and EDI standards which the providers do not understand. The catchall answer has been clearinghouse.

Providers ask to include language in contracts assuring that HIPAA compliance will be maintained. This is difficult to address; there is no consensus yet on what compliance is or will be. Even the language in both HIPAA and the HCFA Correct Coding Initiative make the term itself confusing.

Acknowledging the panel’s discussions regarding the local use codes, Mr. Carter said, “What we have been experiencing is variances in national code implementation. ”HCPCS codes are updated each year and are valid January 1 through December 31. One state Medicaid program implements the same national codes with valid effective dates July 1 through June 30. This year, commercial payers implemented HCPCS 2000 according to the national standard, while HCFA allowed the use of an overlapping 1999 and 2000 code set until April. Mr. Carter pointed out that there always has been and will continue to be exceptions.

The X12 can allow payers to implement various interpretations while still maintaining adherence to the standard. This flexibility of the X12 is magnificent; its complexities make the X12 a two-edged sword. Very few payers support the latest version of the 837. Those that do support the 837 claims have few trading partners submitting data in that format. As long as it isn't required, must opt 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 takes roughly four times that effort. The X12 formats are time consuming to read and difficult to modify. It is not cost effective to code an X12 that is likely to require reprogramming once the final rule is published and payers begin implementing their interpretation of the standard.

Implementation, Mr. Carter concluded, 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 are in a wait-and-see mode. Until the final rule is published and the implementation guidelines are released, there is little opportunity for early implementation.

Despite the obstacles, Mr. Carter strongly supports the X12 transaction formats as the standard for health care EDI. He predicts that the sharp learning curve will level off and the flexibility of open standards will provide interoperability pay off.

Based on experiences so far, the major issue he sees is that 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 go.

Mr. Carter proposed that the industry as a whole should be given an additional 24 months to convert to the X12 formats. This would: (1) provide a more equitable amount of time for implementation among all trading partners, (2) allow for a more stable implementation of the new standard, and (3) bring us as close as possible to 100 percent compliance in four years.

Mr. Carter referred to his proposal as “building the foundation . . . Payers preparing the foundation in the first two years, the rest of the industry coming on in the next two years. ”

Tom Grove, Superior Consultant Company

Over the past year, Mr. Grove assisted dozens of small e-commerce vendors as well as major HIS vendors in the health care space. He shared their perspectives with the panel.

Mr. Grove cited three major obstacles to mass adoption of the Internet as a central part of a health care business strategy: (1) concerns about confidentiality of patient information,(2) security concerns about placing mission-critical data on the Internet,(3) the lack of standards. HIPAA provides solutions to all major obstacles. By addressing security and privacy concerns and providing standards for transmitting critical data, HIPAA unlocked the gates--Internet solutions to long-standing health care problems are flooding in, creating a whole new market sector and brand-new HIPAA concerns.

The e-health market 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. Another 150 companies were just entering or about to enter this market segment at the beginning of the year.

Although many major market players in health are consumer or supply chain oriented and may not be very involved with the kinds of transactions and data related to HIPAA, this too is 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 trend is especially valuable to smaller hospitals, which will soon be able to have a full suite of health information systems, without needing a lot of computing hardware and a complement of programmers to support it.

The number of vendors offering specialized security applications as a way for hospitals 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.

Currently, there is a lot of confusion about how to implement security measures. Much of this confusion stems from the lack of technical specificity in security regulations. Many new vendors do not understand how to make the decisions they need to make, based on a risk analysis. Mr. Grove mentioned two options for relieving confusion. HHS could act like the IRS—issue non-punitive rulings on various situations posed by implementers. A more practical solution, he said, would be for HHS to publish more examples of working, acceptable solutions--either with the final regulations, or as a separate clarification.

A related cause of confusion is misinformation circulating among the vendor community. One vendor called to say that he recently learned he would be expected to keep all his servers locked inside a vault in order to meet HIPAA physical security demands. The sheer volume of the regulations and their associated commentary discourages reading the complete text. Some vendors find them difficult to understand. Mr. Grove said they are trying to interpret the regulations without understanding intent. He encouraged HHS to publish that intent as clearly as possible.

The regulations define data authentication as the corroboration that data has not been altered or destroyed in an unauthorized manner and give examples of how this may be ensured: a checksum, message authentication code, or digital signature. Questions arose over just what will be sufficient, particularly since the standard seems to apply to both transmitted and 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 stored data was not modified in an unauthorized manner, so long as the perpetrator uses the authorized application that updates the checksum at the time of data change. More clarity on how to apply this regulation to transmitted vs. stored data is needed.

Open networks and encryption standards interest many clients, particularly those developing browser-based products. Many question what qualifies as an open network. What constitutes acceptable protection will change over time, as computers get faster and current encryption standards become more vulnerable. Some separate guidelines have been published by HCFA defining what constitutes acceptable encryption. Clients are clamoring for more clarification and examples of what will be required.

For many vendors, the implementation calendar is not clear. Vendor contacts are concerned about the mechanics and sequence of implementing various parts of the transaction standards. WEDI has formed a working group to address this issue and produce a strategic national implementation plan. 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 much time to do something as big as this, and that coordination is essential.

Other vendors request that the rules be amended to call for compliance on all the regulations together on one specific date. Mr. Grove urged the committee to keep this in mind, particularly if the discussion turns to deadline delays. One specific date represents one solution to the problem of how to implement when so many different transaction sets interact with one another.

Customers are calling, asking about compliant versions of software. Continuing delays in publication of the final regulations are frustrating them. Mr. Grove urged for publication of the remaining rules.

There is total confusion about business partner agreements, as required by chain-of-trust agreements and the privacy and 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. Mr. Grove suggested two actions. First, combine the two agreements, with one standard of compliance. Then, urge Congress to amend the original legislation to provide the direct power needed to address all business partner concerns, instead of resorting to the contractual web of these agreements.

Mr. Grove shared another privacy question he repeatedly hears from start-up Internet vendors. There is much concern about how to de-identify data, since it is getting easier to re-identify data, particularly involving patients with uncommon conditions. Also, some of the de-identification discussed in the regulations may destroy data usability. Mr. Grove pointed out the potential commercial value of the resulting data sets, an area that in itself, he suggested, raises interesting questions. He encouraged the committee to recommend clarification of the de-identification of data and the allowable uses of the resultant data set.

David Sweigert, Open Network Technologies, Inc.

Mr. Sweigert discussed lessons learned assisting organizations within BCBSA prepare for implementation of the HIPAA final security rule. Business needs drove modernization, Mr. Sweigert noted, not HIPAA. IT managers rank Internet applications and security important technology issues. But they are concerned about upcoming HIPAA security regulation. The industry is weary of the on-again, off-again nature of the release of these rules. Rumors circulate while industry associations and work groups try to build awareness.

Mr. Sweigert stated that an organization's HIPAA guru has to: (1) seek senior management buy in, (2) build organizational awareness, (3) set up an organizational education program, (4) put system vendors on alert that HIPAA compliance requires vendor initiatives.

Market drivers overshadow HIPAA compliance. Key drivers are the cost savings Internet technology brings and increased interaction between payer, insured, and providers. Complying with HIPAA is a secondary, and Sweigert affirms, achievable goal. Information technology managers want to satisfy consumer concerns that sensitive, confidential information is protected. They need to know how confidential information can move to the Web and remain within HIPAA compliance.

Many IT organizations within the health benefit administration or claims processing sector lack a sophisticated talent pool with proposed security standard knowledge and understanding of emerging Internet technologies. The HIPAA proposed security regulation is voluminous and complex, Mr. Sweigert noted. It is difficult for many organizational staffs to understand the rule or comprehend the impact it will have on their operations.

Vendors: (1) need to be put on notice that HIPAA compliance will be mandated upon their software solutions, (2) need to map their product features and benefits to proposed HIPAA security regulations to enable IT managers to understand solutions being offered, (3) should map their software solution set to HIPAA regulations, especially in the case of security.

Venders need to help customers understand requirements under HIPAA and what regulatory relief their products may provide, while proceeding with business needs-driven applications. This way, management, operational and technical personnel can all be provided a standardized baseline of information that includes HIPAA security requirements and technology that meet present business requirements. Aware of the impact of HIPAA and planned application rollouts, these personnel can make decisions regarding the cost of identification, authentication of users, privileged management of users, and access control,

Organizations have appointed compliance officers, and their legal departments actively review planned IT applications for HIPAA compliance issues. 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, no matter how the final regulations look.

Mr. Sweigert encouraged all vendors, especially those in new areas of Internet technology, to focus on how their solutions and customer sets benefit the customer and how they relate to the HIPAA proposed regulations and the proposed final rule. He gave examples of how a vendor can map software solutions to the regulatory constraints mandated by HIPAA.

Discussion

Dr. Zubeldia noted that HIPAA was required to have implementation guides in 1998 and the compliance date should have been August of 2000; in his view there has already been a two-year extension. Mr. Carter responded that payers have waited for the final rule and should be required to convert a percentage of transactions over to the HIPAA compliant transaction set. Mr. Grove stated that, given the difficulties of implementing different transaction sets at different times, he advocated making the implementation cut over simultaneously. Ms. Meisner suggested implementing the transactions in an X12 mode, and getting people to become HIPAA compliant in the data content over the migration period. Mr. Bechtel agreed. X12 transactions have been done for years, he said. Getting to 4010--in some cases, “we are already there. ”The issue, he said, is data content and finding willing and ready trading partners. Mr. Carter stated that the clearinghouses were the furthest along in readiness and capability to comply. Payers are second and institutional providers are coming on. Other participants agreed. Dr. Zubeldia stated that the pharmacies are 100 percent compliant today. Ms. Meisner noted that, as a group, the individual providers were least aware and ready; a lot of information that they will need to provide is going to have to be added to the practice management systems.

Ms. Meisner discussed the professional encounter submission and the paper-to-print image. Additional information is not available on the HCFA 1500 and UB92 print form required in some electronic formats. It is kept in profiles and provider information. This information does not necessarily have to be on the print image as long as it is available in the practice management systems or print image grabber.

Mr. Larry Watkins, a participant on Panel 5 who was in the room, stated that ASPIRE, a group within AFEHCT, was looking into this disparity. Vendors are given a kit and answer questions for each element where gaps exist, explaining how they fill those gaps today for implementation. The next step is to determine what is appropriate under HIPAA.

Mr. Grove, responding to a query about the provider community, stated that they are somewhere behind the vendors. Many recognize that most of their compliance issues, specifically related to transactions, are dependent on the vendor providing software. Some will face major efforts. “Awareness is coming; preparedness isn't quite there yet. ”Bechtel stated that readiness from the provider vendor perspective was moving along quite well. The providers themselves need the vendors to get there.

Participants discussed conflict in testimonies about clarity and effectiveness of X12's 4010 implementation guides. Ms. Meisner stated, “They had come a long ways;” just adding semantic notes would take out the ambiguity. She found difficulties, however, in the X12 process for making corrections. Mr. Bechtel concurred. He suggested that some situational fields in the guide lead to different interpretations. Another issue is consistency between the transactions. The implementation guide task group is fine-tuning the process.

PANEL 4: Discussion of Early Implementers – Provider Perspective

Rita Aikins, Providence Health System, Oregon Region

Ms. Aikins, an information privacy security officer and an early implementer, stated that Providence believes the standards are reasonable. The transaction standards, the medical code sets and the identifiers all have specific requirements. Implementation and compliance around those standards are adequately defined. The security standard, because it is scalable and technology neutral, requires each provider develop, document, implement and maintain appropriate security measures to meet business requirements.

Each provider has to establish a process, assess risks, and devise appropriate mitigation for identified threats to health care information. Ms. Aikins stated that this could be a problem. Some providers are not sure how to do that.

Ms. Aikins presented Providence’s experience with HIPAA and outlined what they have done so far to comply with the standards. First, Providence conducted a complete asset inventory of all applications, interfaces, databases and hardware. The inventory is needed for vendor communications, partner communication, risk assessment, compliance and surveys. Next, Providence developed a risk management methodology to identify and assess risk and mitigation for risk, and to maintain an acceptable level of risk. It took about six months to develop and put the methodology in place. Providence will be using it across the entire Oregon region. Ms. Aikins asserts that this assessment is definitely a requirement for compliance.

Providence developed a risk assessment process that evaluates organizational and departmental practices against the standard and provides a gap analysis.

Providence also uses some compliance surveys as part of the risk assessment. The information is used for analysis and reporting purposes. Since Providence was an early implementer, they utilized the risk assessments to go back and change business practices. Ms. Aikins emphasized that Providence did this not because HIPAA required it, but to improve business practices.

The security standard’s primary focus is on administrative processes. Providence has gone through and identified the policies, procedures and processes they believe need to be compliant. Some 70 have been identified so far.

Providence then reviewed their process for the identification, development and the approval of policies. Existing policies that are either in a service level or in departments, and any policy they feel needs to be compliant with the security standard is pulled and moved to a regional level. Ms. Aikins pointed out that policy development and approval is a slow process for large health care providers. There is a large audience that need to buy-in and be part of that approval process. Ms. Aikins added that value has been gained from the asset inventory, the risk management methodology and assessment, and from the development of the Oregon regional policies.

She noted that Providence is heavily dependent upon software vendors for software modifications. They continue to ask if vendors should be required to comply with the requirements. Some vendors go ahead and make modifications to the systems; others are not so proactive. Ms. Aikins stated Providence would like to see something about the vendor relationship with the standards.

Knowing more about the monitoring and enforcement of the standard would also be helpful, she said. How will auditing be done for compliance? Will it be similar to a joint commission survey? Understanding this would assist providers in their preparation for compliance.

Ms. Aikins also suggested that the security standard should address both electronic and paper health care information. She cautioned that providers who take HIPAA word for word and only look at electronic information are going to get themselves in trouble.

Gary Levine, Medicine Shoppe, International

Mr. Levine stated that the pharmacy community has benefited from telecommunication standards for interactive on-line prescription-related processing between providers, clearinghouses, switches and third party administrators. The adoption of these standards by provider pharmacies and claims processors has facilitated and provided efficiencies from both a business and health care delivery perspective.

NCPDP's EDI standards account for upward of 70 percent of an average pharmacy's business transactions and annually amount to billions of on-line prescription health care transactions. Mr. Levine stated his belief that NCPDP's telecommunication standard satisfies the necessary requirements mentioned under the HIPAA legislation for pharmacy. Adopting a national EDI standard like NCPDP's would greatly decrease the burden on health care providers, and eliminate the need for continually reprogramming pharmacy computer systems to support multiple formats. Lack of standardization would place undue burden on pharmacy providers, and make it difficult for software vendors to develop a product that supports business needs. It would be difficult to develop any kind of operational efficiencies; providers and payers alike would not realize a savings.

From a patient care standpoint, standardization would: (1) enable pertinent patient and medication usage and information to be exchanged and captured, (2) 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, support the delivery of superior levels of patient care, better interaction among health care providers and improved health outcomes. Conversely, uncaptured or unknown data could create a situation where the patient may be vulnerable to therapeutic conflicts or admissions without detection.

Robert Tennant, Medical Group Management Association

Mr. Tennant stated that countless proprietary systems, now in use within the industry, create problems when these various systems attempt to interact or communicate. Full interoperability between systems will take many years. He cited the joint WEDI-AFEHCT Internet Encryption Interoperability Pilot Project and stated all efforts to assist those seeking to identify and resolve interoperability issues should be supported.

Mr. Tennant noted concern, too, about the proposed use of a unique patient identifier. Tracking patients electronically across disparate internal organizational systems and, as they move between locations, will be a critical factor in the expansion of e-health.

Maintaining the security and confidentiality of personal health information is a key issue. Many consumers are apprehensive about having their personal health information sent over the Internet. Providers are concerned about their legal liabilities.

There is also concern about implementation periods and tracking. Those without existing vendor contracts may find that two years passes too quickly. Many smaller members have limited resources. Those initiating e-health well into the compliance period may fail to meet proposed deadlines.

The NCVHS is mandated to track and report on HIPAA implementation. That will not be an easy task. Self-reporting and survey data are likely to be overly optimistic, due partly to the potential for civil and criminal penalties for non-compliance. It will be critical 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. Many may view HIPAA as strictly an electronic issue, not pertinent to them as they submit paper claims and maintain a paper-based patient record system. Educational outreach is needed to convey: (1) the benefits of HIPAA and e-health and (2) that HIPAA regulations--primarily security and privacy--apply to many aspects of any system. HIPAA compliance is not optional.

There are few reliable cost/benefit analyses of HIPAA. Many consider that the tables included in some of the NPRMs grossly underestimate the costs. Mr. Tennant urges that accurate figures be made available so group practices can begin to budget for implementation.

There is also a problem with staggering the rollout of the regulations. The cost to upgrade practice management systems and claims software will be substantial and will increase significantly if necessary changes cannot be undertaken simultaneously by a single vendor. Mr. Tennant discussed roadblocks to implementation stemming from several of the specific HIPAA provisions in the transaction and code sets, NPI, security and privacy NPRMs.

Mr. Tennant recommended that HCFA and HHS be more involved in the HIPAA implementation process. MGMA contends that HCFA should institute a toll free number for providers with questions on HIPAA. 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 would assist providers in compliance.

Mr. Tennant asserted that HIPAA should release the electronic claims attachments and electronic medical records proposed rules as soon as possible. He said another crucial piece of the HIPAA puzzle is the unique patient identifier.

Other recommendations included: (1) The NPIs should be disseminated as soon as possible. Databases from Medicare and Medicaid could initially populate a single national registry. (2) The flexibility and scalability of the security regulations should be insured. (3) State preemption should be the standard for all HIPAA provisions. 4) The Federal Government should comprehensively assess industry implementation levels at the 12 and 18-month milestones. (5) Industry efforts to facilitate implementation should be supported. The government mandates HIPAA, but the majority of implementation assistance is expected to come from industry sources. (6) The adoption of HIPAA and e-health should be encouraged through supporting prompt payment initiatives. (7) One key incentive to move providers toward HIPAA and e-health is the adoption by private payers of the current Medicare 14-day window for paying a clean electronic claim.

Helene Guilfoy, IMG Healthcare Consultants

Ms. Guilfoy reported on how providers are implementing HIPAA, based on statistics readiness assessments of over 220 health care systems, including 150 hospitals, academic medical centers, large national health systems and IDNs across the nation.

Ms. Guilfoy outlined how a reliable HIPAA implementation consists of four phases: (1) awareness focused on what HIPAA is all about, what needs to be done, and the client’s own in-house training, (2) the initial readiness assessment, (3) remediation, (4) and implementation.

More than half of the HIPAA policies and procedures requirements are not currently addressed by those providers actively engaged in preparing for implementation. Providers readying themselves have about an 18 percent overall compliance rate with security policies and procedures--18 percent of the requirements in the HIPAA current NPRM are “ready to go. ” Technical security is at an 11 percent compliance rate. Integrity, access controls, alarms and events reporting: 11 percent are HIPAA compliant. Less than 60 percent of the software systems evaluated are ready to comply with HIPAA security requirements as mandated in the NPRM. The lowest percentage of compliance for the institutional claim is 50 percent; the highest is about 63 percent. Half the providers actively engaged in implementation do not yet have the content required on the X12 837 to file the institutional claim. Compliance for the professional claim is between 20-50 percent. Other compliance percentages for data collected include: (1) payment and remittance: 12-40 percent, (2) eligibility: 17-28 percent, (3) claim status: 30-40 percent, (4) referral and certification: 42-89 percent, 5) coordination of benefits information: 82 percent, (6) home health information: 32 percent, (7) special applications: 18 percent, (8) Medicare information: 19 percent, (9) inpatient: 68 percent.

Ms. Guilfoy stated that she has yet to find a hospital where the code sets of the information currently stored matched what the X12 837 requires. Translation algorithms are being used to process the information.

Addressing converting from the UBs to the institutional claim and the differences in the variability of the code sets, Ms. Guilfoy stated that currently the hospitals and systems assessed collected about 72 percent of the data elements required for the institutional claim.

Ms. Guilfoy suggested sending letters to vendors asking about their HIPAA compliance, a description of their plan, any costs the provider might have to pay, and when they expect to have this information out. She emphasized that providers need to understand that they can't do any data collection training or testing until the vendor delivers the software.

Patrice Kerkoulas, Memorial Sloan-Kettering Cancer Center

At Memorial, four standards are in production today with Medicare. MSKCC implemented the 835 with Medicare in 1995. After the HCFA proof of concept testing in 1998, the 276, 277 and 997 were moved into production in January of 1999. Currently MSKCC is conducting a proof of concept project with Empire Blue Cross on the hospital outpatient therapy, 277, 275 request for ADRs. Ms. Kerkoulas stated that their initial proof of concept testing was to prove if the implementation guides were ambiguous. Some ambiguities were still left—She noted they have improved since. Unforeseen complexities of implementation warranted beta testing prior to the implementation.

The 276, 277 had interpretation issues. There was a gap between the payer and provider in terms of what the provider number meant. On the hospital side, there were date of service issues. An end-user issue was moving from customized, proprietary status code into the national status codes; it was mostly a learning transition. With the 277, 275 pilot, information needed to do some programming was not available. She said everything is in the new guide.

Ms. Kerkoulas emphasized the importance of complete testing and advised that test files give programmers something to work with while awaiting the initial file from the payer. MSKCC developed 89 different test scenarios (different bill types, age of claims, volume testing) for the 276, 277. She also suggested: aligning business office resources for testing and the implementation, and providing on the Web a testing checklist for payers and providers.

Within the 276, 277 project, and now in the 277, 275, MSKCC anticipates versioning issues. Ms. Kerkoulas advises allowing for window of overlap and phase schedules. Providers and payers must plan how they will deal with the three to six-month period when every transaction set and every participant might have a different version.

MSKCC recommended to HCFA, during the 276, 277 project, to implement the standards that are one-way transaction sets first, both to get them out of the way and to let the payers and providers build experience. Ms. Kerkoulas advised allowing 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 implementation, MSKCC exchanged 19 sets of files that identified 26 interface issues.

Identify everyone who will be involved to plan out the projects. Develop together a workflow analysis. Flow out the projects, when and where things are going to be automated, including various support systems. Then determine how the interactions with the payer will come in and how automated transactions will be posted. Streamline the reengineering for cost elimination; both plan for and prove it with before and after flow charts.

MSKCC found that they could transmit and resolve the bulk of their 276 transactions a few days after initial billing. The claims status transaction eliminated 30-day cycles and telephone calls originally required for provider services. Claims aged over 30 days reduced by 18 percent. Some 92. 5 hours a week were saved in Medicare claim status alone. Cost savings for the 276, 835, 837 and 270 totaled about $600,000 a year.

Fred Urbanek, Information Technology Association Services, Premier, Inc.

Mr. Urbanek discussed his involvement in efforts to facilitate collaborative solutions for HIPAA among Premier's 215 independent not-for-profit health systems. A member-driven HIPAA working group confers monthly via conference call to discuss current HIPAA-related topics and share experiences, insights, challenges and lessons learned. The CIO of the Alliance members is the primary participant.

Mr. Urbanek noted that no organization within Premier wishes to be a HIPAA early implementer. Even the most proactive take offense when described as HIPAA early implementers for fear that funding and support might be lost by “doing more than absolutely necessary to address a challenge offering little benefit” to anyone ahead of schedule.

Minimal progress has been made beyond general HIPAA education and awareness. Organizations continue to struggle with the uncertainty of how to manage the HIPAA project. Officers are reluctant to assume responsibility due to the impact that HIPAA is expected to have on business processes. In some larger organizations, corporate legal counsel has been delegated responsibility for HIPAA. Time is spent interpreting and analyzing the regulations but there is little tactical action.

Varying levels of security assessment have been realized at a few organizations. Feedback regarding 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. Many hospitals are currently struggling to finance operating costs as a result of the balanced budget act and year 2000. Few financial resources are available for an investment that may take several years to recognize a return, especially an investment in controls where return is realized through cost avoidance.

Other barriers to HIPAA implementation include dependence on system vendors, an inability to gain support in the clinical areas, ambiguity regarding the requirements, and a general uncertainty regarding the impact HIPAA will have on proven cost effective processes.

Mr. Urbanek suggested incentives to better motivate provider organizations: (1) increased reimbursements for organizations achieving compliance before the deadline, (2) extended or staggered compliance deadlines based on the type of covered entity which could address implementation issues resulting from dependencies on third parties, (3) extended and/or staggered compliance deadlines for processes and systems within the provider environment, alleviating the strain of replacing and upgrading clinical systems solely for HIPAA compliance.

Discussion

Ms. Guilfoy stated that IMC intends to put information on specific vendors and potentials for compliance on a subscription Web site. She pointed out that today no vendors are compliant. Maximum compliance on one transaction type is about 80 percent. IMC is surveying vendors to determine their awareness of HIPAA, compliance plans and time tables. So far, little data has come back. Responding to a query, Ms. Kerkoulas noted the importance of enlightened, visionary management and structuring and supporting the right team. It was noted that business cases existed and can be provided. Dr. Zubeldia commended Ms. Guilfoy on her presentation and encouraged her to continue, noting similar documentation was needed for the payers. Ms. Guilfoy responded that IMC had sent a letter to the payers asking about readiness plans to implement HIPAA. Dr. Zubeldia cited the need to find out how much of the data required in HIPAA is actually needed by the payer--and how much might be excess. Participants noted the inclination for the provider to collect and send everything (optional or not) in a single response. Dr. Cohn proposed that HHS look at Ms. Guilfoy’s data. Ms. Guilfoy observed that another issue is that more clinical data is now required that either is not yet automated or doesn't yet pass through to the billing system. IMC was looking into the “island of information” that still needs to get into the billing.

Dr. Cohn stated that Mr. Tennant’s comments about the need for comprehensive assessment of industry implementation was crucial. Everyone had addressed a tendency in the industry to hold back until the final regulations are published: then it will be “a horse race that needs to be followed carefully. ”Another missing piece, Dr. Cohn stated, is working with HHS to get funding and facilitation.

Dr. Braithwaite clarified that only small health plans have three years to implement. All providers must be compliant within two years, according to the statute. Noting that the panel concurred that vendors had to implement first, Dr. Zubeldia pointed out that the vendors are not required to do anything under HIPAA. Ms. Guilfoy stated that there is usually a contractual requirement for the vendor to implement federally mandated legislation. Depending upon the contract, the vendor could be penalized for not delivering appropriate code. Ms. Aikins stated another concern is some vendors might decide to close their doors. Mr. Blair and Mr. Tennant agreed. Vendors for the ambulatory sector were most vulnerable. Many small and medium-sized group practices have contracted with vendors that are no longer in business. Mr. Tennant added that MGMA was urging members to contact their vendors, determine what their contract provides and what their options are. Ms. Aikins stated that some vendors are reluctant for any type of HIPAA verbiage to be added to the contract. Ms. Guilfoy observed that, with Y2K, some vendors said “This is enhanced capability; you have to buy this new release. ”She noted this issue is questioned on the vendor survey. Ms. Trudel asked if vendors' performance level on Y2K would be a reasonable indicator of potential success in HIPAA. Ms. Aikins replied that, after Y2K, the big question was: Are vendors in a financial state to do it again?Mr. Tennant concurred when it came to the claims transactions, but cautioned “you can't just have a vendor come in and tell you how to run your security when all they know are claims. ”It is a much broader problem.

Responding to a question about populating the provider database, Mr. Tennant stated that the problem with any database is not just getting the numbers out, but getting updated information back. Providers change group practices, locations, phone numbers, fax numbers. And if there is any fee, it is going to be a disincentive to get information.

Ms. Kerkoulas clarified that once resources were committed, MSKCC was able to implement the 835 in about six months and the 276 in about nine months elapsed time. A consulting group rather than a vendor was used in all three implementations. Asked if, in six months or a year, providers could implement in that time frame or less, especially if vendors are better prepared and consultants available to help, Ms. Kerkoulas replied, “by transaction set, possibly. ”She emphasized looking at the transaction set-by-set, payer-by-payer. It is reasonable, once the network infrastructure is in place, once the payers are ready for testing. Meanwhile, have staff lined up for testing and have the transaction sets prioritized.

The hearing was recessed at 5:28 p. m. to be reconvened the following morning.

Dr. Iezzoni reconvened the hearing at 9:10 a. m. on July 14, 2000; initiated introductions of the participants; briefly summarized the previous days presentations and introduced the first panel.

PANEL 5: Discussion of Early Implementers - Industry Solutions.

Christine Stahlecker, Blue Cross Blue Shield Association

Ms. Stahlecker discussed, from a payer perspective, the need for leadership in the implementation of HIPAA standards, outlined the role undertaken by WEDI strategic national implementation process, and requested the support of NCVHS. Two factors led to Ms. Stahlecker’s perspective: (1) BCBSA member plans' requests regarding HIPAA implementation and compliance, (2) insights gained developing and maintaining front end application systems and supporting business procedures--an experience that parallels activities that payers will face implementing HIPAA

Ms. Stahlecker presented “lessons learned” in a proof of concept project conducted by a virtual project team made up of Medicare contractors including the co-chairs of the X12N claims status work group, contributing authors of the implementation guide, partner providers for each contractor, and vendors supporting those providers. Most meetings were conference calls; project materials were posted on a Web site. The project included the receipt of the 276 inquiry transaction from both institutional and medical provider trading partners. Interfaces were built to both the Medicare Part A and Medicare Part B claims processing systems. Claims were located using the matching data from the inquiry retrieved, and the 277 response formatted and returned to the requestor. The standard transaction involved was the claim status inquiry.

The project seemed a straightforward implementation and well staffed. The teams included members familiar with EDI and the standard. Yet, only the institutional transaction was successfully implemented into production. And the project took about nine months. Assessing the project, five lessons were learned. (Details on the lessons can be found on the NCVHS Web site: http//aspe. os. dhhs. gov/nchvs). Similar situations are likely to occur with other HIPAA standards, Ms. Stahlecker stated, adding that a similar lead-time for each entity and transaction in a national HIPAA implementation is unnecessary. She suggested that the delays experienced represented opportunities for others to avoid similar pitfalls. Common solutions could be reached and communicated. Applying this approach to other standards can shorten the learning curve, avoid different interpretations and different solutions to ambiguities. Sharing interpretations and experiences among the members of the proof-of-concept project team had great value for all participants. In the same way, the industry could benefit from similar common forums to address issues related to the overall implementation of the HIPAA administrative simplification standards.

The five lessons learned, combined with an appreciation of the scope of HIPAA, resulted in a search for industry coordination and a search for leadership for the implementation of HIPAA standards. Ms. Stahlecker discussed steps taken to initiate a collaborative effort surrounding HIPAA implementation. The BCBSA representatives met with HCFA and HHS. WEDI was identified as the appropriate organization for this initiative. Outreach was conducted to seek out industry activity regarding HIPAA implementation, to introduce SNIP and to request participation. In June, a WEDI industry forum was held to announce SNIP and share its vision and mission. The three work groups--security, education and transactions--were introduced. The transaction group was subdivided into five: sequencing, translations, transactions, testing and business issues. Work sessions convened.

The strategic national implementation process, (SNIP) was announced at the WEDI annual conference in March. SNIP’s purpose is to address HIPAA implementation obstacles by creating an industry collaborative effort to reach consensus regarding the resolution of processing issues, structure, order and priority of the mandated standards, and to set trading partner expectations for this process change. All activities are focused on delivering implemented standards expediently, with efficient use of resources. The communication approach is similar to the virtual project team.

Initial steps to form the group of participants are (1) outreach that identifies existing implementation activities, (2) seeking out experiences of early implementers, (3) and channeling lessons learned for other implementers. Attention will be focused where differing interpretations of the standards exist, and efforts directed toward reaching industry-recommended solutions and best practices.

SNIP looks forward to keeping the NCVHS Subcommittee on Standards and Security apprised of progress and issues, and seeks recognition of the WEDI SNIP in drawing HIPAA implementers as participants.

Larry Watkins, Per-Se Technologies

Mr. Watkins stated that WEDI formed the Strategic National Implementation Process task group (SNIP) to assess industry wide HIPAA implementation readiness, and bring about the national coordination necessary for compliance. SNIP’s purpose is to identify implementation issues, best practices, model workflow scenarios, and to mitigate national deployment obstacles.

Health care is still a regional business. The administrative reality is composed of non-standards and locally defined data and code definitions. Standards have been virtually impossible to deploy and implement in this fragmented environment. Adopting standards is only the beginning of the solution. Implementation is the challenge. Implementation dramatically affects the administrative processes, systems and information exchange that have a direct impact on the revenue and cash flow for most of the affected entities. The task needs to be accomplished in two years.

Per-Se is positively anticipating the standardization and simplification that HIPAA will bring to everyday operations. However, without the national coordination that WEDI SNIP will provide, the process of getting to these standards could undermine business. Per-Se has several major concerns that SNIP can help mitigate: (1) provide both a recommended deployment schedule for the transactions and code sets that will bring about industry-coordinated ordering, timing and grouping of transaction implementation, and (2) provide leverage to encourage trading partners to adopt this schedule; implementation will not be perfect but it will go a long way in setting expectations and providing coordinated deployment, (3) X12N implementation guides and data dictionary are inadequate. Ambiguities and gaps will be identified, it is critical that the industry can bring these issues to a nationally-recognized entity like SNIP for coordination on definitions, clarifications and work-arounds, to bring solutions for implementation, (4) aside from nationwide deployment itself, testing is the most time-consuming part of implementation. WEDI SNIP can indicate appropriate levels and methods of testing for trading partners.

WEDI SNIP provides a coordination point for the industry for the formulation of solutions and recommendations in an ongoing way, countering barriers to successful implementation. Actions are structured through three work groups: (1) The Transactions, Code Sets and Identifiers Group, (2) The Education and Awareness Group, (3) The Security Group. SNIP plans to: 1) bring together different industry groups via conference calls and meetings, to identify, discuss and resolve HIPAA implementation issues, (2) disseminate the appropriate information via a series of periodic reports, list serves, and a planned Web site, (3) begin dialogue to address industry consensus on model processes and procedures, a long-term approach to addressing the significant changes occurring.

Jon Zimmerman, HDX.

Over the last year, Mr. Zimmerman, general manager of HDX and senior manager of HIPAA initiatives for shared medical systems, engaged in over 100 provider, payer or industry forums or discussions: many working directly with the health systems senior management team to kick off HIPAA preparation initiatives. He discussed how the industry can cope with HIPAA's mandates in an economically challenged, highly fragmented, complex, technologically and culturally diverse environment.

Mr. Zimmerman observed that “to adopt,” means use what works--Do not create what you do not have to. “Standards” implies what has been agreed to, de facto consensus process. He suggested that HIPAA is extremely relevant, applicable and perhaps essential in an era of unprecedented and rapid technological change.

HIPAA's five security tracks are: (1) administrative procedures--how to define, communicate, administer and monitor acceptable practices to protect the confidentiality of patient information and business operations, (2) Physical safeguards--how information is physically protected from disclosure or harm, destruction and damage, (3) Technical security services--how to assess the information is enabled for only those who need to know, within the context of their responsibilities at any given time, (4) Technical security mechanisms--how the information is properly protected during transmission and storage, (5) electronic signature--how to ensure those who use electronic signatures as part of their business processes can irrefutably, uniquely and specifically be identified.

The key issue is how to improve effectiveness by providing efficient access, while improving security practices to improve individuals' rights and business operations. A corollary issue is how to change or enhance secure operations in this environment, and the economic impact incurred. Changes require investment. Positive, progressive change requires solid understanding of the current state of affairs, clear depiction of goals, and a sound set of interrelated steps forward. All this takes time and money.

Mr. Zimmerman acknowledged these changes fall upon the industry just when it is under severe economic constraints. But this also is a time when interconnecting businesses, processes of suppliers, customers, partners and consumers, through standard-based computer networks is driving innovation and attracting investment worldwide. Mr. Zimmerman cited a number of interrelated initiatives underway on both national and regional levels indicating that health care can reap the same rewards.

Lisa Gallagher, Exodus Communications

Ms. Gallagher, representing the Forum on Privacy and Security in Health Care, noted that implementation of systems could not, and did not, wait for a system of standards. The current situation surrounding health care technology and medical vocabulary is difficult enough, she acknowledged, and all but insurmountable in terms of privacy and confidentiality.

A system of standards was under appreciated when health care was delivered at the community level; only recently has there been a compelling argument for health care information systems that extend beyond.

The Forum on Privacy and Security in Health Care was created to address compliance issues in the health care industry by providing a venue and a mechanism for the exchange of ideas, technology and expertise. The forum's mission is to: (1) encourage the health care industry to develop more efficient methods of providing a secure environment for their commerce, (2) promote the use of the common criteria--that is ISO standard 15408--to aid in regulatory compliance, (3) educate the industry about the worth of these standardized technology blueprints and catalyze the industry.

Although passage of the HIPAA legislation and the upcoming regulations will help solidify goals and requirements, Ms. Gallagher emphasizes that gaps remain in the definitions and levels of understanding. An industry-accepted vocabulary for requirements expression and industry-wide acceptance of values are still needed. Meanwhile, security professionals must buy equipment, integrate systems and implement secure environments without a clear statement of the goals that need to be achieved.

Health care providers are considering the implications of implementing architecture, policy and procedure changes in order to establish compliance with the HIPAA security requirements. A prime concern is how to establish and maintain compliance in a manner meaningful to patients, business partners and the public. Too many interdependent factors coexist for compliance to be achieved by any one segment of the community alone. Stakeholders need a compliance mechanism that satisfies all their different but related requirements. Policy makers must have a way to state security needs and concerns so they can be clearly understood and implemented. Product vendors and system integrators need clarification to help them translate policy into compliant technology and a way to demonstrate their achievements. Those responsible for evaluating products and systems to confirm compliance need standards against which to evaluate and mechanisms enabling their success.

The forum is working on developing compliance blueprints for developers, health care organizations and accrediting organizations. It also is involved in the development of standardized security profiles to specify and measure the security aspects of IT products and systems.

One way to establish the certainty and confidence the industry needs to complete implementation is through the use of common criteria (internationally recognized standard for specifying and evaluating security features of computer products and systems) for IT security evaluation. Common criteria can: (1) translate security policy into functional security specifications for products and systems, (2) enable selection of a level of assurance defined as confidence in the correct operation of a product, (3) provide a way that prospective consumers or developers can create standardized sets of security requirements that meet their needs in the form of protection profiles that then can guide vendors and integrators in their efforts to produce compliance products and systems, (4) serve as an evaluation method, supported by the availability of commercial evaluation laboratories, that offers consistent, independent and cost effective ways to help confirm compliance.

The forum is promoting community-wide use of common criteria concepts and is working to have the common criteria technology and methodology recognized by accrediting organizations, insurers and others. Ms. Gallagher encouraged HHS to proactively participate in efforts such as the forum.

Mary E. Kratz, Internet2

Ms. Kratz, manager of the Internet2 health science initiative, commended the subcommittee for gathering input from such a large and diverse group of health care participants. She noted that the creation, gathering, organizing and promulgation of health data affect a wide variety of participants, each with its own set of issues.

The Internet2 health science initiative brings industry associations in the health sciences, academic medical centers and medical schools together with the Internet community. Guidelines are being developed for safe and effective use of the Internet for clinical practice, medical and related biological research, education, and health awareness in the public.

Internet2 is a consortium of over 180 universities, working in partnership with industry and government to develop and deploy advanced network applications and technologies. The primary goals of Internet2 are to: (1) create a leading edge network capability for the national research community, (2) enable revolutionary Internet applications, (3) ensure rapid technology transfer of new network services and advanced applications to the broader Internet community. Through Internet2, working groups and initiatives members collaborate on advanced applications, middleware, networking, partnerships and alliances.

Ms. Kratz discussed the advanced application development under work by Internet2 members which enable people to collaborate and access information in ways not possible using today's Internet. Internet2 application initiatives include efforts in digital video, digital imaging, data mining, tele-immersion, virtual laboratories, digital libraries and distance independent learning.

Development is underway for collaborative efforts of academia, industry and government partners that address the application of advanced technologies. Internet2 members are coordinating efforts around health care. Applications are being developed that address needs for integrated knowledge bases, distance education, training and information delivery infrastructures. Grids are developing into a core technology for data-intensive services. Resources needed to solve complex problems are rarely co-located: the grid technologies are emerging to address advanced scientific instrumentation, large amounts of data storage and computing power, and tools for collaborations.

Internet2 members and partners are discussing new initiatives to advance the medical domain's use of Internet technologies. Internet2 middleware initiative seeks to define services for authorization, authentication, directory services and security for the academic community. The Medical Middleware Group seeks to extend these services and work in partnership with the Object Management Group's domain task force on health care, Corbamed, to apply these and other services to medical environments. Complex medical business and clinical applications are able to interoperate through the application of middleware and medical middleware. Current implementations of this technology include core services to enable person identification, terminology mediation, information access, and resource access for security.

Internet2 works closely with U. S. Federal Government agencies engaged in advanced networking technology and application development. NGI is a cross-agency effort that includes the National Science Foundation, DARPA, NASA, the National Institutes of Health, National Library of Medicine and the Department of Energy, focused on advanced networking needs of the mission agencies and the research communities. Internet2 also collaborates with the Federal Government outside of the NGI initiative. Several government research laboratories are members of Internet2 and participate in the Internet2 Abilene network to achieve high performance conductivity between researchers at university campuses and national laboratories.

To ensure that the Internet has the ability to support health applications, additional technical capabilities need to be developed and deployed. Collaboration between health and biomedical subject matter experts and the engineering community bring together the expertise required to address the next generation of the Internet.

The Internet2 Health Science Work Group is forming collaborations and projects to address a variety of areas, including quality of service, IP security, public key infrastructure, medical middleware, and distance education. The health and networking communities are developing improved network technologies vital to health applications on the Internet. Areas of interest include bandwidth guarantees on demand, strong authentication, last mile issues, disaster and operations. Discussions are underway to form project teams to address electronic health record architecture, issues related to the digital divide, use of open source methodologies for sharing of intellectual properties and appropriate uses of emerging technology capabilities. The National Library of Medicine is actively engaged with the Internet2 health science initiative. The Internet2 community is working with the NIH to define the requirements for future funding of information technology research that will develop the complementary technologies needed to enable improved networking technologies for the health care community of the future.

Ms. Kratz stated that, in the Internet2’s view, the promise for advanced Internet technology centers on facilitating broad, secure access to mission-critical health care delivery. The focus should not be primarily on speed, but on the way quality of service, multicasts, advanced video, and remote instrument operation have the potential to transform health care delivery, by combining with the right middleware and regulatory environment. Any fundamental limitations will not come from technology, but from the medical care system's opposition to adapting to the new capabilities.

Gary A. Beatty, Washington Publishing Company

Mr. Beatty discussed tools that are available to the health care industry for testing compliance. Compliance verification is a process to ensure these standards are implemented in a uniform manner consistent with the implementation guides. The Standard Transaction Format Compliance System is a compliance, verification and testing tool based upon the HIPAA implementation guides.

STFCS testing (both within an organization and between trading partners) gauges components related to the quality and quantity of interactions, and business issues relative to implementing and establishing compliance with HIPAA regulations and requirements. Quality--while referring to specifics such as the ability to map application data to and from the ANSI X12N transactions--is also a measurement of the cost effectiveness and efficiency of an organization’s transmission capabilities. A focus on quantity evaluates translation performance in terms of how well the current environment supports need: an organization with a need for 300,000 transactions a day and a translator that can only handle 5,000 transactions per hour has a problem--and needs a better solution to its environment.

Testing provides: (1) field-approved, provider proof of concept, (2) highlights issues prior to mass deployment, (3) information to determine the most feasible, tactical implementation plan--“so you maintain a process in place, a plan in place, and meet deadlines,” (4) an opportunity for the various stakeholders in the industry to work together; implementers have to work with trading partners, vendors and consulting organizations to work through this implementation process.

Mr. Beatty also commented that: (1) A successful test confirms that the submitted transaction set is syntactically correct and is validated for acceptance by any trading partner in the health care industry. (2) Organizations can validate that they have the ability to generate HIPAA-compliant transactions without taking up their trading partners' time and resources. (3) Libraries of compliant transactions, generated during testing, can serve as a list of companies that can send and receive HIPAA-compliant transactions. (4) STFCS can be used to resolve disputes between organizations.

Mr. Beatty recommended that implementers coordinate with trading partners, everyone doing their own testing first using a neutral third party, so they can validate that they have the ability to generate HIPAA-compliant transactions. Then go into a parallel stage and parallel testing, conducting business both by established means (paper, phone) and the electronic environment. And then, finally, go live between business partners.

Discussion

Responding to concerns that there was not enough commitment to making sure providers will be HIPAA compliant, Mr. Zimmerman stated that SMS has a broad initiative. Applications technologies and services teams are deployed, and an operations team ensures that the hospitals in their data center are enabled to achieve compliance quickly as a natural part of their operations within SMS. Three HIPAA design teams (code sets and IDs, transactions, and security and privacy) produced an integration module within each application area to facilitate the processing as part of the workflow. The modules automatically translate in the 270 and 271. SMS has exported that technology to over 500 customers and it is enabled across its major systems. The 835s are live in production. The challenge, Mr. Zimmerman stated, is in administrative policies and procedures. SMS does not view this as an IT challenge. This is a business challenge within each hospital, he said and added: “A third of the hospitals in this country are in the red. ”

Mr. Watkins stated that Per-Se’s biggest problem with educating clients is that “people are still doubtful. ”Per-Se’s response is to create experts within their customer base and position them in front of clients. With IDN products, Per-Se has a clinical system and a patient management system. In both, staff are deployed to learn everything they can about HIPAA, then talk to clients, not just about HIPAA, but about how they can specifically update their system to take advantage of features and comply with HIPAA.

Mr. Zimmerman stated that HIPAA tracks were always at health forums for chief medical, chief executive, and chief financial officers so they understand the importance, that “we are invested,” and the link to e-business. He emphasized that visits to help senior management teams get started positioned the message at the top. He also works with the HFMAs. SMS participates in user summits. HIPAA University provides interactive education on the Web (www. smed. com/hipaacentral).

Mr. Beatty stated that the industry is no more than five to ten percent down the road toward deployment of HIPAA. Many organizations are sitting on their hands, not ready to do anything until the final rule comes out. He shared Ms. Frawley’s concern about the vendor community. Customers will not be able to do it by themselves; they need help from the vendors.

Mr. Watkins stated that Per-Se was very concerned about the mass deployment issue. He observed that people underestimate the level of coordination necessary to bring about deployment. “To think we can individually go out and implement HIPAA is insane. ”He emphasized the need for an industry-wide coordinated effort to deploy this technology and that--without final rules--it will be difficult to start that process. Per-Se is doing everything it can to encourage payers to implement. They have begun testing with trading partners that have implemented and are getting those transactions up and running. Few payers have done it and it is very difficult to move forward without that. Another issue is that, taking it one payer at a time, no one will ever get this done in two years. It will take a coordinated effort.

Mr. Zimmerman concurred. It is demonstrated, he said; there is economic value in implementing these transactions. He added he is encouraged by payers who say that the denial rates go down when eligibility gets implemented on the provider side. “Still, people won't believe it is serious until they see the final rules. ”

Mr. Beatty observed that when many organizations look at HIPAA they only see the cost side. They do not do a cost benefit analysis. They totally ignore the benefits side and leverage the cost against moving forward. They need to look at both sides of the equation.

Ms. Stahlecker and Mr. Watkins were commended for their efforts to organize the industry toward implementation. Dr. Cohn observed that the committee heard yesterday that there were going to be some major implementation hurdles that had to be closely monitored. Hearings would continue on a regular basis, to try to identify the issues around implementation. Dr. Cohn reiterated what the committee had been hearing about the dependencies on vendors. He suggested that, while the vendor issue is handled throughout the activities and SNIP, specific focused activity around the vendors might be considered.

PANEL 6: Discussion of Early Implementers – Geographic Perspective

Walter, Suarez MD, MPH, Minnesota Health Data Institute

Dr. Suarez began and ended his presentation by urging everyone to think nationally but act locally. Despite how much deployment is recognized as a national issue, implementation has to take place locally. He illustrated the significance of the regional perspective with a brief history of the role Minnesota has played in working toward electronic commerce in health care.

In Minnesota the emphasis is on three major areas: (1) electronic transactions, code sets and unique identifiers, (2) security, and (3) data privacy. Action is on two fronts: education and awareness. Education concentrates primarily on provider organizations in rural communities with less knowledge about HIPAA or the impact it will have on their business. The second front focuses beyond education on planning, piloting and beginning now to implement the requirements.

Some 12 stateside workshops initiate the first front. A key component is a series of simple tool kits for beginning to assess where one is in terms of working toward implementation of HIPAA. Early implementers help newcomers begin. Others work with more proactive organizations. User groups disseminate information, assemble experiences different local organizations have in implementing standards. Recognizing that, due to resource restrictions, organizations cannot devote funds for everybody to work on everything at the same time, activities are prioritized, time-lined and sequenced

Work groups focus on the first three transactions: eligibility, claims and the remittance advice. Then they move into the other transactions, the code sets and unique identifiers. The primary objective is to evaluate the actual implementation guide. As a community, payers and providers are coming together and striving to come to consensus on a standard guide. Providers don't want to program multiple requirements under systems to “try to send a claim with this flavor to this payer and another with other favor to that payer. ”Payers are interested and committed in compromising and developing a common implementation guide everybody can work with. The next stage focuses on planning and beginning to implement pilot testing of these transactions. Groups will work on different activities, then exchange experiences and share results. The goal is to begin full implementation of the transactions by 2002.

The work group for the security standards has reviewed the proposed rules, submitted comments and is waiting for the final rules to come out. Meanwhile, work continues on a consensus around the standard certification policy statement and considering best practices and standard policies and procedures on security. Plans are being made for a security tool kit that can be used to assess an organization’s security fitness.

In terms of data privacy, the final rules will be reviewed from a multi-stakeholder perspective. Six core constituencies (consumers and employers, providers, health plans, policy makers, public health and researchers) represented under the health data institute will look at the final data privacy rules and assess the impact that they will have. Meanwhile, the providers, health plans and others seek consensus on a set of data privacy policies and procedures.

W. Holt Anderson, North Carolina Healthcare Information and Communications Alliance, Inc.

NCHICA is a 501(c)(3) non-profit research and educational organization with more than 150 members: providers, health plans, clearinghouses, professional groups, research and pharmaceutical companies, government agencies and vendors.

The Transaction Codes and Identifiers Work Group focused on developing a consensus among providers, health plans and vendors on the sequence and timing for implementation of the transactions and codes. Together they developed and promoted a schedule with dates for the implementation and testing of each transaction. Clearinghouses and government agencies were involved in the process. A document detailing the issues with code sets and transactions was produced and circulated.

The Data Security Work Group developed a checklist: a tool with 521 closed end questions that directly map the proposed security requirements. It is available through NCHICA’s Web site.

The Network Security & Interoperability Work Group is analyzing requirements for the use of secure communications and developing a basis for secure transaction interoperability among members. The work group is also determining how members can best benchmark, select, and negotiate a contract with a vendor.

The Privacy and Confidentiality Focus Group analyzed the proposed privacy regulations and provided comments on the NPRM. When the final rule comes out, the group will map differences between national and local laws and regulations to determine the “most stringent. ”Mr. Anderson stated that NCHICA does not anticipate that state law will be preempted; the work group has been involved with privacy legislation in North Carolina since 1995 and is responding to the proposed privacy regulations.

Through The Awareness, Education and Training Work Group, NCHICA, in conjunction with the state licensing agency, will conduct a series of surveys to assess and increase community awareness and readiness. The work group is developing a speakers’ bureau, educational programs, workshops and training programs on implementation of specific transaction or code sets. Mr. Anderson noted that NCHICA has the buy in and participation of the NC Medical Society, the NC Nurse's Association, the NC Health Information Management Association, the Medical Group Managers Association and The NC Association of Local Health Directors. NCHICA is reaching the members it believes will be toughest to bring along: the smaller physician and nurse practitioner practices.

Mr. Anderson discussed several key issues NCHICA encountered: (1) The state and private members lined up financial and contractor resources based on when issuance was expected; delay on the final rules has efforts locked out of budget cycles--getting funds re-allocated is difficult, (2) Phase in the rules; they cannot be implemented all at once, (3) Cost concerns--especially with the smaller practices and that 30 percent of the hospitals that are under water financially, (4) The privacy regulations are unknown, ambiguous and a concern, (5) The lack of resources is a real issue.

Elliot M. Stone, Massachusetts Health Data Consortium, Inc.

Mr. Stone discussed MHDC’s success in identifying and assisting health care organizations to become early adopters of HIPAA standards. A prime motivation for MHDC becoming a catalyst for HIPAA, he explained, was the need to overcome the lack of interorganizational rules for confidentiality, security, and electronic transaction standards--barriers to success for any health data organization. MHDC needed to find a way to exchange clinical and administrative data among health care organizations and the community.

Mr. Stone stated that MHDC’s first lesson and their recommendation to the committee is that, since health care and HIPAA implement at the local level, HHS services should develop partnerships with regional and local organizations to build awareness of, and compliance with, HIPAA standards at the community level.

MHDC adopted a three-phased strategy for HIPAA compliance in the region: education, communication and resource sharing. Its first major activity has been to educate the community about the value of standards, through the CIO forum. The forum includes eight information technology companies and the chief information officers of 27 health care organizations. Half are from provider systems; half are health insurers.

Mr. Stone observed that health care communities need to: (1) identify and convene their opinion leaders (especially opinion leaders on technology), (2) gain consensus on the return on investment and benefits of HIPAA compliance through the IT and business departments, and (3) provide neutral forums to educate all members.

A second major activity has been to communicate HIPAA resources on MHDC’s Web site and alert members and colleagues about new content with weekly e-mails. Examples include: work sheets on how to prepare a HIPAA compliance budget, confidentiality guidelines on patient consent, a compendium of privacy principles, summaries and comments on the HIPAA NPRMs, articles by local and national experts, and links to client advisories from the major law firms. A privacy resource center on the site leads to information about privacy, confidentiality and security. Mr. Stone emphasized the importance of providing practical, useful information and tools for the project leaders at the hospitals, health plans and other provider groups, charged with HIPAA implementation.

A third major activity is resource sharing: MHDC’s library researches members’ questions about HIPAA. White papers, research reports, and literature packets are built around these questions. MHDC has also fostered two collaborative organizations: the New England Health Care EDI Network and the Community Health Center Network (NEHEN). CHCN is working on the 278 transaction with a neighborhood health plan in Boston whose constituency is mostly Medicaid recipients and community health centers. MHDC also facilitated meetings between Medicaid, the Boston Medical Center, vendors, and NEHEN.

Mr. Stone reiterated the importance of making the business case for standards: how they facilitate prompt payment and increase the return on investment. Standards improve outcomes, error prevention and efficiencies.

Eric Bartholet, Computer Science Corporation, Worldwide Healthcare Consulting Group

Mr. Bartholet discussed technical and process-related issues that had to be overcome in implementing the HIPAA transactions for NEHEN. NEHEN is a consortium of payers and providers in eastern and central Massachusetts, who are collaborating on the implementation of the HIPAA EDI transaction sets. Most of the region's largest provider networks, and two of its largest managed care organizations are members. It is an open organization; any payer or provider may join for a flat monthly fee. NEHEN provides conductivity to Medicare and Medicaid; provider members have access to all four payers through a consistent user interface.

NEHEN’s primary objectives are: (1) address HIPAA compliance issues; all transactions currently flowing over NEHEN network are HIPAA compliant, (2) improve service efficiencies through EDI.

NEHEN went live with eligibility verification in 1998. The next planned transaction is the claims status inquiry, scheduled for August 2000. It took about a year to develop the infrastructure; new members can begin trading transactions within a few months of joining NEHEN. Current transaction volumes are about 220,000 a month.

Two key implementation issues have affected NEHEN’s progress: (1) providers have typically required a significant amount of redesign of their patient access processes prior to implementing eligibility transactions. The gain has been higher quality data and fewer rejected claims, but these redesigned processes affect how soon providers can effectively implement HIPAA transactions. (2) the key to maximizing the value of the eligibility transaction for providers is to integrate the function within their core information system.

One of the biggest challenges provider members have had is that the region's payers offer unique technologies to access their member data. Current local access methods include card swipe devices, PC dial-up technologies and interactive voice response units. The promise of HIPAA's administrative simplification is to consolidate these methods into a single standards-based approach, allowing access to all payers from a single user interface. This will not go far enough. To maximize value to providers, HIPAA transactions need to be fully integrated into the core application workflows, eliminating any need for multiple data entry.

The challenge at NEHEN is that few vendors fully support the HIPAA transactions. The fact that a typical large IDN often has multiple registration systems from multiple vendors that need to be integrated further compounds the challenge. Mr. Bartholet emphasized that overall, NEHEN's experience with the implementation of eligibility and specialty referral transactions has been very positive. Both payers and providers have seen significant financial and operational benefits from early implementation. Benefits include: (1) reduced telephone-based customer-service support requirements for the NEHEN payer members, average eligibility verification time reduced from seven to one minute--providers can verify nearly 100 percent of all patient visits. (2) claims rework has been reduced by up to 25 percent; in one study up to 35 percent of rejected claims were directly attributable to incorrect eligibility information. (3) An audit trail of all transactions was created, facilitating better management of the verification process.

Mr. Bartholet urged the committee to explore ways of encouraging vendors to make their products HIPAA compliant “sooner, rather than later,” reducing the costs and time associated with implementation. He suggested HCFA could compile and disseminate information on vendor compliance efforts.

Mark Gordon, Thomas Edison State College

Mr. Gordon discussed New Jersey's proactive approach to achieving health care administrative simplification. The Healthcare Information Networks and Technologies (HINT) study found in 1994 that EDI technology and national health care transmissions standards could result in as much as $760 million in annual cost savings or cost avoidance in New Jersey. The HINT study suggested pilot projects and legislation. As a result of the HINT findings and recommendations, HINT legislation (S-323/A2119) was developed with input from both the public and private sectors involved with healthcare. With bi-partisan leadership support, both the New Jersey State Senate and the New Jersey General Assembly unanimously approved the HINT legislation. Governor Christine Whitman signed the HINT legislation into law on July 1, 1999 (P. L. of 1999, Chapter 154). The HINT law promotes the use of EDI technology in New Jersey, and prompt payment of healthcare claims along with the national health care standards--specifically HIPAA--wherever possible, to achieve administrative simplification and cost efficiencies for both the public and private sectors in New Jersey.

As part of the HINT study, a statewide survey regarding how health care information was processed, the use of current information technology, associated costs, and defining and overcoming barriers to the use of information technology was mailed out to 1,250 different participants. It elicited a response rate of 34 percent from seven segments of the state health care industry. The major barriers mentioned were: (1) costs associated with change, (2) the then current lack of national standards, and (3) concern about confidentiality of health care information in computer networks and databases.

The HINT study revealed all healthcare entities save money by processing claims electronically instead of submitting paper claims. With electronic processing: (1) the average cost per claims is less, (2) the costs to both the payer and the provider are less, (3) the rejectionrate is 31 percent less, (4) the rejection rate for follow up on claims is 44 percent lower, (5) accounts receivable payments are almost twice as fast -- 30 days versus 57 days for paper.

Under the New Jersey HINT law: (1) providers submit health care claims on behalf of patients, (2) payers of health care claims are required to accept and transmit healthcare electronic data interchange (EDI) using HIPAA standards; the payer cannot say, “send paper and we will let you know,” (3) a state HINT Advisory Board assists in information EDI technology policy, including measures to protect the confidentiality of medical information, (4) prompt payment of health care claims: 30 days for EDI and 40 days for paper, and (5) acknowledgment of EDI claims within 2 days and 10 days for paper claims.

Mr. Gordon pointed out that the State Department of Health and Senior Services (DHSS) data intermediary project is converting hospital inpatient reporting from mailing tapes to an electronic reporting system which will reduce hospital transmission costs by 60 percent. This particular state project is the first in the nation to have the ANSI 837 version 4010-I, a HIPAA-required standard, certified as compliant by the Electronic Health Network Accreditation Commission in January 2000. As part of this project, the vendor was required by DHSS to have the transmission certified HIPAA compliant by an outside certification firm.

William O’Byrne, Department of Banking and Insurance, State of New Jersey

Mr. O'Byrne, a regulatory officer responsible for writing and drafting the rules and regulations, discussed the HINT law, a first attempt at early implementation of HIPAA. New Jersey's implementation of HINT is dependent upon the adoption of the transaction and code sets by the HHS. HINT requires Mr. O’Byrne’s department, DOBI, to establish a timetable within 90 days of the date that federal rules are adopted for transaction and code sets. This timetable will fix the dates for the implementation of a system for the electronic receipt and transmission of health care claim information by payers who do business in the state of New Jersey.

DOBI has drafted the proposed rules for the establishment of this timetable, which places the department in a position to file administrative rules in conformance with HINT pursuant to the State of New Jersey's administrative procedures act.

Prompt pay provisions require all payers to pay uncontested claims no later than 30 days after receipts filed electronically or no later than 40 days if filed manually. Payers will be required to implement a system for the electronic receipt and transmission of health care information transactions within 12 months of the DOBI adoption -- well before the HIPAA standards become mandatory. Payers may notify DOBI of the need for extensions and waivers within 180 days of the adoption of the timetable. Extensions will require that the payer demonstrate that compliance will result in an undue hardship to the health care payer, its subsidiaries, or the covered persons.

DOBI is preparing a HIPAA HINT questionnaire that will be sent to all payers. The questionnaire will enable DOBI to position payers by implementation stages. It will also serve as a wake-up call to payers who have not already taken action.

After HIPAA is adopted, the proposed rules will be published. Unless excused or extended, 12 months after the adoption of DOBI's rules, all payers will be expected to handle claims transactions electronically.

Bart Killian, Utah Health Information Network

Mr. Killian stated that HIPAA can, and should, be successful because UHIN succeeded in Utah. He noted efforts began in Utah with a one-line attachment to an Insurance Commissioner law: “All payers shall be able to accept electronic claims by July 31, 1995. ” UHIN has been ongoing since 1991. Production began with ANSI 835 and 837; 3032 and 3051 are used for Medicare. Some 90 percent of UHIN’s provider base is in Utah. That coalition includes every hospital, about 99 percent of the physicians, and all payers but one in Utah. UHIN translated backward from its X12 standard to NSF in order to provide service to most of its 400 national payers.

Gaining initial trust and buy-in was difficult, Mr. Killian said. One reason for UHIN’s success is that they recognized early on that, in health care, every entity is a customer of the others. UHIN strove for consensus and put itself at the center as everyone’s ally and arbitrator.

The second thing UHIN learned is: “Make all the laws you wish, but what you must do is bring immediate, ongoing value to your partners. ” One immediate value UHIN created was leveling the playing field for providers in Utah. “People say that rural and small town providers will not adopt. Rural providers in Utah were the first to use electronic claims and among the first to use electronic remittance advice because, suddenly, they could have the same turn-around time for payment as the urban centers. ” Mr. Killian reiterated the need to understand value: for Utah’s rural providers, the value was geography no longer made a barrier.

Another thing one must do--and it was one of UHIN’s great problems, is—one must have a process in place to identify and resolve issues quickly. If one does not have a way to resolve issues, one loses a role on what is happening. UHIN leveraged the synergy of the group. UHIN took small measured steps and experienced successes. Define the steps in a way that everyone can use “the old American value” of return on investment. With every step, UHIN demonstrated that its partners could recover their initial investment in less than six months. UHIN substantiated that costs had decreased to the end users -- payer, provider, government and industry.

Mr. Killian noted that UHIN serves as a link between local and national levels. UHIN is involved in HL7, WEDI, ANSI, Health Key and other entities and actions. Providing representation in the broader community and bringing back both a working sense of the situation nationally and experiences and solutions of other coalitions is at the core of UHIN’s agenda.

Mr. Killian focused on the need to put in place nationally a process to resolve problems inherent in implementing HIPAA standards. He stressed: (1) the need to be proactive and initiate business-driven solutions, (2) establish a process to deal quickly with problems about standards including a way to propose and modify them in a succinct timeframe. Utah's standards are similar to HIPAA. UHIN learned how to be able to change them when problems were identified or business needs changed. UHIN utilized open discussion and consensus to clear a way to solutions.

UHIN has reduced the 236 HIPAA standard reason codes and combinations to 90--“a number a provider's office can memorize and understand. ” Mr. Killian reported a savings of over 300 percent compared to 1995. He stated UHIN believes costs can again be reduced by at least that much with single standard identifiers. Having the identifiers would solve a number of problems. He strongly recommended that they be brought forward. In summing up, Mr. Killian emphasized: the success factors that will make HIPAA work will be value driven, and part of a reasonable, timely ongoing process.

Discussion

Mr. Gordon clarified that the $760 million savings highlighted in the New Jersey HINT study was a total potential annual cost savings, calculated over a five-to-eight-year period with an understanding that it would not be realized in the first year.

Mr. Bartholet clarified that the New England Health Care EDI Network has access to four payers; two are managed care organizations: Harvard Pilgrim Health Care and Tufts Health Care. NEHEN also provides access to Medicare and Medicaid through the same gateway.

Responding to a query about HIPAA compliance, Mr. Bartholet stated that NEHEN has eligibility verification live today. Not all the transactions are available. In order to facilitate the vendors' data collection, CSC took whatever EDI capabilities existed within the vendor's applications and whatever data they could get easily. The data was then put into a gateway where they map and convert into a HIPAA-compliant transaction. SCS and NEHEN both put a gateway at each of the provider organizations' sites.

Mr. Stone emphasized the importance of trickle-down clout. Employers are the top of the trickle-down process; they need input so that they can say to their health plans, “Let us know early in our contract negotiations about your plan to be HIPAA compliant for at least the enrollment. ” MHDC is developing companion guides to the enrollment transaction and intends to offer contract language for use in vendor contracts.

Mr. Killian agreed. The employers pay for health care; they drive this whole process. Major employers have told health plans, “If you are not electronic, not using UHIN and not dealing with providers who do the same, we’ll go elsewhere. ”

Mr. O’Byrne described how, as DOBI is filing rules that will force HIPAA compliance, payers in New Jersey are requesting to raise their premium in order to accumulate money for implementation. They have to comply within 180 days of the adoption or secure additional time. Mr. O’Byrne said that is going to be quite difficult for them to do.

Expanding upon his earlier discussion, Mr. Bartholet pointed out that if the eligibility transaction is at the front end of the process, it is being done when the physician's office or the patient is on the phone or right there. Any information not in the system can be captured doing the transaction. Asked about vendors that could exchange the eligibility claims, Mr. Bartholet replied Medetech, IDX, Eclipsis, and some homegrown systems. Mr. Gordon stated that the data intermediary project had found a multitude of IT systems within the hospital settings. Some vendors have been proactive with five pilot hospitals. Others failed to make progress during the 6-month pilot period. Mr. Killian stated that all of the hospital vendors and many large group practice vendors are cooperative. That accounts for about 80 percent of the eligibility and claims volume. The other 20 percent is “huge;” it becomes 80 percent of the end point. Mr. Killian observed that smaller group practices have more trouble. Their practice management systems are inexpensive, but they are not integrated and probably will not be. Alternatives are costly. Finding vendors willing to implement HIPAA in these shrink-wrapped or homegrown practice management systems will be a problem.

Mr. Gordon pointed out that the vendor often has installed different versions of software programs. What version will they make HIPAA compliant and how long will they support others?

Appreciation was expressed to the panelists for increasing awareness of major issues. Dr Fitzmaurice and Dr. Cohn advised being prepared to make the annual adjustments that HIPAA permits as the industry continues to feedback through forums, such as the NCVHS hearings.

Dr. Suarez clarified that Minnesota plans to work on the HIPAA implementation guide. The evaluating and work being done toward community consensus focus on optional elements. If payers and providers can reach consensus, providers in Minnesota will not have to send situational things to different payers.

Mr. Stone concurred, suggesting the negotiated phrase is “a companion” to the implementation guide. Timing, scheduling, definitions--these are being worked out. The implementation guide will be sacred, but it will always have a companion.

Mr. Killian added that the adopted implementation guide for eligibility is primarily situation. In Utah, add-ons were created. They are called standards, to differentiate. He quoted Dr. Suarez: “We need to have national standards, but we have to implement locally. ” Medicine and its payment, he said, are regional issues.

Subcommittee Discussion: Next Steps.

Dr. Cohn summarized what the subcommittee had learned and began to identify next steps. He noted that the issues are very significant and include problems with the external code sets. There seemed to be a fair amount of risk in terms of maintenance and updating of elements that slip between the medical code sets and that portion under the control of the SDOs. He indicated attention needs to be paid to this void.

Another issue is establishing a timely process for getting codes for Medicaid and others. Dr. Cohn noted this seemed partially addressed, but noted enough resources need to be put into that effort. Again there is some risk, as everyone moves from national to more local codes. The communication process around this seemed broken. Probably the effort needs to be expanded beyond Medicaid; a lot of local codes “out there” need to be included in the appropriate set.

Dr. Cohn observed the need for ongoing comprehensive assessment of the industry’s progress towards implementation. This is going to be a much bigger activity than initially perceived. Tracking implementation will be an ongoing effort.

Dr. Cohn said he heard the need to ask the Secretary to make sure there is adequate funding in HHS to facilitate implementation occurring in an expeditious fashion. He agreed with the ­­­panel that funding was necessary to accelerate the identifier process. For providers and health plans--especially providers--funding will be important.

Dr. Zubeldia stated that compliance with the transaction standards needed to be assisted. Everyone had pointed out that the testing was a long process. He identified compliance testing as a marketing opportunity for the vendors, but noted that only about a dozen companies that STFCS tested showed their dots. Dr. Zubeldia suggested that establishing a national testing center or uniform testing and certification policies might help.

Ms. Fyffe reiterated the need to track major implementation issues and obstacles. Testing could bring problems to the surface. Local codes are one example; she remarked. What else might be out there?

Mr. Blair stated that consultants and others are beginning to offer tools, capabilities and assessments to provide certification information. The missing link, he pointed out, is to get information to the providers and the payers so that they can make intelligent choices.

Dr. Zubeldia asked what could be done to prevent the providers from being misled by vendors who imply they are HIPAA compliant. Mr. Blair noted that a number of panelists had made an assessment of the readiness of a vendor, provider or payer. One had a tool to gauge compliance; another did surveys to verify compliance. He said if providers and vendors knew who could provide evaluations of compliance, it would help them move expeditiously. Dr. Braithwaite recalled a problem that came up in the testimony about a certifier who checked another’s results and none compared. HIPAA standards are out there, but apparently people are not certifying in a consistent way.

Ms. Trudel noted another way to address this issue might be to provide providers with check lists and questions: “Check to see if vendors tested with the STFCS system. Are they compliant with the common criteria?” Dr. Cohn noted how technical many of these issues are and said he would like to see some certificate of compliance. It did not need to be a government certificate, but he commented it would be nice if two different compliance groups did a test and it came out with the same result. He observed that, from the vendors’ side, this must be very complex--This was something the Subcommittee needed to hear from them.

Dr. Fitzmaurice discussed alerting the Secretary that delaying the publication of final HIPAA regulations had reduced the credibility of those who urged planning for these standards. And it also caused a decrease in resources budgeted for HIPAA implementation in 2000—and, quite likely, in 2001. Another thing Dr. Fitzmaurice said he heard was that the implementation guides and the data dictionaries were not adequate. He suggested assessing the role of the government versus the market; support might be needed to improve the implementation guides. Given just how much had been learned at these hearings and how much more there is to go, Dr. Fitzmaurice urged considering having regular hearings over the next three years, perhaps every four months, so that people can regularly have an assessment point for immediate HIPAA issues, and monitor those already identified. He observed that, with all of this activity, there might be a need for a focal point that monitors, supports and leads health data standards processing generally in the United States. Leadership might be needed to start assessing the private and public sector roles and funding for things within the domain of the government. An entity might be needed to urge other agencies engaged in health care transactions to coordinate efforts and contribute to the leadership and the “grunt work” in getting these standards out and used.

Dr. Zubeldia mentioned concerns about the data content. She noted that because of “an arcane, obscure and maybe foggy” process to implement national HCPCS codes, the states developed a local code mechanism that was easy for them. Instead of going to HCFA with a request for a national HCPCS code, they made their own local code. Whether or not that code was the same in all 50 states, it fit their need and was expedient. Dr. Zubeldia cautioned that the same situation could happen with implementation guides. A process--MOU—had been agreed to, but what they heard was every state is developing its own local variations and intends to continue, rather than take them through the MOU process to refine the national implementation guides. This could create a permanent state-by-state variation, because the national process is perceived to be too difficult.

Another concern Dr. Zubeldia cited that needs to be explored further is the matter of data requirements. Claims are being paid, eligibility inquiries are being responded to, referrals are working--all with the data we have today. But, somehow, the data requirements are changing. 4010 requires more data than is being captured today to do the same function. Dr. Zubeldia questioned if the data requirements in the implementation guides are too strict—if trying to impose requirements that do nothing beyond calling for new collections of data is going to impede implementation. Is it reasonable, now, to require anything beyond what already works in the NSF or the UB92? Ms. Trudel volunteered to have her group look at what the gaps exactly are. It was mentioned that NUBC and NUCC have been looking at this and could probably be of assistance.

It was put on the agenda for the September breakout. Another item is a discussion about a work plan outlining next steps for the PMRI standards. A panel on ICD-10 (including a discussion on the standards for digital signature) is being considered as part of the October hearings. Panelists from these two days offering industry assistance will be asked for an update. Input from the vendors on where they are, their issues, and how far they are in terms of HIPAA will be scheduled for the October hearings. A discussion about the first report of injury can also be scheduled for the October hearings, should anyone come forward. X12 is eager for the subcommittee to recommend some new X12 transactions to the Secretary for adoption for a second round; part of those two-day hearings will be spent asking for anything else to be recommended.

Dr. Cohn thanked the members for their participation, and the hearings were adjourned at 2:03 p. m.


I hereby certify that, to the best of my knowledge, the foregoing summary of minutes is accurate and complete.

/s/ Simon P. Cohn 4-13-2001

_________________________________________________

Chair Date