- Contact the Committee

Mr. Chairman and distinguished members of the Subcommittee, I am Dr. John Halamka, the CIO of Beth Israel Deaconess Medical Center and Harvard Medical School. I am grateful for the opportunity to testify before you today on the creation, management and exchange of both clinical and administrative electronic medical records.

Exchanging Clinical Records via the Web

Introduction

The same technologies that send web pages from one site to another on the public Internet can shape a private medical intranet that assembles a “virtual” medical record that draws on sources of heterogeneous information. But, barriers to creating virtual medical records on intranets abound. Some are technical: correctly identifying patients, guaranteeing data integrity, and protecting confidentiality. Some are organizational: standardizing the types of information exchange, providing appropriate sanctions for violation of security policies, and obtaining patient consent for transmitting information among multiple institutions.

Several groups have proposed solutions for such technical and organizational challenges and have implemented systems that use intranets to provide clinical information to health care providers. [Kohane, Fraiser] This holds special impact for emergency departments that constantly struggle with providing care based on incomplete information about medical histories. To illustrate both the challenges and some early solutions, we describe the early experiences with a live implementation, CareWeb, that shares complete medical records information between multiple healthcare organizations on a corporate intranet.

The Beth Israel Deaconess Medical Center, the Joslin Diabetes Center, two Boston area community hospitals, and several satellite outpatient clinics have clinical affiliates that that required the integration of existing electronic medical records. Each site has different clinical computing systems, different institutional vocabularies, and varying completeness of clinical information.

Beth Israel Deaconess stores clinical data and several related practices in a comprehensive, custom built computing system [Bleich], while clinical data at Joslin Diabetes Center resides in an industry standard database. Our goal was to consolidate medical records “virtually” at these heterogenous institutions, using the corporate intranet and to make that information available to practitioners at the point of care.

CareWeb operates in response to a care provider who, using a standard web browser, creates a query for information by specifying patient identification. This information is submitted over the intranet to CareWeb which, in turn, generates a request for information the Beth Israel Deaconess, Joslin and community clinical computing systems. The systems respond with demographics, problems, medications, and records of allergies, notes, and visits. CareWeb interprets the incoming messages and creates a single, unified presentation that it returns to the health care provider as a series of web pages. Tool bars enable full navigational control, allowing the medical record to be scanned using a tab folder-like paradigm.

Barriers to using an intranet

Barriers, both technical and organizational, preclude a uniform infrastructure for exchange of medical records on an intranet. To exchange patient identified information among hospitals, even apparently simple tasks, such as identifying the correct patient, can be a challenge.

Identifying the patient

In the United States, there is no universal healthcare identifier to identify individual patients. A logical approach is to use a combination of demographic identifiers – such as name/date of birth/gender or social security number. However, demographic identifiers are often mis-entered or mis-reported, making patient identification a difficult problem. Teich and colleagues at Partners Healthcare in Boston [Teich] found a 3% discrepancy in birth month for known matched patients, and a 39% discrepancy in last name. Another study [Goldberg] found a 2.4% discrepancy in gender for known matched patients.
The Health Insurance Portability and Accountability Act of 1996 (PL 104-191) [HIPAA] stipulates that Health and Human Services devise a strategy for universal patient identification by 1998. Current suggestions span the gamut from the social security number to the use of long random numbers, unique to each individual. [Szolovits]

CareWeb uses a statistical probabilistic best match of name, gender, date of birth and other demographics to group the medical record numbers of each patient together into a community member index. All clinical data resides in the clinical computing systems of each health care facility, but the common patient index provides pointers to patient specific information at each location. Beth Israel Deaconess, Joslin and the Community Hospitals are electronically interfaced to this community member index such that each new patient registration automatically updates the index with patient demographic information, medical record numbers and pointers to clinical data at each site.

Data format and Vocabulary

Medical records contain data elements that vary widely among hospital systems, both in definition and in the amount of data available. To exchange electronic medical records successfully, all partners involved in the exchange must first define the uses for the data and then elect a consistent set of elements most relevant to the intended use. For example, a clinical emergency department application requires a set of data far different from an application assaying managed care eligibility. Data elements must also address potential legal and social sensitivities. A patient may agree to share insurance authorization information, but not HIV status.

Several standardized data sets have been suggested for emergent clinical use, including the Center for Disease Control's Data Elements for Emergency Department Systems (DEEDS) [Pollack], the Boston Collaborative data set [Kohane], and the National Information Infrastructure Health Information Network Emergency Medicine data set. [Barthell]

But even if partners agree on data elements to exchange and a consistent way to request information, the data exchanged may not be easily comparable. Hospital systems are heterogeneous, and most lack uniform vocabulary. One hospital may list a diagnosis as “hypertension,” while another may code the same diagnosis as “high blood pressure.” Similarly, medication lists assembled from multiple hospitals might appear as Naproxen Sodium, Naprosyn, and Aleve.

Vocabulary standards solve the problem of data comparability. ICD-9-CM coding is one of those most familiar. By coding all medical records with ICD-9-CM codes instead of physician-generated English descriptions, hospital discharge records become comparable. The international Systemized Nomenclature for Medical and Veterinary Medicine (SNOMED) provides a comprehensive set of over 150,000 terms organized into twelve categories – anatomy, morphology, normal/abnormal functions, symptoms or signs, chemicals, drugs, enzymes, organisms, physical agents, spatial relationships, occupations, social contexts, diseases, and procedures. [SNOMED]. The National Library of Medicine’s Unified Medical Language System (UMLS) has concept identifiers that group these ICD-9 and SNOMED terms into a single nomenclature. [Humphreys] The Logical Observation Identifier Names and Codes (LOINC) provides a library of over 6500 clinical test names or identifiers. [LOINC] Finally, the National Drug Code (NDC) provides a standard dictionary of medications. Although most institutions do not use all of these vocabularies, it is possible to translate institution specific data into standard terminologies during the presentation of medical information to clinicians. [Law]

At each hospital, a site-specific CareWeb program intercepts incoming requests for information. These programs have knowledge of the computer systems at each site and translate hospital specific information into standard vocabularies – ICD-9-CM for diagnoses, NDC for drug information, and LOINC for laboratory. Once translated into standard vocabularies, messages are sent between CareWeb sites using Health Level 7 [HL7], a standard data format for medical information interchange.

Security/ Confidentiality

In his 2004 state of the Union address, President Bush noted that we should implement interoperable electronic medical records to reduce medical errors and healthcare costs. However, the security and confidentiality implications of web-connecting the nation's clinical data from a major impediment in realizing this goal. [Woodward, Rind]

In 1995, the National Research Council of the National Academy of Sciences was charged with evaluating practical measures that can reduce the risk of improper disclosure of confidential health information, while providing appropriate access to those interested in improving quality and reducing the cost of care. Their March 1997 report, "For the Record: Protecting Electronic Health Information," presents the findings of two years of collaborative investigations which delineate best technical and organizational practices to protect patient confidentiality [NRC]. Intranet medical record systems should incorporate these recommendations, and recent legislation emphasizes the need to implement strong security measures. For each unauthorized disclosure, the Health Insurance Portability and Accountability Act of 1996 (PL 104-191) [HIPAA] imposes a fine of up to $250,000 per incident, and up to five days of imprisonment. In addition, failure to protect patient information and patient privacy can result in loss of accreditation. Implementation of this act is anticipated in mid-1998. CareWeb incorporates all NRC guidelines for protecting health care information and the techniques for this are discussed elsewhere. [Halamka]

Authentication

The authenticity of each CareWeb user is guaranteed with a strong username and password. Passwords expire every 90 days, must be at least 6 characters in length and may not be English words.

Access Control

Once authorized, CareWeb determines each user's role from a database, and this role is used to restrict access to specific areas of the medical record. Currently, clinicians are allowed to examine the full record, while registration clerks are limited to demographic information.

Audit Trails

The security policy of the Beth Israel Deaconess Medical Center is to provide auditing at the level of the specific patient queried and the individual menu selections used. [Safran] CareWeb implements a complete multi-organizational audit trail.

In any multi-institutional reporting system, there are two places to capture the audit  either at the institutional level where the information is stored (the sites), or at the point where the information is delivered. Careweb audit information is captured at the site level. By storing audit trails at each site, each hospital can control and audit the information that leaves its site, regardless of where it is delivered. Each hospital site server captures patient identification information, the requester, the requester's location, date, time, and information requested. Although information is stored at the site level, a multi-institutional auditing system that provides patients with the details of the movement of their medical information throughout the healthcare enterprise is available. The auditing query system has the same hardware token authentication and access controls required for any CareWeb healthcare data request. Once authenticated, an auditor enters patient identification information and submits the information to the CareWeb auditing system. It produces a consolidated report showing all flows of information about the patient for all institutions.

Protection of External Communications

The existing hospital computing systems at all the healthcare facilities connected to CareWeb employ a complex series of hardware controls that limit direct connectivity to clinical servers from outside the institution.

Encryption of Public Network Transmissions

For communications between data sources and CareWeb users, we implemented a cryptographic system that incorporates industry standard components for digital signature and encoding of messages, using the most secure keys available.

Electronic Authentication of Records

CareWeb uses digital signature cryptography methods for all network transmissions, ensuring the integrity of all health data delivered. The NRC recommends an implementation of digital signature to ensure that medical records are not changed on the individual systems where they are stored. The CareWeb architecture provides a secure mechanism to transport each institution's data and can guarantee that the data were not changed during the retrieval process. Security policies of each institution providing data dictate the reputability of the data.

Physical Security and Disaster Recovery

Multi-institutional architecture provides significant physical protection for health data. Instead of physically locating all patient records in a central data source vulnerable to physical disasters, the CareWeb architecture creates a virtual record that is assembled on demand and not stored in a central repository. Currently, all hospital computers linked by CareWeb are geographically dispersed and are locked in secure computer rooms accessed by electronic key code. The CareWeb architecture depends upon the physical security and disaster recovery practices of the individual sites that provide data. However, if any sites sustain a disaster and cease to provide data, CareWeb notes that a site is currently unavailable and provides a virtual medical record comprised of all functioning sites.

Software Discipline

Web pages returned by CareWeb cannot be stored on local hard disks by the browser. Three specific techniques are used to prevent such behavior. The pages are given an expiration date of January 1, 1970 and arrive “out of date.” The pages are sent with a special message instructing the browser not to store them. Finally, the pages are sent in a secure mode (secure sockets) which most browsers use as an indicator to not store pages.

Discussion

Continuing reports of flaws in Internet security give a public impression that internet technologies are not suitable for transmission of sensitive information, and this creates difficulty in obtaining institutional support. Consensus for deploying such a system must include information systems personnel, hospital administrators, patients, and clinicians.

Several groups are working to define data and security standards to encourage the development of a national infrastructure for medical data exchange, including HL7 (www.hl7.org), the EHR Collaborative (http://www.ehrcollaborative.org) , and the NHII project (http://aspe.hhs.gov/sp/nhii/).

Implementation of federal legislation mandating universal patient identification combined with the efforts of researchers, public interest groups, and industry fuels a rapid evolution of the infrastructure required to exchange medical records using intranets. With an appropriate balance between confidentiality and the need for clinical information, an intranet-based system will benefit patients and physicians and ultimately lead to better care.

Acknowledgements
Funded in part by a cooperative agreement with the Agency for Health Care Policy and Research and the National Library of Medicine Sharing Paperless Records Among Networks of Providers Grant (U01 – 08749).

References
[Kohane]Kohane IS, Greenspun P, Fackler J, Cimino C, Szolovits P. Building National Electronic Medical Record Systems via the World Wide Web. Journal of the American Medical Informatics Association 1996;3(3):191-207.

[Szolovits] Szolovits P, Kohane I. Against simple universal health identifiers. Journal of the American Medical Informatics Association 1994;1(4):316-9.

[Fraiser]Frasier H, Kohane I, Long W, Using the Technology of the World Wide Web to Manage Clinical Information, British Medical Journal, No 7094 Volume 314 Saturday 31 May 1997 P 1600-4

[Baker] Baker, Dixie B., Robert Barnhart, and Teresa Buss, "PCASSO: Applying and
Extending State-of-the-Art Security in the Healthcare Domain," Proceedings
of the Annual Computer Security Applications Conference, San Diego, CA,
December, 1997.

[Halamka]Halamka JD, Szolovits P, Safran C, ”A WWW Implementation of National Recommendations for Protecting Electronic Health Information”, Journal of the American Medical Informatics Association, 4(6), November 1997.

[NRC]For the Record: Protecting Electronic Health Information, Computer Science and Telecommunications Board, Commission on Physical Sciences, Mathematics and Applications, National Research Council, National Academy Press, 1997.

[Washington Post]Schwartz J and Saffir, Barbara J., "Privacy Concerns Short-Circuit Social Security's Online Service", Washington Post, April 10 1997

[HL7] Health Level Seven: An application protocol for electronic data exchange in healthcare environments, version 2.2, Chicago, Illinois Health Level Seven 1990.

[Rind]Rind D, Kohane I, Szolovits P, Safran S, Chueh H, Barnett G, Maintaining the Confidentiality of Medical Records Shared over the Internet and World Wide Web, Annals of Internal Medicine, July 1997.

[Woodward] Woodward B. The computer-based patient record and confidentiality, N Engl J Med., 1995;333:1419-22.

[Safran] Safran C, Rind D, Citroen M, Bakker AR, Slack WV, Bleich HL. Protection of confidentiality in the computer-based patient record, MD Computing, 1995; 12:187-92.

[GoldbergJ] Goldberg, J et. al, A Strategy for Assembling Samples of Adult Twin Pairs in the United States, 12:1693-1702.

[Pollack]Pollack D, “Data Elements for Emergency Department Systems (DEEDS)”, Annals of Emergency Medicine 31(2):264-273, 1998.

[Barthell] Barthell EN, Kulick SK, Felton CW, et al: The National Information
Infrastructure – Health Information Network. Top Emerg Med 1995;17:17-23.

[LOINC]Forrey AW, McDonald CJ,DeMoor G, Huff SM, Leavelle D, Leland D, Fiers T, Charles L, Griffen B, Stalling F, Tullis A, Hutchins K, Baenziger J, Logical observation identifier names and codes (LOINC) datbase: A public set of codes and names for electronic reporting of clinical laboratory test results. Clinical Chem 42(1):81-90, 1996.

[SNOMED]Cote RA, Rothwell DJ, Palotay JL, Beckett RS, Broch L, eds., The Systematized Nomenclature of Human and Veterinary Medicine: SNOMED International” Northfield IL, College of American Pathologists, 1993.

[Law]Law V, Goldberg HS, Jones P, Safran C. A Component-based Problem List
Subsystem for the HOLON Testbed. Submitted to the Fall Symposium of the American Medical Informatics Association.

[Humphreys] Humphreys BL Lindberg DA Schoolman HM Barnett GO. The Unified Medical Language System: informatics research collaboration. J Am Med Inform Assoc (1998 Jan-Feb) 5(1):1-11

[HIPAA96]Health Insurance Portability and Accountability Act of 1996.

[Bleich] Bleich HL Beckley RF Horowitz GL Jackson JD Moody ES Franklin C Goodman SR McKay MW Pope RA Walden T et al, Clinical computing in a teaching hospital. N Engl J Med (1985 Mar 21) 312(12):756-64

[Teich]Teich J, Personal Communication.
Exchanging Administrative Records via the Web

Overview

The New England Health EDI Network (NEHEN) was formed in 1998 by a collaborative of non-profit payers and providers to implement HIPAA administrative simplification for the region. Three of the provider organizations, Partners Healthcare, CareGroup, and Lifespan helped found NEHEN. Boston Medical Center joined in December 1999. UMassMemorial and Children’s Hospital joined in February 2000. Tufts Health Plan, Harvard Pilgrim Health Care, and Neighborhood Health Plan are the three payer members exchanging HIPAA-compliant eligibility transactions. NEHEN also provides connectivity to Medicaid and Medicare, which are affiliates rather than members. Together, these payers insure more than 80% of all people with healthcare coverage in Massachusetts.

Architecture

NEHEN is fundamentally different from the typical healthcare electronic transaction models seen in the marketplace. Today, the electronic solutions available generally fall into the payer proprietary model or the clearinghouse model. In the payer proprietary model, the providers conform to the specification provided by the payer, leading to a different solution for each payer that a provider deals with. In the clearinghouse model, the clearinghouse handles any translation between the provider’s preferred data formats and that of the payers the provider wishes to trade with. This model is typically funded through per transaction fees.

In the NEHEN model, the participants agreed to the following guiding principles that drove and continue to drive the architecture decisions:
• Standards-based approach
• Security and Privacy are of paramount concern
• Common program management
• Share innovation

One of the members initially developed the software used to route transactions to the appropriate trading partner and then donated that software to NEHEN, enabling the other members to quickly ramp up their transaction volumes with minimal cost. Because the members feel that their primary arena for competition is not in administrative costs, but in clinical care, all are willing to collaborate on such tasks as software development for the purpose of driving down costs.
To make concurrent development possible and to ensure HIPAA compliance, the members agreed to implement their communications according to the standards proposed by HIPAA. This approach allows all members to implement the same base solution for each of their trading partners, greatly reducing the overall cost of their EDI solution. In addition, by relying solely on publicly available and universally recognized standards, interested prospective members can easily estimate their cost to join and begin trading. When those members join, the incremental cost to the existing network to beginning trading is minimal because of the standard approach.

In order to ensure privacy and security of the highly confidential data being exchanged, the NEHEN members have implemented a private network rather than using the Internet as the transport mechanism. In addition, there is no central database that tracks or even counts the transactions, thus all patient-identifiable data is transitory in nature.
To get the greatest benefit out of electronic transactions, initiating and reviewing them must be integrated into the standard workflow at within a provider organization. This has meant integrating transaction initiation and review into the Hospital Information Systems at each of the large provider members. This integration ensures that it is easy for employees to request information and use it when it is returned.

Work to date

When NEHEN formed, the members decided to concentrate first on developing the eligibility inquiry and response transaction. Because this transaction takes place at the beginning of the patient visit and can lead to costly rework and write-off of claims if eligibility is not verified, this was a natural first step. Eligibility has now been live since June 1998 and the providers currently are making over 1 million inquiries per month. With the addition of BMC, UMassMemorial, and Children’s hospital and increased usage by existing members, NEHEN now processes 2.1 million transactions per month (December 2003)

In addition to eligibility, NEHEN also provides referral, claims, claim status and remittance transactions. As of the HIPAA deadline, October of 2003, all members in NEHEN were fully compliant with all mandated transactions.

The typical return on investment for a new provider joining is measured in months and will continue to decrease as the connectivity options that NEHEN provides its members expand.

Future of NEHEN and Administrative Simplification

Over the past five years, NEHEN has focused first on implementing the initial set of electronic transactions, and then on expanding its base by recruiting other large provider organizations to join. Now that several of the large providers have joined (BMC, UMassMemorial, Children’s), NEHEN and its program managers are thinking about the best way to expand effectively to allow smaller provider organizations the potential administrative cost reductions that have been realized by their larger cousins.

There are several potential solutions, with distinct options targeted at the community hospitals, medium-sized physician practices, and individual or very small physician practices. Any of the solutions, however, can leverage the investment that the NEHEN members have made in developing a standards-based, secure approach to administrative simplification. Today, the NEHEN payers and, through NEHEN software, the other major payers in Massachusetts, can respond to a standard eligibility inquiry in less than a minute in a fashion that can be integrated into the provider’s practice management or hospital information system. In the future, NEHEN will continue to develop the supported transactions, and it should also develop the connectivity options for smaller providers because the existing connectivity solution becomes unmanageable after the number of members expands much beyond ten to fifteen.

Once these connectivity issues are solved, the end result in terms of administrative cost reductions for the entire Massachusetts health care system has the potential to be industry changing. The following example of the “Life of a Claim” illustrates this point by describing the differences that will take place once the electronic transactions NEHEN is working to develop are a reality.

Life of a Claim before NEHEN

Patient A comes in to their primary care provider for their yearly physical and forgets to bring her new insurance card showing that because of a change in jobs, Patient A is now covered by Insurance B rather than Insurance A as they were last year. Since eligibility is difficult and time consuming to check without electronic means, the registration clerk relies on the information already in the system about Patient A to check her in.

After that day’s visit, the provider’s practice management system prints claim for Patient A and it is sent to Insurance A, because that’s what the patient had last year. After about one week of traveling through the mail, the mailroom of Insurance A, and the sorting, scanning, and data entry process at Insurance A, the claim is loaded into Insurance A’s system.

That night, the claim bounces because Patient A is no longer covered. Without an electronic means of claim status inquiry, the provider doesn’t know this fact until they happen to call or Insurance A sends out the monthly tape with updated claim status information.

After learning that Insurance A will not pay the claim, the provider bills Patient A directly. Patient A receives the bill and if they are conscientious, calls the provider immediately to inform them that Insurance B is now their insurer. If Patient A is not so conscientious, it can easily take 60 or 90 days before the provider learns that they should have sent the claim to Insurance B initially.

By this time, even if the provider submits the claim to Insurance B, there is no guarantee that Insurance B will pay the claim since it has been so long since the date of service. Even if the claim is eventually paid, it is very likely to need more intervention from the billing and accounts payable departments in the provider and payer organizations before it is complete. Finally a paper check will be cut and mailed to the provider’s lockbox, adding another 4-5 days to the amount of time it takes to be paid.

Overall, the current manual claims submission process results in the average taking 100 or more days to be paid in Massachusetts.

Life of a Claim after NEHEN

With electronic eligibility, claim status inquiry, and claims submission, the overall financial picture changes dramatically.

With the same situation as above, the following changes are immediate:
Patient A comes in for their physical without their card. While the registration clerk is validating demographics like address and birth date, their system automatically requests eligibility verification from Insurance A. Before the registration is complete, Insurance A notifies the provider that Patient A is not covered. At this point the registration clerk can ask the patient what their correct Insurance Carrier, another inquiry can be initiated, and the correct copay and insurance are recorded.

That night, the practice management system submits the claim electronically to Insurance B. Because the standard requires it, all items on the claim are coded according to the national standard.

Later that night, Insurance B’s claims engine runs and suspends the claim because one of their claims adjudication rules was violated. The next day, the provider’s staff can use their electronic claims status inquiry facility to check on the claim and if necessary, call to proactively try to get the issue resolved.

After any issues are resolved, and many current issues are directly related to problems solved by electronic access to data at the front end of the process, the payer’s system sends electronic funds transfer instructions to their bank and a payment remittance advice to the provider.

Overall, with electronic access to data on the front end and electronic claims submission available to every provider, it is a realistic possibility for claims to be paid in three to five days rather than the current 100 plus. Obviously, there is a great deal of work to be done to the existing payers’ and providers’ systems to make this vision a reality. However, with the NEHEN consortium already trading standards-based common transactions, the framework is in place and ready to be expanded.

Value of the NEHEN model to the Massachusetts healthcare system

There are several components to the value of NEHEN to the Massachusetts healthcare system. The first is that because payer connectivity exists for such a large proportion of the total covered market, providers can quickly see a return on investment when they integrate electronic connectivity into their standard processes. In addition, because so many of the large providers are members, new payers that join could see a large proportion of their Massachusetts membership start using electronic transaction.

In addition to providing significant value to new and existing members due to the high penetration of the marketplace, the NEHEN model has at its core several key principles that significantly differentiate it from the usual healthcare electronic commerce model. These core differences are a flat fee for membership without transaction-based charges and collaboration to share innovations in administrative simplification.

The flat fee is perhaps the most significant because it provides an incentive for every member to raise its own transaction volumes. Over time, the per transaction cost to the most active of the NEHEN provider members has already dropped to $.05 per transaction with just eligibility being traded today. As upcoming transactions are created and come online, this cost will drop even further, to a projected $.02 - $.03 per transaction later this year. When this is compared to the typical $.35 - $.40 per transaction charged by a clearinghouse for this service, it becomes clear that the NEHEN model allows most of the value gained by the electronic transaction exchange to remain inside the healthcare system with the payers and providers and the value doesn’t leave the system and go to the clearinghouse or other third-party. As an example, a specialty hospital in Massachusetts with 300,000 patient visits per year will minimally use five electronic transactions to support each claim (eligibility and referral inquiries, claims submission, remittance advice, and actual payment). Under the NEHEN model, the hospital would keep at least $450,000 more of the administrative cost savings than under a clearinghouse model because they would be paying $.30 less per transaction.

When NEHEN formed, the members decided that in order to achieve electronic trading at large volume they needed to act collaboratively rather than competitively. In addition to agreeing to standards and employing a common program management to help drive decisions, the members donate software developed to solve a specific member problem to the NEHEN consortium for use by other members. This sharing of the development cost has greatly lowered the bar to entry for provider organizations that are often cash poor and prefer to concentrate their resources on providing clinical care rather than administration.