Transcript of the January 28, 2003 NCVHS Workgroup on National Health Information Infrastructure Hearings

[This Transcript is Unedited]

National Committee on Vital and Health Statistics

National Health Information Infrastructure Workgroup

Hearing on Health and the National Information Infrastructure and the NHII Personal Health Dimension

January 28, 2003

Hubert H. Humphrey Building
Room 705A
200 Independence Avenue, S.W.
Washington, D.C. 20201

Proceedings By:
CASET Associates
10201 Lee Highway, #160
Fairfax, Virginia 22030
(703) 352-0091

Panel 5: Linking Individuals to The Personal Health Information
- David Brailer, CEO, CareScience, Santa Barbara Project
- Pat Wise, HIMSS
- Johnny Walker, CEO, Patient Safety Institute
- Barbara Selter, MAXIMUS Intelligent Technologies Division
- Questions and Discussion
Panel 6: Authentication Issues
- Peter Waegemann, Medicla Records Institute
- Brad P. Keller, Sun Trust Bank
- Glen Marshall, Seimens
- Marty Abrams, Center for Information Policy Leadership
- Questions and Discussion

P R O C E E D I N G S

DR. LUMPKIN: My name is John Lumpkin. I am the chairperson of the Workgroup on the National Health Information Infrastructure. We are going to be starting our second day of hearings.

Yesterday we had a very interesting series of discussions. We started off talking about the next generation of the Internet and some of the implications for the Health Information Infrastructure.

Some of the issues we face in how we may interface with that and the important role of how specifically it is helping fairly information intensive and discuss some of the roles. I think that, as a work group, we are going to have some recommendations that we are probably going to put forward when we have our discussion at our full meeting in February.

We had David Lansky on the phone yesterday, I think concurrently and today he is here. We are very pleased that he could participate.

I think we need to discusssome items. We are live over the Internet with an audio stream. Some of you had an opportunity to listen and know it's helpful if you do give your name before you speak.

(Introductions were made.)

Thank you. We will begin with the first panel. We do have someone who, hopefully, Barbara Selter is coming, but why don't we get started with David Brailer and then we'll proceed on with the panel. Thank you.

Panel 5: Linking Individuals to Their Personal Health Information

MR. BRAILER: Okay, thank you. I'm going to talk about our experience in Santa Barbara and try to raise some issues object its relevance to your discussions. Thank you for having me.

I will say that people always ask why Santa Barbara, and when I stepped out of my hotel this morning into the cold weather, I answered the question yet again, why Santa Barbara.

Let's see, are there slides?

Okay, we'll go off the handouts. I'm going to start with a couple of very brief case studies. Those of you that are clinicians know that one case study is an anecdote and two case studies are science, but I do want to just give you a sense of the flavor of this.

The first was-- and I'll be very brief, is a patient in Santa Barbara who had mammography and two events happened. Missed the definitive exam for biopsy and both because of that and other reasons, this fell through the crack.

The abnormal mammogram was found by an obstetrician on a routine visit and then proceeded to do a definitive diagnosis and specific therapy and the patient survived.

This raises the question about why the physician didn't have the information as well as why the consumer didn't have access to this information.

The second case study is about a person who is followed by a regular physician who goes to a specialist for treatment of congestive heart failure and you see that the chart shows a very limited amount of information that was revealed by the patient, but the real story that was available through other doctor's offices and ancillary service providers is quite a bit more complex in terms of both the efficiency and the knowledge base for treating this patient.

Both of these case studies are intended to really illuminate this question that's already been published in the literature about why it is that consumer access to information is important and beneficial from a quality perspective and it's no surprise turning to the Harris interactive slide that consumers revealed a very strong appetite for having access to their test results or getting preparation information for scheduling appointments and for asking questions and interacting with clinical professionals.

And I think it's really in the spirit of this that in Santa Barbara we saw the opportunity in year two of the project for substantial additions around the consumer arena. Clearly the issue there on slide five is that consumer health information is widely dispersed. This is true in almost every market in the United States, that a relatively small share of patients are treated exclusively by one set of clinicians who have the entirety of that patient's longitudinal experience under one enterprise and therefore in one set of integrated data bases.

On average we found that consumers were treated by 2.7 providers across the course of a year in Santa Barbara, which is slightly lower than some other statistics that I've seen.

Therefore the Santa Barbara County Care Data Exchange was formed.

It's now in its fourth year and was brought together by organizations in Santa Barbara and it is county-wide and I think that's important because those of you who know the environment there know that there are two very different components of the county, the south county that is influenced by Los Angeles and the north county that is one of the largest migrant farm worker populations in the United States on a per capita basis.

Santa Barbara County Care Data Exchange was set up to be a public utility. It was set up to be something that was available to all and its main focus was bringing information to decision makers so they could have it available when treatment decisions were made.

I'm on the slide titled information fragmentation. When we started this project, we took a look at the baseline of care delivery to see if this fragmentation happened on impact and indeed we found that physicians who shared the same patient -- which happens in 40 percent of the cases in Santa Barbara -- ordered similar drugs, tests or other therapies and about 11 percent of the time, there were duplicate things ordered on the same patients and surprisingly, half the time the patients followed through with that treatment, not knowing that they were duplicate or they were even potentially conflicting.

Physicians didn't know what other physicians were doing with their patients. When you know out of four drugs that a patient was taking was not known by a physician when they were making other treatment decisions because the physician had no way of knowing and the patient may not have known or been able to describe what the drug was.

There's a great deal of, in you would, hassle avoidance. It was easier for physicians to order repeat tests than to find the information from the original. I see physicians nodding their heads.

And the sense of physicians was that if they didn't have something after about a minute of trying to get it, it was easier just to order it and information was missed.

Physicians reported that one out of nine pieces of information they felt were necessary for their treatment decisions they could not find.

Now, this is the picture of health care in America. Frankly, I believe that this is probably better because this is a slightly smaller and less complicated environment than some of the very, very fragmented urban environments in the United States.

So when the organizations came together in Santa Barbara, the key factor was to be able to take all comers and so what you see on the list of sponsoring organizations are the medical health plan that covers care across the county, the public health department, both as a public health entity and as an operator of county-sponsored community clinics.

The largest physician group in Santa Barbara -- 180 physicians; the largest hospital systems as well as their competitor, the Catholic Health Care, Marin Medical Center, a variety of IPA's, including the largest mid-coast IPA; a pre-formed community health organization in north county called Lumpoc which is on the border of Vandenberg Air Force Base; the medical society radiology centers as well as lab providers and a couple of employers, particularly the largest, the University of California, Santa Barbara.

There have been other additions to this list since that time but this was the minimally necessary group to form broad community ownership of this enterprise.

The organizational model, I apologize, is a little difficult to read, but the key of this is a hub and spoke relationship among these entities. They are linked to each other under a variety of agreements to determine access rules, obligations or data availability, disciplinary procedures, economic funds flow, all of the different real infrastructure that's needed to have safe, confidential and ethical sharing of the data.

This group is governed by a council which has one vote per organization so the wealthy organizations don't crowd out the others. There is a lead council, a clinical council, a technical council, a clinical council, a technical council, a consumer council and a financial council dealing with the various aspects of specific utilization of this project, each with their own autonomy and accountability to the stakeholders who have issues in those areas.

When we looked at the issue of data sharing, we realized that this is a many to many phenomenon. It is not simply making general connectivity available and so we sequenced these on the basis of first institution outbound, institution to clinician, institution to consumer, institution to public health.

Here, institution is an enterprise or a corporation other than a solo or dual physician practice. For example, a large physician group is an institution because they are a data generator. They have data available that others want, those are completed, have been up and running for quite a while.

We are now doing the clinician to clinician, clinician to institution, clinician to consumer and clinician to public health aspects. This is actually obtaining data from doctors' offices that's generated in realtime or retrospectively that's needed for other things and these will be phased in over the course of the next year.

I won't talk about the technology in detail but I just will say that one of the fees that we had put into our design constraints was that there was no central architecture that stored patient data for two reasons.

One is economics. The cost of doing this is enormous. And one of the issues economically with data sharing is that the one thing you can be certain of is that the costs are up front and large and that the benefits are small and trickle over time.

Cumulatively, the benefits are larger than the costs but the secret to making this economically beneficial as well as beneficial from a patient advocacy and quality perspective is to make the up-front hurdle as low as possible and the way to do that is to build distributed peer to peer or some other form of architecture.

Secondly is security and the confidentiality. No matter what is said in an agreement, what is stated in other authoritative means, there's no way to insure the reliability and safety of data that's stored in a physical location by a third party.

And therefore, our view is that the only people who should control access to their data are the people who are already obligated to do that which are the providers and ancillary care entities themselves and so have a brokered kind of sharing, peer to peer relationships, allows the data to be assembled in realtime if there is informed consent and if both the data holder and the data compiler believe that the data should move to that requester.

I won't go through the data sources, but suffice it to say that the variety of data holding organizations over the next three slides have put online the overwhelming majority of data that is electronically available.

All organizations that have generated laboratory results have put them online. All organizations that generate radiology reports, radiology voice dictations have put them online. Organizations that have developed, that have radiology images available, have put them online. Organizations that have clinical dictations, transcriptions of all reports, surgery reports, admission reports, discharge reports, office visit reports, have put them online.

Pharmacy data is available from the pharmacy dispensing within the providers as well as from local pharmacies and from a pharmacy hub that operates, supporting the county. Emergency room notes are available as well.

So we have tried to bring together what is electronically available about these patients. This has also been supplemented by the information from the Medical health plan about eligibility and referral data that's necessary to frankly supplement the care delivery environment in the safety net aspect of this project so there's a variety of data available.

We now have a backlog of over 30 data sources that have requested to be connected to the care data exchange that are being processed and this is now available on a first come-first served basis and the backlog of organizations demanding they put data online represents the completeness of the penetration of this into the county.

Examples of that include a pathology group that wants to put pictures, if you would, of their histologies as well as their interpretations online because their biggest hassle, their biggest cost and their biggest communication barrier is dealing with all the repetitive requests they get from doctors to look at a picture of something or to be able to understand what was that pathology from two years ago so this is an example of many different types of information.

Other social service information is coming online as part of a frequent utilizer program that I'll talk about briefly.

Turning to the applications, the primary application we intended to bid was a physician appliance that allowed physicians to get access to the comprehensive set of patient data so when a patient walks into a doctor's office, the doctor is able to understand what is known electronically about that patient if that patient has given consent, if the data holders allow that data to be available, if that physician is authorized and authenticated, then the physician can know.

Also, some public health applications, looking at disaster recovery, looking at some population reporting, etc.

The next slide talks about the consumer applications and just to hit a couple of the key points, well, we discovered when we started this project is that there's a great number of consumers, actually approximating about the same percentage you saw on the Harris interactive survey that wanted to have access to their personal health information, test results, other content; who wanted to see who saw their data to track the access laws and who wanted to make amendments, who wanted to be able to make comments on their record, who wanted to be able to add details about allergies or other types of information and who wanted to be able to do communication with physician offices.

We have since added the ability for consumers on a pilot basis to do online management of their informed consent, to be able to send conditions about who can see what data at what point.

This requires a great deal of logical thinking, if you would, the ability to be a little bit savvy about the use of applications, but we think this has enormous potential for the future, particularly given the two-tailed nature of informed consent that we use in Santa Barbara that I would be happy to elaborate on.

The next slides are showing examples of screening and I will not go through those. You are more than welcome to look at the details of those online, but I think suffice it to say that simplicity is the rule here. One of the things that we learned is that the average data record in Santa Barbara is accessed electronically about 11 times within the first month that it's generated.

So patients who do access their user logs see an enormous volume of activity when they just go to see the doctor so this issue of simplicity, of allowing them to be able to figure out what all saw what and what the chain of events is so it doesn't just give them A, a data dump or B, alarm them with the level of just movement of information, has taken a trial and error basis but we are in the fourth iteration of this and we think we at least have a functioning application that can do the basics and something we can build on.

Where are we with the consumer implementation? This is a four phase release. We started with a consumer council, a group of people that advised us about what consumers wanted, what they did not want, what rules they would follow, which ones they would not, what expectations they had, what technical savvy to be prepared for, what issues of understanding the content of the information.

That group of 12 people became the first pilot users. Then the University of California Human Resource Department formed a beta test group that tested the application. This group is now in the process of supporting a university-wide release so that it is part of a broader use environment there and there's now also an expansion going on, not just through that employer but through hospitals or physician offices where consumers can dial up for access to the information.

One caveat I would give is that California state law requires that information not be posted on the internet or a patient's access unless a physician reviews it in advance. Therefore, physicians are in a control point of determining whether or not patient information is available so the consumer information access to this point is contingent upon the physician's approval or their ability to support patient access.

The enrollment process I won't go through the details of, but the key aspects here are to perform a real life identity verification which is why we require a physical presence either in human resources or in physician's offices or a hospital, to link that to an identity object, if you'll pardon the expression, a technical representation online of who that person is and validate that; to issue credentials and then to go to the physician and support their set-up to define their interaction environment, will they allow on-line interaction, will they allow scheduling, etc.

This is a relatively scalable process although the time consuming piece is the actual human verification process and there's some discussion going on not only in the organization but elsewhere about how this can be done on-line, not unlike setting up other on-line secure data base access.

If I could be so presumptuous, I'm going to end with three slides that summarized what I think some of the lessons here are.

I did not write these slides for this discussion. I'm actually presenting these in this building tomorrow but I thought if you would be so forbearing, I'll give you at least what I think the key snapshots are.

Our experience is that it's getting information to physicians that's the key. Physician's offices have relatively little information that we do want to get and the cost of getting that is quite high so we think the real benefit is getting information to doctors. It's inexpensive, has a lot of benefits and it sets the foundation of getting information from doctor's offices. That could be somewhat contrary but we think that's a great starting point.

The key role of technology is in the ability to be loosely coupling. I have participated, as many of you, in the debates about interoperability and the adoption of standards. I believe that's very important.

I also believe if we wait for that, we'll be waiting for a while and therefore we have to take a broad array of formats so we not only take JPEGs that are generated by optical disk storage of scanned lab reports from the lab but we take highly structured data that comes from a linked generation that comes out of their more sophisticated systems. The key is assembling those in a way that the users find meaningful.

The next slide is that some people I know believe that interoperability, sharing of data across enterprises, is a great logical step after health care enterprises in America finish their internal IT development and my belief is that, in fact, these are parallel.

In fact, I would go further to say that across enterprise interoperability is an important leverage to overcoming physician resistance to the adoption of these tools because it gives physicians information that they never had before; therefore, we think that cross-enterprise can either move faster than internal or can be parallel to it.

We think there's a two-tiered ROI. There's hard dollars that come back to the data holders in terms of reducing the manual due to handling costs, the number of FTE's that move data around and there's a clinical benefit which is larger and longer term that comes from the clinical efficiency and our experience has been that it takes both of these to be able to bring all the patient stakeholders together.

We think that there is a market failure. The clinical data sharing addresses. We had McKenzie and Company do a detailed economic assessment of this and found what might have been instinctively true-- that there is a first mover disadvantage. There is no reason to put your data online if other people have not. On the other hand, there is a positive network externality, meaning that there is a return to all stakeholders as more participants come forward.

Therefore the benefits are U-shaped, which means that a policy intervention is needed in order to overcome the first mover disadvantage, but one would believe that the sustainable benefits coming from the network externalties could be quite large.

Finally, one of the things that we have come across is a great deal of paranoia among providers about what they can and cannot do around community collaboration with respect to ambiguities and anti-trust as well as potential start conflicts. I believe those are both very important foundations of law for health care operation but I think a lack of ambiguity is harmful.

It turns out from our legal opinions that there's clear safe territory here, but I think it would behoove data availability as well as consumer access for these to be clarified.

Thank you for your time. I would be happy to answer questions when we are done.

DR. LUMPKIN: Okay, thank you. Pat?

MS. WISE: Good morning. My name is Pat Wise. I am the staff liaison for the electronic health record and the NHII initiative for HIMSS.

Founded in 1961, HIMSS is the health care information industry's largest society and trade association, representing more than 13,000 individuals and 100-plus corporations.

With five offices nationwide, 43 chapters, and 20 special interest groups, HIMSS exists to improve human health through the effective use of information technology and management systems.

During the summer of 2002, the HIMSS board of directors unanimously voted to adopt the National Health Information Infrastructure as the society's top strategic policy issue. At that time, it chartered the formation of the NHII task force which is chaired by Dr.C. Martin Harris of the Cleveland Clinic Foundation.

The HIMSS-NHII task force includes representatives from provider organizations, consulting firms, your parent committee, the National Committee on Vital and Health Statistics, the Centers for Medicare and Medicaid, the Centers for Disease Control, the Department of Defense and the Veterans' Administration.

The purpose of the NHII task force is to drive the country toward the creation and universal adoption of a national health information infrastructure.

Recognizing that the NHII will not be achieved through the efforts of any one entity, our initiative works collaboratively with other organizations to harness the depth and breadth of our collective memberships.

We are committed to providing extensive education opportunities for the members and the industries at large as well as conducting pervasive outreach to both legislative and executive branches of our government.

One of our early initial projects for the HIMSS-NHII task force was a comprehensive audio education program presented by Jeff Blair providing an overview and tutorial of the creation of the NHII concept, the vision of NCVHS and recommendations for realizing that vision.

Additional early efforts including creating an inventory of existing technologies and practices, citing a position statement and citing a gap analysis on the development needs and encouraging multiple sources of increased funding that could help the industry create on NHII and actively supporting state initiatives that may serve as test beds for this national initiative.

As the nation builds a health care information infrastructure for the 21st century, HIMSS applauds the efforts of this Workgroup in addressing the issues related to link individuals to the personal health information.

In preparing for today's testimony, HIMSS sent inquiries to its individual and corporate members to more fully assess the implementation of the enterprise MPI. The responses were surprising.

Currently, the majority of health care in the United States is documented on paper and exists at the source of the care provided. These locations range from 24-hour storefront to acute care settings, urban and rural private practice settings, community hospitals, specialty clinics and academic medical centers.

Even within the same enterprise, it is not unusual to find convenience files or duplicate files located in clinic settings and practitioner's desk drawers. This results in a fragmented picture of the individual's health needs and health histories.

The potential for electronic health records to improve efficiency, safety and the quality of care is recognized throughout the industry. Access to appropriate information at the time of care delivery is essential. Clinicians and consumers need the right information at the right time.

Electronic health records and the transmission of personal health information can provide the link necessary to connect the weekend visit to the clinic with the visit to the family practitioner for a chronic ailment with the clinicians in the medical center treating a complication.

Integrated electronic health record systems allow providers immediate access to essential clinical information and provide consumers with the capacity to provide essential information about their health care to the providers of their choice at any moment.

The benefits to integrated electronic health records are substantial for both consumers and providers and include a reduced number of adverse events caused by lack of information about health consumers at the point of care; reduced duplication of diagnostic tests due to the inability to locate the results or a practitioner being unaware that a colleague has just recently ordered the same test.

Efficiencies gained in the system when practitioners do not have to hunt for clinical information enhanced decision making through on-line clinical support software and an individual's being confident that subject to appropriate privacy controls, regardless of where or when they seek the health information, the professional treating them has access to relevant clinical histories and treatment information. The enterprise master patient index is more relevant than ever to the health information system.

Health care organizations may have several systems handling various different data processing needs from laboratory to billing or from ADT to image manager. In today's world each system will likely have its own patient data base and its own identification schemes.

When data must be transferred or collated between the domains, the ID numbers on the two systems may be different. Additionally, the same ID may exist in both domains, but identified different people, preventing access or matching up of the data or, more importantly, raising the possibility of mismatched data.

Errors in patient identification or variation of medical record numbers can undermine the system leading to fragmented information or worse, commingling of patients' information.

An EMPI provides access to patient care data, medical records and billing information while improving internal efficiencies, clinical and financial outcomes.

Upon querying its membership, HIMSS determined that the large health care organizations have done the most work with the MPI models. These models facilitate the organization of clinical data for clinicians. Most have no provision for consumer access.

No advanced models were identified through our requests.

In community hospitals and private practice setting, EMPI appears to be in early development or non-existent. Most linking across providers today is between laboratories and physician offices and hospitals.

Social Security number is the common identifier used. Even within this fledgling linking, problems exist in correlating test codes. The majority of physician practices are not automated, and, of those that are, only the large ones have the sophistication to exchange information electronically and those are only pulling information, not pushing out information from their own electronic health record.

Accessibility of information for the consumer was, once again, not a factor in their design.

Community hospitals are, for the most part, still taking laboratory results and other information to physician offices as well as providing dial-in to an enterprise EMR on a line review of patient information by the physician. Information is not pushed to physician offices electronically at this time.

The health care information is not reviewed by a patient consumer except upon direct request and at that time generally the information has been converted to a paper record.

In the state of Delaware, the Health Commission has approved the development of a utility that can provide an index, indicating which providers in a community have information on a patient. This utility is a long range vision that will implement a standard way for patient care stakeholders to electronically exchange information in a secure and timely fashion. The utility would establish standards for patient identification, secure electronic internet data transfer, data content and legal agreements for the utility's use.

It would implement these standards so that patient authorized providers can use the utility to electronically request information from other data contributors. Utility does not store patient information. Rather it stores who has that information.

The encounter registry stores provider-encrypted patient identification numbers which will be cross-referenced for future use in requesting information.

Patients will have to authorize data contributors sharing of this information.

Studies indicate that implementing electronic sharing of information can reduce the administrative costs of health care by 50 to 80 percent. The Wisconsin Health Information Network experienced between $17,000 and $68,000 savings per physician practice by electronically requesting and in taking information requests from the hospital departments.

HIMSS membership has consistently advocated for the development of a national framework that promotes the use of electronic health records and the patient authorized sharing of relevant clinical components.

This health information is extremely personal and consumers need to be confident that the their information is valued, their privacy wellbeing respected and the information welcome to improve their health or that of the public at large.

Currently in its fourth year of implementation, integrating the health care enterprise or IHE, is a HIMSS-led initiative that brings together clinicians, information technology professions, professionals, industry representatives to implement standards for communicating important information efficiently throughout the enterprise. IHE achieved its objectives by fostering integration through coordinated implementation of established standards.

IHE is not an effort to develop new standards. Rather, IHE depends upon the existence of stable clinical data standards such as HL-7 or Dicom, widely accepted by users in industry. These standards provide tools and technology. IHE specifies how to apply such standards to real world scenarios and integration problems.

This initiative is currently expanding its technical framework to include the functionality needed to support the IT infrastructure including the MPI, query display and synchronized patient view. A description of the proposed work of the IHE IT infrastructuring committee, relative to the EMPI is found in attachment one of my testimony.

The HIMSS community is very pleased and supportive of today's meeting. In preparing this testimony we learned that our assumptions about the uses of EMPI across the nation were quite overstated. There is a great need for groups such as that gathered here today to work to achieve symmetry within an EMPI as well as create a reality in which EMPI is the norm, not the exception.

HIMSS looks forward to the realization and the promise of electronic health records. We take seriously our intent to drive, frame and lead initiatives of national import.

To this end, we have developed the following work plan to launch these efforts. A detailed prospectus will be developed based upon feedback from the EHR steering committee, the IHE experts and other case stakeholders. Our key elements include the following:Rolling out a robust EHR initiative program of value to the corporate community; promoting health care standards, development that supports the development of the EHR, participate in the Institute of Medicine panel on the patient safety of the data standard initiative.

We are identifying standards-based solutions to integrate systems necessary to populate information in the EHR and we are soliciting comment in a publically available format.

We are defining the necessary attributes of electronic health record. A position statement will be published on the attributes of a fully functional EHR, prioritizing elements of the EHR and key domains is key to this.

Galvanizing the industry involvement, support and participation is also one of our goals.

We are creating an EHR demonstration projects utilizing consensus process and refined development and document the EHR technical framework. We are attempting together organized industry implementation to test processes to prepare for public demonstrations.

We are scheduling demonstrations at key industry meetings to showcase our implementation of an EHR technical framework. In addition, we are documenting the business case for an EHR and advocating public policies that provide financial incentives and grants for EHR implementations.

We are establishing HIMSS as a clearinghouse of information, research and other EHR materials and developing, maintaining and growing a comprehensive EHR implementation tool kit.

We are utilizing the Davis award process to identify, showcase and indicate regarding real world EHR implementations. We are updating the current enterprise threshold criteria and we are launching this year a small practice Davis.

A tangible, real world integration model will provide a rich source of lessons learned, best practices and educational opportunities. The impact of patient safety and quality improvement outcomes become identified, quantified and publicized.

Utilizing the collaboration of clinicians, vendors and industry stakeholders, with a unified vision and documented strategy, the long term goal of actualization of the ubiquitous electronic health record conclude realized.

On behalf of the HIMSS-NHII task force and the society as a whole, I thank you for the opportunity provided to us this morning.

DR. LUMPKIN: Thank you. I think we need to switch the projector cable. Go ahead with Johnny Walker from the Patient Safety Institute.

MR. WALKER: Good morning. The Patient Safety Institute thanks you for the opportunity to share with you this morning.

What I would like to cover in this short period we have together is taking PSI's experiences and lessons learned and focus on the problems one must address to successfully link all the electronic sources, those in particular for a comprehensive patient-centric, personal health records nationally would require.

This would include in particular not only the sources nationally but also linked communities that we already have, for instance, Santa Barbara, that was talked about earlier, the quest for a solution that is acceptable to the patient individually and still usable to the physician in public health.

For a few minutes, I would like to move our frame of reference from an enterprise model which has certainly been demonstrated by a number of vendors, past the community model which is certainly challenging enough that only a few communities which have actually successfully implemented it to the focus of PSI, a national utility model and how that might operate.

Contrary to what one might expect, the really intractable problems in a state and a national model are more in the governance and policy areas than in the technology area.

First, a little background on PSI so the lessons learned have a frame of reference for you and as I proceed through this, I would be amiss in not sharing that we don't claim to have all the answers by any means at all.

PSI is a national collaborative of physicians, hospitals and consumers, it's non-profit and its basis, it is focused on starting with a core base of information that the doctors universally agree what they want to see when they treat a patient, the diagnosis, the meds, the labs, allergies and the immunizations.

As you begin to roll this out with patients, you quickly find, though, that they are never satisfied with that and they continue to have their own additional things that they want to have so if you build an infrastructure, a railroad, a utility that allows the basic core data, then adding on the others as you go forward and customizing it for each community, each facility, literally each state, then that's a goal that is not unreachable.

The banks begin sharing confidential information for patients realtime now at eight-tenths of a cent per transaction, confidently 35 years ago that was done by basically a crisis situation, bringing the industry to a point of making decisions and ultimately the decisions themselves, coming out of the industry for a collaborative, a governance model, that they would all trust.

They didn't have consumers or patients in there and, in fact, the founder, Joe Hawk(?), still regrets that's one of the things he wishes they had been able to do but the banks were quite comfortable with the collaborative that they put together and it has served them financially quite well.

As we begin to put this formal collaborative together, we were first told it was impossible. The patients and hospitals and physician leaders would absolutely never work together and it was quite an experience as we did put the board together and it was also quite intriguing how common the interest of each area was.

When we talked to the different patient advocates, inviting them to be on the board, the first three we went to and the first three that joined which -- we had to hire a PR firm to find out who a patient advocate was because we didn't have, in health care really had never focused on who really represents patients.

It's pretty easy for docs. Oh, that's the accrediting state societies, that's the AMA, that's the MGMA but who represents patients.

So we hired a PR firm and they gave us three names and we went to those three names and in each discussion as we were talking to them, three questions very quickly came out as the patient advocates were sitting with their arms folded which is I don't really trust you folks.

And those three questions, the first one was do you support HIPPA and the second one was can the patients see the data. The third question was okay, if you support HIPPA, if we could see the data, can we change the data. Of course, that raised the ire of the physicians and the hospitals but when they were provided, that they could append the record and actually add additional information, they were more than satisfied with that and finally realized that maybe a collaboration and cooperation was a faster way to get their initiatives moved forward than confrontation and legal or public outcry.

The principles that PSI is built on is one, it's for all stakeholders, open to all, dominated by none.

The second is, and I'm going to paraphrase these because obviously you can read them, individual data keeping private. Three, opt-in is core. Opt-in for the consumer, opt-in for the physician, opt-in for the hospital. It's a choice, not a mandate.

Three-- it's also as privilege three, PSI's most valuable asset is its trusted third party status and it can't be bought.

And, finally, PSI's mission is helping an advancing health care, not making money.

The goals are very similar to everybody in this room, anybody that participates in health care in this century, are all trying to improve quality, reduce errors, lower the cost and strengthen the privacy.

The governance model was one of equality, one of patients, one of physicians, one of hospitals and now the other stakeholders are being added in addition. When we started with the physicians, we sat back and said who would represent physicians. At that time it seemed to be that you needed, if you were going to have three, which we decided on, of each area, and let them actually opine and make decisions for their own area, then you would need the national association, the state association, and finally the one who actually provides the management guidance forum and so we went after the COE of the California Medical Association, the largest state, the CEO of the MGMA and the then-current president of the AMA. Three meetings -- we didn't finish any of the meetings before they had all said yes.

Their concern was that if industry itself did not take the initiative, then the public outcry would force the government to create something that would not have input from the industry and that would be catastrophic for everybody.

They felt like doing it on a national model was their last chance. The hospitals also were represented as we chose them and then we ended up with the help, as I mentioned, from the public relations firm, we chose the National Consumer League's president, the National Alliance of Hispanic Health who represents the largest minority and then somebody who was incredibly knowledgeable and well-spoken and respected in privacy and security, which was Twila Braise(?), of the Citizen's Council of Health Care.

Along the way we were told what we were trying to do had already been done which was music to our ears but in another industry and that was what we were doing in essence was bringing to health care what Visa had brought to the banking industry 35 years ago.

So that led us to Joe Lauktor(?) and his interest in being a very, very active advisor to the PSI board in helping us innumerable times, not go down dead end roads that they had already gone down and could show us a better way.

PSA is easily explained as is a Visa analogy or just a big switch in the sky. It doesn't house the data in a central data base, the privacy people really like the fact that you don't have a central data base, even when they are the ones that are participating and governing it.

Secondly, the data is available realtime so that when a patient needs it, it is authorized, allowed, authenticated by the patient and that physician can go to the PSI hub, grab the data from any source and return it realtime to that physician in whatever format he happens to wish to display it, whether that's a browser base, whether it's a PDA or whatever.

That's incredibly important in getting physician buy-in to not tell them they have to change the whatever they just bought and sink all the money in learning how to use it.

Our MPI approach and industry standard technology, it's really nothing I would consider earth shakingly novel. There's really commercial grade quality technology out there that is off the shelf.

The pointers is a little different story which I'll talk about in a minute. But this has been demonstrated on a community model successfully several times recently.

PSI is actually designed on a national and a state basis. On a national basis, R. X. Hub, for instance, whose recently became one of our partners, the lab companies, the insurers, the outpatient portals seeking to work with us and even immunization registries, want to go to one single course that they can tie into, do one interface and then, even in discussions with the VA, have one way to get to the private sector and not have to tie to every hospital, even every community, every idea and could there be not one place that they could tie in that, then could interface to everybody else with whatever the standards that are being created or used.

So we ended up creating a national hub that would take the data and make that available to the states and then certainly the states, through the national hub, if you will, spoke and hub, one state and the two models up there are identical to just show though that one state actually can move data from one to the other.

You have actually a public and a private piece to the national piece where you have public users and then you have the private input users and sources but you have the same thing in the states and as the states begin to wrestle with the highest priority they got which is how do I handle the fiscal crisis in particular, how do I handle health care and do I quit using Medicaid to save money.

The savings that are accredited to reducing errors, improving the quality from sharing data are significant enough that they can in essence begin to tie in at every single place that they have a patient which, when you start to list the number of the programs they have, is very, very significant and this doesn't even talk about the new one which, of course, is bioterrorism and homeland security which is another whole ball game, all of which should be riding in the same basic railroad or the same network, the same communication, literally for a state, the same MPI used for all of these programs instead of as they now have, a manual, one for all of them.

I would like to share with you one of the most intractable challenges that we found just to help you see some of the things that you begin to get into when you move to a national model and think in national connectivity.

The one that probably gave us more trouble than any of them was for patients who might opt in. When you are a national model, that's almost everybody when you are starting but knows that have not yet opted in, obviously, when you have a consent you have a whole different ball game but prior to consent, if you have PSI's foundation that's built on privacy, opt-in, principles, than those easy answers suddenly become more difficult so let me walk you through it here and keep in mind-- HIPAA isn't the end-all, be-all, end-all for what I think is going to be the solution if, in fact you are not committed to going to where the patients and the public want you to go above which you are really required to, you are going to be facing an uphill battle, that is going to make it much more difficult.

It's much easier--

DR. BLAIR: Could you just clarify-- when you refer to HIPAA, are you referring to the privacy regs or the financial administrative transactions or both?

DR. WALKER: Mainly I was referring to the privacy regs.

What we found is if we have discussions at the board level with our privacy advocacy, they are always wanting more than what is actually required in the HIPAA privacy regs.

So let's walk through a couple of things here.

If you are talking about a patient who might opt in but who is not and you are going to use a model that says we only use people who opt in as a choice, then to link the patient's data requires either a national patient identifier, which, one, doesn't exist and two, has all kind of consumer opposition or two, you have to use demographic data.

If you take the clinical data and you distribute it as a first source, and don't keep it centrally, you still have to deal with the demographic information.

So a link requires that the demographic information be kept either centrally or remotely. If you keep it centrally, one must deal with immediately, two issues. Do you pre-link and therefore, no, prior to permission, which facilities had data like, for instance, a medical health facility.

Should that get out and therefore be offensive to somebody who hadn't even given you permission to see their data or participate with your system or if you don't pre-link, did you at least possess the ability to access their considerable demographics prior to them giving your permission or consent.

If you wait for the patient to opt in, which would seem to be the natural resource, the problem you get into is that collecting the demographics is just way, way too slow with the mass of data to get to a critical point and that puts you back to, again, not using just current but historical data, but if you use historical data, then you are going to require matching technology at each facility.

So let's go to there. If you go to matching the demographics locally, you run into some other issues.

One is the demographic algorithm software now has to be moved from one central location to each resident location of that data, including physically in this cases, if they have electronic data to give.

This is cumbersome, financially, technically, security, response time and scalability, all very troubling. In addition, using that approach limits the ability initially if the registration happens to be at the emergency room or in an emergency ambulance or some other like encounter because of the time played to actually set them up and move around and find the data.

And finally, if you do require consent, you have to deal with the fact-- what is it that you are giving the patient to incent them to play ball. They don't want to just play ball and give up their perceived privacy just because you wanted them to. They have to feel like they are getting something back in return so you have to think of the value of the proposition from the patient and make sure there's something in it for them that they want to consent.

I'm not sure where we are on time, but I will pass the torch at this time and be glad to address any questions at all in the question and answer time.

DR. LUMPKIN: All right, we'll have questions at the end of the panel. Barbara?

MS. SELTER: Good morning. I'm Barbara Selter and I'm representing the Western Governors' Association, and I'm very pleased to be able to be here this morning to tell you about a project that is dealing with the issue of obtaining and collecting personal information from multiple providers and provides just that value proposition that my colleague Mr.Walker was talking about for individuals.

The mechanisms that are actually out there in the real world, very substantially for obtaining and sharing data, for the most part people are still unfortunately mailing and delivering paper forms or faxing forms. There are some medical records and private networks but they are few and far between. There are a few smart card projects.

The first phase of the health passport project I will be telling you about is one of the pioneers in that area doing card centric data sharing. There are also a number of models for internet-based and probably the most effective when you bring the two technologies together.

The health passport project really started with the whole idea of finding a new client identifier and using technology to be able to integrate different delivery programs. It started historically as a payment system.

Some of you are familiar with electronic benefits transfer for cash benefits and food stamps but in the health care arena, there was a much greater need to share information across multiple programs with multiple providers providing information for an individual.

The basis of this project is the fact that clients testify benefits that target population of benefit recipients from multiple providers use a single access tool, in this case a multi-application smart card to allow benefits, cash benefits and assistance with the delivery of medical benefits to an overlapping population that participates in a number of these benefit programs.

The vision of the project is based on a multi-application card, a card is provided both to the provider and to the patient and the actual content of the card varies. For the providers, a very significant issue is physician ID and credentials particularly as we move into the internet world but as you can see from this slide, there are a number of applications that can reside on the card.

At the same time that the card was becoming increasingly popular in a number of states, for benefit delivery, states were also moving to the whole idea of portals where there was a single access point-- the no- wrong-door approach where clients could come and receive a range of government services through a single point of entry over the internet.

The first phase of the health passport project was totally card-centric. It was an 18-month pilot in three states. The states were Wyoming, Nevada, North Dakota. It covered 30,000 mothers and children, and it was the first attempt to cooperate across multiple levels of government-- the federal, state and local government as well as the private sector.

A number of federal agencies, such as the Public Health Service, the Maternal and Child Health, Head Start programs, the National Library of Medicine, Medicaid, CBC for immunizations, and the General Services Administration for technical support as well as a number of private foundations and private physician practices.

The initial project included WIC benefits, the Women, Infant and Children supplemental nutrition benefits, a number of local maternal and child health optimal pregnancy and well-child programs, the EPSDT Medicaid program, Head Start and a number of food benefits for food stamps and the WIC program.

A key issue of the first phase was the whole idea of the card as an integrating device among a number of disparate systems. Each legacy system remained the same and had the ability to read data from the card or to update data to the card so that a provider could go into their legacy system, whether it was the WIC management information system, the Head Start Family Information System or private provider system, whatever. Go in and see, on a screen, the data reading on the card, the data in the system and decide to either update the card from the system or update the system from the card, depending on which was more current.

A very key part of the first phase of the Health Passport Project was the access to kiosks and this was some of the value proposition that I was alluding to when I began.

The patients could securely view health data and benefit data by going to a kiosk. Kiosks were located in the supermarkets, community health centers, public libraries and other programs. They could download their electronic benefits and obtain their balances. They could obtain printouts of office appointments, medical appointments for themselves and their children and probably the most often used feature was the ability to print out an official state registry of immunizations that they could take to the school, to pre-schools and to community groups.

This second phase is moving into the whole idea of combining technologies. One of the things that was found in the evaluation of the first phase of the pilot is that the card was good for certain static data but was not as good for a constantly changing data.

Therefore, the idea was to move into the card as a vehicle for identity authentication and some minor data sharing but not extensive data sharing. The extensive sharing of medical records would be on the internet.

The second phase was really concentrating on the whole idea of creating a web-based patient account that would be able to use digital signature technology to be able to integrate systems from multiple providers. The project intended to build bridges across multiple levels of government and the private sector, to demonstrate secure and scalable-- and here the keyword is scalable -- processes for individuals to request and disclose medical information. To be able to combine the use of a card and the use of the internet, to kind of get the best of both worlds and to test interoperability across multiple levels of government.

As you can see, I think today we are at the stage where it's very easy for one or two requesting and providing organizations to, in essence, come to some agreement about how they are going to share data and build interfaces but as you start multiplying the provider organizations, and you start multiplying the requesting organizations, the situation becomes very complex and very unmanageable.

So the western governors went to the Federal Public Infrastructure Steering Committee Health Working Group which is a group that has participation from a number of federal agencies that are looking at how to securely share information across each other's facilities and came up with this model that would try to get at the problem of how do you scale the exchange of medical data.

A key part of this project is to come up with those common operating rules, agreements and procedures so that entities can feel secure about exchanging confidential information.

My colleague alluded to the Visa-MasterCard model. It's a very similar thing in action here. Just as merchants and issuing banks adhere to a common set of principles of the financial community, they need to do the same in the medical community.

So this project is really about both management structures, those operating rulings, those common protocols, the control mechanisms as well as the software solutions.

A very key issue about this approach is that while there is this common basis, there is no need for a single universal patient identifier. The patient can, in essence, keep different identifiers from every different system the person participates in on the card or in the what we call the facilitator application so that there can be a translator.

There's a single card number that can link to multiple different client identifiers and can do so in a secure way.

The patient below is quite similar to the one that have you have just seen in the presentation before mine. The idea is that the, both the patient and the requester have cards that can be used to digitally sign a request for medical information. When a patient presents in any of the participating clinics, the requestor can sign this request and the patient can authorize each and every request for information.

The request is sent to this facilitating application which verifies the digital cigture and also checks the authorization privileges of the requestor, of the questioning provider. The provider could be a health care professional, could be a nutritionist, could be a Head Start family worker, could be a clerk doing demographic intake. Could be any level and it's very important to be able to maintain patient authorization privileges for the various different levels of data.

The request is then routed to all of the systems in which data for the patient exists.

The provider clinics, if it's an electronic document, that's the best of all possible worlds. The data can be sent back to the aggregator and presented in realtime to the requestor.

If, in fact,, the data does not exist in electronic format which is what we are finding in most of the clinics we are talking to in terms of gathering requirements, there are multiple ways that that problem can be approached.

You can use a scanner, you can use a data entry, web-based data entry screen. You can use services which is what Social Security, for example, does when it needs to give medical evidence.

But the data, once it is put in electronic format, is sent back to this facilitating application and is presented again in realtime to the requestor. No data is maintained at this aggregator application. It is only a switch or a hub.

The only thing that is maintained is an audit data because of the fact that it had been requested. The fact that it had been provided and the date of what transaction has been requested and what information has been provided, what transactions have been provided and that is done to be in compliance with the HIPAA legislation.

This facilitation application validates requests, generates disclosure requests, wraps the transactions and maintains the audit data base.

It also becomes a hub for the authentication of the requestor and the provider. It becomes a way of maintaining confidentiality and maintaining compliance with HIPAA.

A key point about this approach is that when additional participants want to participate, it's quite easy. All you have to do is agree to abide by the common operating procedures and build a single interface and you then have the capability to interface with any number of other providers who are participating.

The idea for this project was to do a pilot area in the San Diego community and then scale it at whatever level, whether it's at the county level, the state level or regional level.

Key issues about this-- it's scalable, it uses a rule based protocol, it's convenient for the patient, it's convenient for the provider and most importantly, it's low cost because requestors and providers don't have to re-do their systems, they don't have to argue over a common patient identifier. They can use their existing systems without the expense of modifying them.

Where are we going? Truly I see a convergence of these multiple technologies. Idea authentication is the foundation that makes all of this possible. We are going to see more and more different public and private entities in the health care arena, combining resources to get to a place where they can afford to exchange data conveniently.

Thank you very much.

DR. LUMPKIN: Thank you, I thank all the panelists. It's certainly a very thought provoking discussion this morning. At this point we have time for some questions before we take a break.

Agenda Item: Questions and Discussion

DR. SCANLON: I would like to ask Barbara a few questions about the passport project.

Barbara, it seems like the focus was on public sector programs and so-- in essence you have a captive population in some of the programs in each of the three states you started at.

So, if anything, that should have been a good, with that much control and with sort of the benefit situation. That should have made it somewhat easy over the general situation where there's no direct connection.

How far along are you now in what you described to us here in terms of the data interchange and the standardization of records.

MS. SELTER: I did want to comment on the fact that while it was a public benefit recipient audience, the patients had full ability to opt out and, in fact, of the 30,000 participants, there were no fewer than, no more than a handful of participants who chose to opt out and quite interestingly, when interviewed, we did a significant number of patient satisfaction surveys and one of the key questions was how do you feel about having confidential information on this card and to our great surprise, we found that most people believe that the security of the system, of the card, was far greater than the security they had over their data right now and so that was a big plus.

We are in the requirements gathering stage now. We are going to be again targeting some public programs but a number of our partners in the San Diego area are private providers. Scrips Howare is one; Community Health Group, which is a private managed care organization is another. We have a number of private physician's groups and the support of the San Diego Medical Society.

So the idea is to move more and more into the private sector as well as the public.

DR ORTIZ: Hi, Eduardo Ortiz. I have a multiple level question but to begin with, Johnny Walker, I wanted to ask a similar question in terms of how far along you are in terms of PSI in terms of practical application operationalizing, you know, how many provider organizations or clinicians organize patients, etc., are actually already working with you on this.

So just kind of from that perspective, I'm not sure exactly where you are in the spectrum of development and implementation.

But then along that line I was thinking, it seems this model that you have come up with is a very interesting model where you can serve as this kind of national hub where people can connect to and have access to this information but not have the information themselves so it seems like a real interesting model.

But I'm also thinking, as this comes up, that there may be other organizations or groups that are interested in doing similar things so, for example, this passport project could be, you could consider it maybe a competitive project or a kind of a regional level so I'm wondering one, on a national level, are you aware of any other groups, organizations, etc., that are trying to do the same thing that you are. If they are, or, if not, groups like passport, do you see this almost in a way as if they do come up, is there room to have multiple groups doing the same thing?

Would it be more competitive, would it be more collaborative, and then on top of that, the question kind of also goes out to David Brailer. Would be your organization, David, is a for-profit company, isn't it, your Carescience is for profit?

MR. BRAILER: Right.

DR. ORTIZ: So I'm kind of wondering, too, as these things evolve, how you guys feel about each other's technology. Like would David see the PSI as potentially a competitive thing that might be good because he is a for-profit company.

Do you see it as something like wow, this is really cool. We would interact with them and that would be an opportunity for data to be shared nationally so, you know, it's kind of multiple levels of my question but I'm really interested in getting some answers to those.

DR. WALKER: Let me take a shot at a couple of those. Maybe reverse the sequence. In regard to western Governors, they actually approached us and said couldn't we work together?

There's no sense of having our network and your network and where you and again, ours is a non-profit so we don't have to be worried so much about competitive because our mission is to be helpful. All we've got to do is be sure there's enough cash to undertake any project we do.

So we basically began for months telling them everything we knew how to do and finally they suggested why don't we work together so there's already discussions underway about how we would combine these two.

We, likewise, with communities, Santa Barbara or any other community, would be more than glad to take that community. There's no sense of reinventing something that's already tied together and just making an access to another community that may be using a different way so our goal is to fill but not are placed where something already exists so we don't have to be everything.

We only want to be something that everybody could trust that it's a means to share data.

MR. BRAILER: Sure, I can comment on that. First, CareScience is a technology supplier who the Santa Barbara County Care Data Exchange and I think we've already established in our discussions that the technology is not the rate limit step and so the Santa Barbara County Care Data Exchange is, in fact, a collaborative that's established by that county, that's owned and operated by the county and the other 12 care data exchanges that we are bringing up in nine states now are you separate and independent organizations.

More than half of those are using technologies other than or in addition to CareScience technology.

In fact, if you look at the complete set of technology that's needed to do this, it is quite broad.

So I think the question is not one of what will CareScience to do. It's a company that is in business to provide solutions that are necessary to fill gaps in technology availability. The question is what these independent regional or community organizations want to do.

And they are involved in a variety of discussions with service providers, with data holders, state, local and national, technology and service organizations, consulting entities.

I would say, if you can ask the question how do you characterize these, the answer is I see clearly the need for addressing these standards. I see a need for addressing an architecture or a framework of business policies but in the end, I think different regional areas are going to want to approach this differently so I think the answer is all of us should want to collaborate and be able to do that and I think it will take a nested federal, state, and community level effort to actually to make this happen.

DR. ORTIZ: Just, Johnny, once again, on the follow-up thing, could you let me know how far along you guys are and also, are you aware of anybody else doing this on a national basis besides PSI?

DR. WALKER: I'm not aware of anybody that's doing it on a national basis. We would invite everybody in the room to come see our demonstration site in Seattle where we have our multiple hospitals connected together with the physicians there.

We are bringing up the ER as well as now we are beginning to add the family practice there so it's scaling as we speak. We have now had contacts for literally a number of states to do statewide initiatives and should be announcing one of them fairly quickly as well as we are in discussions with several more to follow.

So we are both at a community level, but our focus is a much broader, higher level, national-state focus where each state will, in essence, coordinate its own direction and priorities and how it wants to bring its hospitals, its public, its physicians together and then provide assistance there with them.

MS. SELTER: I just wanted to make one brief comment.

We certainly, from the perspective of the Western Governors are very excited about the work of the Patient Safety Institute and are hoping that we can actually piggy back on the work that they have done.

But I think what's most critical is for the government to take a lead to insure that there is a framework of business practices, technology standards, so that these projects that probably are going to get going on the local level can become interoperable with each other and be able to kind of expand the scope on an ever-winding basis.

I think most of the people who are involved in these local level projects are very collaborative and want to be very collaborative and are looking toward somebody and hopefully, I think that should be the role of the government, to kind of push some sort of common operating procedures and technology standards so that these different local level initiatives can come together in the national level.

DR. ZUBELDIA: I would like to ask about the use of standards for these collaboratives.

It seems to me like the master patient index is a very good technology that can be used to circumvent the lack or the necessity of a national patient identifier but there is another piece that seems to be lacking.

I haven't heard much about how the providers retrieve this information and it seems from-- what I'm getting from here is you have to get to the web and get it with a web browser. That doesn't do much good towards an electronic health record that is integrated in this environment.

Have you looked at using standards for data interchange or electronic health record interchange so it can be integrated into a provider's EHR if they have one?

DR. WALKER: That is a subject that we are most interested in, in fact, we view that we need to stay-- PSI needs to do what it can do which is be a trusted third party. For goodness sakes, it doesn't need to be another vendor solution. That's the last thing we need is another vendor solution so our whole goal is to be what we call PSI inside which is take the utility, deliver the data and let the person use it in his EMR the way he wants to, that he already has set up. You do that by defining discreetly and architecturally the components. HL-7 is already a greet start, has definitions for all the five data that we start with and allow today to move the data in, for instance, in labs, if it's RBC or its red blood count, it goes in as discreet as soon as the community decides they want to use LOINK and they all choose a standard and start using it, that immediately then facilitates a standardization of everybody being together just by their choice because you are already selecting it as discreet but even before the selection of the users to agree on a standard, they can still be seeing it in their system with their other lab data which now allows decision support, integration, other things that now happen when you have facilitated collaboration of data. Does that help?

MR. BRAILER: Can I comment on that as well? I think one of the transformative episodes that we stumbled across-- I wish we could say we planned for-- about a year or maybe a year and a half ago was the creation of what we called polling access meaning that rather than going to a browser and looking up someone's data, a physician subscribed to a patient's data and told the application where to send it, either to a browser, to e- mail, to a PDA, to a fax machine or in an XML object to another application. That's when user participation exploded. That's when we saw a very, very large increase in traffic and frankly, we saw a wide variety of published forms, of data going to a place representing the broad variety of how data was used.

I think that really raises the question about there not being a single specific solution or a means of getting access to data, interoperable or not, and so I agree that there's no question that in the end, whatever data we provide from these solutions have to be able to meet the needs of the community or of a group of people regardless of whether or not they are standards eligible or they are able to actually implement things, quote, the correct way.

But this very ecumenical view of how to get access to data I think is what's needed at the real street level of this kind of an application.

DR. BLAIR: Forgive me if I'm identifying the wrong person, but I think Johnny Walker from PSI, you were indicating that EU had to use a public relations firm to identify valid groups that would represent consumers, is that correct? Am I speaking to the right person?

DR. WALKER: I think so. We did use one to try and determine who would be representative nationally of physicians if you only had a few-- or patients-- if you had a few to choose.

DR. BLAIR: This, I think has been a problem that other groups have run into before is trying to identify organizations that could represent patients very well. There are advocacy groups and they do play a constructive role but finding organizations that actually have a fairly broad or diverse membership representing consumers, if you have found some, not only would I like you to share, if it's okay with that group, share that name with us on the committee, but as part of our NHII recommendations where we indicated that other organizations like HIMSS that's here today, that they are going to try to also coordinate with consumer groups so if you have some names of organizations that could help all of us, that would be helpful.

DR. WALKER: I would strongly recommend our three advocates. They are listed there.

Linda Galadner, the CEO of the national consumer's League, she was recommended because she's on so many committees nationally so she gives a great diverse use and connectivity. If you want minorities, the mother ship is the National Alliance for Hispanic Health, the whole Latino health care advocacy and Jane Delgado actually is a practicing psychologist and has written many books and she is incredibly knowledgeable.

The final one is if you can pass the privacy question you want to pose to Twila Braise of the Citizen's Council of Health Care, if you can get it past her, you can get it past anybody in privacy and security so she is-- we found her to be the litmus test. You pass her, you passed everybody's requirements.

DR. LUMPKIN: Mike, for the last question?

MR. FITZGERALD: A series of quick answer questions, I hope.

The first one for David Brailer. On slide seven you talk about information fragmentation in Santa Barbara County and you have a set of very interesting findings. Was that a survey? How did you get that information? Did you look at a batch of claims data and then go to the medical record?

MR. BRAILER: I sure appreciate the question. When we were invited to do, by Santa Barbara to determine whether or not is project like this could work, essentially as a re-visit of the Chen effort, we wanted to do a lay of the land and so we did a six-month feasibility study that included a variety of economic, geographic political assessment, including an assessment of a random sample of about seven percent of patient care transactions and this data was collected through a combination of some electronic data but also chart reviews and it was a pretty painstaking effort to piece together the patients and try to understand what was really going on with pair because the underlying question, both from a patient care advocacy perspective and from a business case perspective was how bad of a problem, therefore what is the upper bound on what we can solve so this came-- and this was in our feasibility study report to the California Health Care Foundation as well as a number of other details.

We have not published this in the academic literature. In fact, we cited a number of academic articles that corroborated everything we found. In fact, we set, frankly, the minimum of some of the other studies so that's in this report as well as some of the other findings.

MR. FITZGERALD: Thank you. And for Pat Wise-- I don't see a page number-- you talked about the Wisconsin Health Information Network experience between $17,000 and $68,000 savings per physician practice. That's a lot of money saved.

What is the source of the savings? Postage? People scrambling around for paper?

MS. WISE: Mostly it was in the great hunt. I know we got the results, I saw it yesterday, where is the today.

MR. FITZGERALD: The man hour time needed to go pull a record or something.

MS. WISE: Exactly. That was their single largest savings.

MR. FITZGERALD: And for Barbara, I would like to ask, the kiosk you described, that a person puts their card in and you get to see information about that person, is the kiosk basically reading information on the card or does it link up to a central data base about the person from which the information when it comes to that person?

MS. SELTER: The information in the first phase, the kiosk was focused on the card as was the project. It was card-centric. And so the kiosk was able to just view the data on the card.

In the second phase the anticipation is that the kiosk would be integrated to the internet and hopefully in addition to having the security to enable the patient to view electronic record via the internet, but only their record, would also provide, for example, if the patient was a diabetic or if the patient had some sort of heart disease, the patient could put their card into the kiosk and be taken to various health sites that had relevant consumer information, hopefully from the National Library of medicine.

DR. LUMPKIN: Could I just sort of ask a follow-up. What happens when the patient loses the card?

MS. SELTER: In the first phase of the project, the cost, first thing is that the security in phase one surrounded by a PIN. Nobody could access, nobody could read information, nobody could write information to the card without the provider putting their card and their PIN in and the patient putting his or her PIN in.

So if the card was lost, nobody could access the information without that PIN number.

In the first phase there was, in the data base that was maintained, a back-up for the card so that the card, the data could be downloaded. That was considered not the most desirable approach and so therefore in the second phase, the idea would be that there would still be a PIN or, alternatively a biometric to protect the data on the card. We are looking at the use of a biometric because that's a little bit easier than remembering PINs.

But in this case, most of the data would remain in the disparate systems, the digital certificate would be revoked immediately.

MR. FITZGERALD: And a question for Johnny. Maybe it's from watching all these Super Bowl commercials or something but I can harken back five or six years ago when Dave Thomas was flipping burgers at Wendy's and this little old lady comes in and says "Where's the beef," so I started asking are where's the product, where's the content, where's the business case to show where the benefits exceed the cost and maybe I have concluded it incorrectly that your patient safety institute develops policies that are reviewed by your board for acceptance and appropriateness and you partner with somebody who supplies the technology that will implement those policies. Is that a fair assessment of what the Patient Safety Institute does?

DR. WALKER: No, I would suggest that we take standards and policies that are the industry EHI or other industry groups, NHI are actually creating and facilitate those.

We are focused on a very singular focus mission and that is creating an infrastructure with a trusted third party that allows it to connect, a Visa-like net work, not being the bank, not being the retailer, not being the consumer, just how do I use a card or a means to do the data and what happens behind the scenes.

MR. FITZGERALD: And so you have people who can go out and install the card readers and run the PKI, all in the Patient Safety Institute?

DR. WALKER: Well, no, actually that is people we would work with but not be dominated by anybody or beholden to any so if a hospital has a particular vendor they want to use, we would use their vendor.

To scale the size and the speed we are wanting to scale, obviously you can't limit it to any organization, much less a non-profit so we have to use all the big players in the country to assist us in rolling that out.

MR. FITZGERALD: Okay, I think I understand.

DR. DEERING: I have a couple of questions for David, and they both have to do with the consumer component which I understand you are just in the process of rolling out.

I think I heard you say that consumer access is contingent on physician approval and so one of the issues is does, since one of the propositions to all of this is that individuals have multiple providers and that is why we need this in the first place, from the consumer's boyfriend.

Does that mean that they have to re-register individually at the beginning with every provider who they would be dealing with within this framework or would you envision, if not now, in the future, that having once registered and authenticated at their first point of entry into the system that there would be some simpler, streamlined solution for them to register?

MR. BRAILER: Thanks. Let me speak both to the technical process as well as to the kind of underlying pulse issue in terms of physician approval.

One of the by-products of the physician implementation is that we create a matrix that identifies the set of all patients by the set of all doctors so essentially we know the intersection of where a doctor has seen a patient in the past.

We use that to generate a roster for the physicians so the physician can go on-line and look at a list of all patients and perform actions like subscribe to their data, etc.

The flip side is that we have a list for a consumer of the doctors they have seen and so they don't actually have a registration process that is doctor-dependent.

The issue is not at the registration level. It is at the data availability level and on July 6th of last year, our policy was that data had a two-week delay period and then was made available to consumers and then Governor Davis signed into law a new policy that stated that physicians had to review this data in advance and so it was changed to an approval process.

So that not only gave physicians, if you would, direct control over whether or not a patient saw a blood test or a radiology exam, but it gave them implicit control over whether or not consumers could generally see any of the data from that doctor.

Now, the real equilibrium is that if a consumer wants to see their data, it's been our experience that doctors get on board relatively quickly however the push-back is, that if physicians don't want to participant, it puts a real barrier up with consumers being able to do this so it shifted a lot of control back towards the physicians.

So technically I think it's quite straightforward to do this, but at least in California, the law is that physicians have to approve specific results in advance and therefore physicians have implicit control over data availability.

DR. HAY: Just for clarification, that's internet only available information?

MR. BRAILER: Well, yes. I'm not an expert on the law but as it has been interpreted to me and as I read the tome of all this-- it's amazing how many pages it takes to describe what I just said, it is not limited to browsable internet. All forms of internet, including wireless and other electronic display means so I think it's subject probably to another part of government to determine what exactly that means, but the intention was not to prevent data from being made available, i.e. to protect confidentiality.

It was made to protect the doctor-patient relationship and so my belief is that it's going to be interpreted quite broadly for any form of transmission of data to a patient that a doctor hasn't seen in advance.

DR. LUMPKIN: Okay. We are at our time for our break unless we have some overwhelming question.

I would like to that I think the panel for their presentation. Very interesting addition to our discussion on the personal health record.

We are going to have a break for 15 minutes and we will start off with our final panel for this hearing. Thank you.

(Brief recess.)

DR. LUMPKIN: I'm going to suggest that because of a technical issue, maybe it would be better if Brad would go first. Let's see, how many people have Powerpoints? I think we have a glitch with his laptop which is, by maker shall remain nameless, so I think if we start off with-- if you don't mind, I'm going to change the order. We'll start off with Peter. We'll go to Brad because in order for his laptop to sense this thing it has to be re-booted to we don't have to want to have to do that a couple of times and then we'll go back to Glen and Marty.

I'm going to ask each one of you to introduce yourself. We are going-- this is an audiostream on the internet so if, I would ask each of you to introduce yourself and then we'll go back to Peter to start.

MR. WAEGEMANN: I'm Peter Waegemann. I am the Medical Records Institute which is ASFTM and am involved with a number of issues I don't want to bore you with, but I was in 1995 a judge for NII for health care and have been the health care chairman from 1996 to 1998 of ANSI's information infrastructure standards panel.

We worked very hard in those days. It was about two meetings a week for two years on information infrastructure issues so I feel with you and if you don't mind, I start out with a few comments about information infrastructure. I'm involved currently with the information infrastructure--

DR. LUMPKIN: Peter, I'm sorry, if I can just have everybody introduce themselves and then I'll come back to you to do your presentation.

MR. MARSHALL: I'm Glen Marshall. I'm currently the principle security architect for CMS Health Services. Approximately 36 years in health care IT so I've punched a lot of tickets on that, plus I'm involved deeply in standards efforts focusing around security and health care infrastructure with HL-7 Dicom, ASTM and IHE.

MR. ABRAMS: I'm Marty Abrams. I'm executive director for the Center for Information Policy Leadership which is located at Hunton and Williams, a law firm. I'm not a lawyer and I need to disclose the fact that I'm not a lawyer.

I run the center. I've done consumer policy for 25 years. I've done privacy and security policy for 13 years. I do this policy from a balanced consumer-business-government perspective.

MR. KELLER: I'm Brad Keller. I'm the e-business risk manager at Sun Trust Bank, responsible for all on-line privacy compliance, risk management issues. That includes all authentication and identity protocols for the on-line environment.

Agenda Item: Panel 6: Authentication Issues

MR. WAEGEMANN: Thank you. I was just trying to say that I'm involved in a good number of country's initiatives on information infrastructure, particularly also Canada and some other countries.

I want you at least to be aware that three countries-- this is the UK, Sweden and the Netherlands had substantial problems with their information infrastructure projects.

In Sweden, after having worked for two years spending about $30 million, they discontinued the project. In the Netherlands, the most advertised, I would say, world-wide advertised project on the national health information infrastructure, also funded a 30 million euros, has been discontinued two months ago because of too much criticism and problems.

What are the problems? People have been focusing on technologies, have been focusing on an infrastructure issue which is relevant today but will not be relevant in two years or three years.

This is a big problem you are dealing with as you are creating an infrastructure, as you are having hearings on technologies, on projects, that they may not be acceptable or may not be the worthwhile in three or four years as we are moving into wireless area, as we are moving into very different technologies.

What went wrong in those cases? It's really lack of flexibility, lack of goals. I'm looking at many NHII issues and that's why my paper which you have in front of you, I have identified the six goals and I would really urge you and charge you as a committee to look those and to say what are the areas where it's worthwhile to focus on?

I may quietly say that I think personal health records is not on the top of my list, but as we are here for personal health records, I enjoyed listening this morning to the various presentations and I think what we need to start out with is to have some definitions here.

I hear presentations on EHRs. We have ten different current, valid visions of what an EHR is. It's not a place here but it's worthwhile to understand that people are working on very different models here.

When we are talking about your personal health record, it is my understanding that we are defining this as something which is really being kept by the patient or managed by the patient if it is a web based system or if it is on a token as we heard a smart card would be a USB storage device or whatsoever or some paper-based system, and what we have to realize there is that these are not new, that the current for most accepted personal health record is the child passport which, according to the World Health Organization is currently being issued by 58 countries worldwide and when a newborn is born to be given to the parents where they start recording some information.

In our countries, or most countries after one or two years, it's being discontinued, but it's the beginning of a personal health record.

So what we really have is three kinds of personal health records as far as technology goes. The most common kind is on arecord. We had at some point 112 companies and Fred Field will be describing that they have shrunk to about 30 in the United States.

We had at some point, 13 million patients to my knowledge who had put their personal health record information on web sites. It has shrunk to 7 million active ones, and if we are talking about what standards we need and what the problems are, then the main issue is when people call me all the time and say, Peter, I put my personal health record on the site of healthor whatever and it isn't there any more and now, suddenly I wanted to use it and all of those have been discontinued.

So there are currently about 6 million of those worldwide on web-based systems.

There are token based systems and what is quite interesting to listen to, that list 40 I know and over the last 15 years, more than 50 companies, organizations, not-for-profit organizations and others who created systems where you had on a smart card or an some token now. One item right now is a USB drive you can buy for 30 bucks and you have 32 megabytes on it and it's part of yoursystem and there are companies starting out all the time and saying no one ever thought about giving this to a patient. Isn't that a great idea.

As I get these calls, I must tell them all, it doesn't work. We have seen it. Richie Free of the European Union once about four years ago said we want to have a demonstration project of at least 200,000 patients. They couldn't find one.

Of the projects which were funded in Europe, and particularly in France and Germany, were discontinued. Sixty percent of encounter information is arriving at theprovider where the patient has left. What the patient carries is not valid, it is not good information becausetest results can come out of it.

Secondly, identification issue. We have one case in California where a grandmother was taking care of 15 -- smart card cases-- 15 children. One got badly hurt. She grabbed the card. It was the wrong card and as we heard early on, it can only be done if you have the individual's consent. It doesn't work because if that individual is unconscious, you still need to get into that information if it has any meaning.

Secondly, we have a good number of states here in the United States where if you have such a token-based system and you have an accident in New York City for state laws, before any emergency physician can access such information, a law enforcement official has to give in writing that no personal belongings are to be taken out of his wallet.

Go into the Bronx in New York City and have a law enforcement officer to verify in writing that you are not taking anything out. By the time you do this, the patient is dead.

What we have to realize is that token based systems is something which comes up all the time. It will not work at this point and I'm willing to change my mind if it happens, but we have a history of over ten years of people starting it and discontinuing it.

It's as big an idea of web based systems and there are web based systems, quite successful, particularly if the funding is right but you have to realize here is what kind of revenue model will we have? I think I heard testimony yesterday from Velamid(?), probably one of the most successful companies where if they take employers and others to sponsor it now, it's not always, it wouldn't be my idea to put my health record onto a web site which is being paid for by my employer or by some other organization.

So we really have to see what happens at that point.

Definition we have to be clear is personal health record is very different from the electronic health record by a provider. The personal health record has to have three parts. This is something which has been established over the last seven or eight years.

The one part is what a patient takes from their provider organization. Now, I went to my providers, to 17 of them and got 88 pages of copies from clinics and doctors and so on and so on. I put those onto five or six of those web sites in order to test it.

That's only one part of it. But patients wanted two more parts. The second part is patients really want to have a record of the alternative medicine. When they go to a chiropractor and they go somewhere else, they want to know what is the cost difference of having some alternative medicine and what does that really mean for their health care procedures.

The third one, an important part is that patients have been saying we want a personal health record for very personal information, not for medical information from a provider but for us. People are saying I want to have my-- it's a female patient, my menstruation data.

I want to have some sexual data which I may not share with anyone else, but I want to have a record on it or I might have some personal problems where I had a rash two years ago. I bought some cream over the counter. If I only would know now what I did so if people want a personal health record for such purposes, what we have to keep in mind is it personal health record is --

As I mentioned, from 1999 to the year 2000, there was this---- and many companies started, many organizations and clubs and other organizations started it. Most of them have discontinued, as I said earlier, we had the reduction from about 13 million to about 7 million at in point and the growth is very slow at this point. It's more declining in the United States.

Where it is increasing is outside of the United States, particularly in developing countries where ten percent of the population, the well-educated, the rich people, are saying I spent easily 50 to 200 bucks a year to have my health information on the web site and when I get really sick I have an airline ticket, I travel to New York or to London or somewhere and get treated, then I have all my health information available, it's worth it for me. There's a current increase of personal health records.

What we have to realize also is that there are some interesting movements to combine towards the EHR. We had the history four years ago, one system has offered to a good number of patients that information could be directly downloaded. It's the only system where this could be done.

Very few patients took part in that program for one reason. Like myself, when you get 88 pages of your health record, what a patient does is filter it and says, I only put certain information on there, I don't need all the information from ten years ago about what a nurse wrote about an eye infection or whatever.

So because of it, there really isn't currently no method where the EHR information in its summary can be taken and automatically transferred to a personal health record. It has to be done for a patient or some companies where some companies are out there which are doing that for patients. They interpret it and continue it.

What you should be knowing is that three countries-- Israel, South Africa and Switzerland -- are currently looking at a combined personal health record and a national EHR record where if they are talking to companies which provide web-based systems for every citizen in the country or for every person living there, for, in Israel, for instance, Iwatched the Knesset for $10 a year and the independent company provides it for all providers or doctors in the country, and everyone, would have a system.

We don't know if it will be successful. We don't know if it will be accepted. I just wanted to know if the negotiations are going on at this point.

What we really have to understand when we look at the personal health record and identification and authentication issues is really the ASTM standard and I understand that there was some talk about that yesterday which may have been some misinformation which has been validated which is a national standard and this standard 221102 is a standard which has become not only an ASTM standard but it's a national standard which defines the minimum data set which defines the relationship for authentication and the requirement for organizations in the field.

The five questions which really come up in regard to authentication to personal health records is who created the information and here we have a number of issues.

We have to realize that it is not your provider. It's the individual who owns and manages and creates the medical record, the personal health record. We have to understand that people are talking over and over. We would only make brokers with national NHII if we had national patient identifier.

We just mentioned here I was asked to testify when two years ago, with the airline industries, we need to have a national identifier for airlines. They didn't do it and I was involved some eight years ago when the banking industry said we finally need a national identifier for banking because individual records have so many different cards and the card numbers and what so ever and wouldn't it be nice to have a national identifier for banking and banking worked wonderful by having a bank number and having a provider prefix.

So your American Express will always start with 37, the same as my Harvard Community Health Plan could start with a prefix and then my number and could give me a perfect national identifier.

People are still saying this is a major problem. It is not because it has been shown in different industries that this can be handled quite well.

The information is currently handled in personal health records by having either a password or having a shared secret. Some people are moving to the Microsoft password or the passport or the Sun passport. These are being used on the internet in general terms and it is my opinion that they would be more than adequate for personal health records on the web site.

The second part is how can one be sure only an authorized person can access the information? Again, it's a question of with passwords. The key issue, when you talk to the companies they say, well, one only can access it if a personal key or personal password is being given.

There were two European studies in France where it has shown the value, at least of a token based or web based personal health record is over 50 percent, in cases where a patient is unconscious or is not able to direct the individual to give the patient information so you have to override it. You cannot say, you only can access the information if you give a password.

So therefore here is an issue where again the ASTM standard has addressed that, we have a national standard.

The third one is really the responsibility and how trust worthy is the information. Now, this is a major issue. I'm probably the one who has been over the eight years most speaking to many organizational personal health records.

When I speak to traditional staff provider organizations such as the Mayo Clinic, they have openly saying Peter, we wouldn't trust the personal health record. A patient could potentially just massage it and who knows what the patient is going to say.

So this is an issue one cannot address in standards. It is an issue of whether the provider trusts the patient in general because most of his symptoms and most of the input into any encounter comea from the patient and the provider has the choice, the practitioner has the choice to believe it or not believe it and the same applies to the personal health record.

When we are saying put the information has been changed since it was originally created, now, this is the biggest.

Of course, what we have found and we worked with the ASTM on that standard is that none of the web-based companies, none of them, had policies in place which were adequate or would be just common in a hospital or anywhere else. They hired just the data base guys who had no idea of confidentiality or security and they had no way of addressing the health care concerns properly.

This is what the standard is for and what I would urge you is to recognize it and to make sure that the industry and everyone who is concerned with personal health records really follows that standard.

It's not a guideline, it's a specification of what needs to be done. It's very specific in each point. And it is available on the web site.

What we really have to realize here is that when we talk about standards-- in 1999 we had the Workgroup in ASTM where we had most of the major players from Web-MD to Health Magic to all of those. We had usually meetings of 50, 60 people and the industry really discussed in the following ways what standards are needed.

You don't need a standard for, an additional standard for data content. ASTM is working on continuity of care, the minimum data set. All of these have been national standards, not just ASTM standards but national, US national standards. So we have a good number of those. We have a main standard for the relationship between the provider and any kind of authentication and data integrity in that here.

And I think where we have to keep our focus is that the one growing area, the personal health record is not for independent organization, but it's a provider organization.

So in my hometown, it is the care group and many others where you can have your patient information on your provider web site. This is now you have one provider and you have only part of the information. You have your medication list, you have you allergies, you have all of this. This is for growing personal health care record field. This is really in many ways where the main future is.

Thank you very much.

MR. KELLER: Well, fortunately, my area is online risk management, privacy, not managing my own personal PC so hopefully you'll take some comfort in that. I apologize for the distraction.

I do want to thank you for inviting me here today. The banking industry is very pleased to be able to offer you whatever insights we may have under the issue we've faced and that we are going to continue to encounter with authentication issues.

Authentication is a very challenging topic. I commend you for having these types of hearing to try and gather insights and look at other industries and areas to try and explore how these issues are being addressed.

The banking industry devotes a tremendous amount of resources to this area, not only individual banks but industry as a whole, both industry groups, the American Bankers Association and others devote tremendous resources to helping to deal with authentication issues.

Obviously the opinions that I express here today are mine and are not the statements and opinions of Sun Trust Bank's, of BITS or the Financial Services Roundtable. The interesting proposition -- it's one that I've thought about for some time -- is that long before there was an internet or a need to authenticate individuals online, banks have sort of been the trusted intermediaries. Banking, in fact, is built on a principle of trust and banks have been keenly focused for a long time on protecting the confidentiality of our customers' personal information.

The public not only trusts us with their funds but with the details of their personal lives as well. We have responded to that trust by exercising extra diligence whenever we are handling confidential information and because of the amount of information that we have about our customer's financial lives, we are able to provide them with substantial insight and assistance in finding the right financial product to suit their needs.

Now, that service, though, has become far more complex as both financial markets and financial products have become more complicated. It used to be that knowing our customer was a simple process of sitting down in a branch and talking to them over the desk. However, with the advent of telephone and electronic banking, that process has become obviously far more complicated.

We are not compelled to ask complicated questions and sometimes very burdensome andonerous questions of who are you? NO, really, I really need to know. Who are you?

Unfortunately, customers don't always react as we wish they would to being subjected to such an onerous and burdensome inquiry.

But our goal as a banking industry remain the same, to provide a satisfying, convenient and effective experience for the customer that also protects the assets and privacy of the customer and the bank, a goal I'm sure that you are striving to as well, to protect not only the privacy or the information of your clients and your patients as your business partners but also those of the people that you serve.

What I want to do is first start out with letting you know what we encountered when we first assessed authentication because when we first looked at it as a practice, as a principle, as a process, we were doing it as you are today and go over you with you so many issues and challenges that we found, then talk to you about what that assessment revealed to us and highlight for you some of the directions that we think authentication is moving to and what we think the future vision may bring.

The original authentication challenges showed that there was a real lack of central guidance for customer authentication. It resulted in a very complex environment for security administration and it was very cumbersome customer experience.

The user, the person who we were trying to authenticate, whether that was a customer, an employee or a business partner-- and I think you will find that whatever the given instance is, the role will be changing depending upon the circumstances.

That user was required to remember and maintain authentication information for each and every relationship they had with the institution. This created an overly complex situation for both the bank and the user, resulting in very high administrative costs and very poor customer-partner-employee experience.

We also had conflicting ownership. The process was owned in many cases by different business units. Services were either owned or controlled by individual business units or, in many cases, by the vendor that provided the service. This resulted in no corporate standards for IDs, passwords, or the authentication process itself. This substantially reduced our ability to administer authentication in a cost effective manner and compromised best risk management processes.

We also found that the application owners, system owners themselves were developing highly specialized solutions. While this was necessary because of the rapid pace of development, authentication was often being defined by the companies that developed these applications or, in some instances, by the application service providers that were hosting the services.

While this was good and necessary to meet time constraints and sometimes regulatory and other requirements and considerations, it created a significant challenge to the banking industry because it did not take into consideration the architecture or the infrastructure requirements of any individual institution.

And we found ourselves having to adapt our infrastructure to accommodate the needs, in many cases, by different hosted solutions or perhaps different applications.

We also uncovered that there were disparate business and technical controls. Numerous credentials were being utilized across the institution. Thus, even systems that may use the same standards for an ID and password may not identify an individual user by the same set of credentials or maintain them in a standard format. Therefore, one system that knew Brad Keller by a given ID and password couldn't talk to another system that knew Brad Keller by a different ID and password, again creating the cumbersome experience and driving up administrative costs expenses.

So what did we learn after we assessed all of our challenges?

Well, what we learned was that authentication is itself a process. In addition, authentication is not only a process, but it itself is a component of another critical process. We also learned that authentication must be approached with a focus on the impact it has on other important collateral issues.

What kind of a process is authentication? I'm sure you have touched on many of this over the presentations that you have had in hearings yesterday and today but we approach authentication as a process that uses risk factors to determine the appropriate method and identification for a particular customer interaction.

Those process elements begin with enrollment, we move to verification and they conclude with revocation. Enrollment is the simple process you would think of, simply signing up users for the system and providing them with the unique means of identification. But that requires determining what the users should be signed up for the system and what type of identification should be used.

Verification, which is actually validating that unique identifier, each and every time a user seeks to access the system. What we have determined, however, and it's something that Martin may address here momentarily, is that there is a real discrepancy between the level off protection that consumers seem to want and the level of effort they appear to be willing to make to secure the security of their identity.

Efforts by banks to require frequent password resets, use lengthy identification processes have not in general been embraced by the public.

We have also determined that consumers need to make a much more active role in preserving and protecting their access. An example would be an informal survey that was done amongst some members of an industry group last fall, found that even when consumers were provided with an opportunity to set or reset their passwords online, for their on-line access to various functionality, somewhere between 20 and 25 percent of them will still avail themselves of the call center to do the very same thing they could do online, having their password set or reset so providing that functionality to them and giving them that self-service, still had them going to the same call centers to do the same thing that they could have done online.

We also need to look at revocation as part of the authentication process which is denying users access to the system.

An important thing to think about whenever you are looking at revocation is that it must work simultaneously with verification to be effective. Also, revocation, as opposed to enrollment, must contain an information data base that's updated almost constantly because where enrollment information doesn't change that often, information for revocation where someone has lost a password or perhaps is no longer a member of your system if you are dealing with employees or business partners, they change, is information that has to be kept on a much more current, almost realtime basis.

We also look at authentication as using risk factors to determine the appropriate method of identification. The risk factors include the nature of the information being exchanged, how sensitive is that information? What channel is being used for that information? Is it a telephone or VRU which is more interactive as opposed to the internet and, of course, what's the customer's risk tolerance? How much effort and energy is the customer willing to put into the system and willing to get the level of protection that they demand?

The bottom line is that for some companies, these are their most important customer facing or business partner systems they will maintain.

If one of these systems, the authentication system fails, or is somehow subjected to an unauthorized use, the damaged reputation that could follow may itself be more severe than any possible regulatory penalty.

It's also very important to remember that the authentication process itself is a key component in managing confidential customer information. It is not only a process in and of itself but it is a critical and important part of another process, a process that begins with security. Simply determining and defining who should be allowed to have access to the system.

Moving through to authentication, which is who are you and what do I have in place to constantly know and determine what you are because really I need to know and it moves through to authorization because once authenticated, a decision must be made of the extent of the user's access rights. What will the user be permitted to see and do on the system? Which employees should have access to customer information?

Authorization becomes extremely important if a user has or should have rights to access to more than one system which is often the case with customers, employees and business partners rather than require each user to go through an authentication process for each system, banks are looking towards what we refer to as a single sign-on strategy or process which, once authenticated, would allow a user to have access across a variety of systems.

A single sign-on, while being very beneficial and giving access and vastly improving the administrative costs of authentication is also somewhat troublesome.

Using risk factors as a guide, you always defer to the highest risk system that a customer or a user seeks to access. The result is that there may be some very low risk systems that a user will attempt to access using very high risk authentication standards.

This may be contrary to customer expectations and create some pushback with users as far as the level of authentication that they are always willing to accept.

It also is somewhat problematic if the users credentials have been compromised because if the user's credentials have been compromised, they now not only have access to a single system but they would have access to every single system across an enterprise or multiple enterprises.

Another means that we are turning to right now is call what we call role based access. That's extremely effective within organizations and is defining roles for the employees and based on those roles, that defines what systems they would have access to so once authenticated, the role that an employee plays within an organization then defines what systems they get to have access to.

While with some systems, role-based access is somewhat difficult, the costs in general are more than outweighed by the benefits. However, role-based access systems are extremely expensive to maintain.

The final element in the process within which authentication sits is privacy. Authentication raises critical data privacy concerns because personally identifiable information must be used, unauthorized access to data bases that house this information poses a very real and serious threat to customer privacy.

But you also must consider when looking at authentication, what is the impact that it has on other areas. The two most notable are identity theft and authentication with and to third parties. Access to the information that facilitates authentication by unauthorized users could allow for identity theft on a massive scale.

Similarly, the misappropriation of a single user's credentials could allow an imposter to engage in transactions using that person's identity. Inaccurate entries or the failure to properly administer authentication process could result in the denial of access to financial assets or seriously damage an individual's reputation.

Not only must the information in the data base itself be protected to insure the individual's privacy, but the authentication process itself must be protected from disclosure. Only those individuals and employees who need this information to perform their jobs should be permitted to have access to the system.

An FTC report on internet fraud just released last week reports a significant increase in reported identity theft from 2002 over 2001. It's up by 162,000 reported cases of identity theft, from 86,000 in 2001. It's important to note that this is only the number reported incidents of identity theft to the FTC.

Banks are still struggling with how do we identify the channel through which identity theft occurs and while we are able to identify and halt attempts to access systems through misuse and appropriation of someone's identity, it is still difficult for us to identify exactly what channel or source that identity theft occurred.

Up until now, we've talked about authentication as a process or as an element within a process as it relates to just a single individual, organization or institution.

But authentication also has to take place with and to third parties. There's a need to provide interoperability of authentication across disparate autonomous systems. Financial institutions have determined that while we've become and are getting very good at determining how to authenticate our own customers, we are struggling with the standards necessary to be able to authenticate our customers with another institution's customers.

While banks have been talking with each other for years, having this contact conversation within a context of an on-line banking relationship is another matter.

We know how to use the ACH system, we know how to use the wire transfer system because those protocols and those methods for authentication are well-established but when we try to authenticate an on-line banking customer from one bank to another, those pre-existing means of authentication simply continue exist and that is the area where we are struggling with standards as we speak.

So I would advise and admonish you as you work through and look at your own authentication standards that you do that with an eye towards the need to be able to talk to other systems and other institutions to that you can avoid some of the pitfalls that are being encountered in the banking industry today.

But what can authentication be? What is the vision for the future? What I wanted to provide you with is a matrix that showed the capabilities of authentication and authorization mapped against some business capabilities and business drivers. I've populated some of this matrix as an example, how any individual company or organization populates its matrix is necessarily going to be driven by their own individual business drivers and their application infrastructure architecture.

However, it is representative of the trend in functionality across the capability shown.

It's for illustrative purposes only and provides a simple tool to use to chart your own organization against authentication initiatives. You will note is it is important to note that the further you move down the matrix and get towards advanced authentication of smart tokens and biometrics, as more sophisticated means of authentication, the more complex, time consuming and costly that implementation will become.

And finally, I would like to leave you with an illustration of how we at the bank see the flow of user authentication information for multiple channels and user access.

I wanted to give you an example of how we see an individual on a roll, how they would move through various channels and make their way through the authentication process with various methods, down to an application and ultimately through the data base it helps support that application.

This actually is a chart that we use at the bank as a litmus test against and to make sure that we haven't missed any information flows or any systems that information flows will have to go through.

This is obviously very simple and very high level but it did help us serve as a starting point to make sure that when we looked at customer information, we looked at the different channels and the different roles and how that information flows through.

Again, I would like to thank you for inviting me here today to share the banking industry's perspective on this important issue.

DR. LUMPKIN: Thank you. We'll move onto Glen.

MR. MARSHALL: I'm going to give you some perspective before I get into the presentation. Correct identification and authentication of people is arguably a persistent problem if not a hard problem.

Back in the 1930's before I was born, there was a company that made a wallet that they distributed when they sold it and in that wallet was a sample Social Security number. That Social Security number had been used by multiple people and screwed the payroll records for years.

And I'll back up, fast forward, back into the late 1960's when we implemented Medicaid. That was when I started in this industry. I was working at an inner city hospital with a very large urban population.

The possession of a health care card was considered to be a community asset. If you wanted to go down to the hospital, you went over to your neighbor, you got his health care card and went down. It got you right in, you didn't have to pay anything except for 25 cents for a pill.

It screwed up medical records, but served their needs very well.

Okay, let's fast forward a little bit more. Without getting into the gory details, the algorithm for generating a valid credit card number is well known in the hacker community. That means I don't need to know your credit card number to steal your identity.

I can make a pretty good guess about it and have a very, very good chance that a random number that I generate with the appropriate check digits and what have you, will in fact be a valid credit card number and I'm not stealing your identity, I'm usurping it. Very simple.

Okay, we can even go further than that. Thirty percent of all of the service incidents into a call center are password resets. Any hacker can tell you that if you have a high volume channel like that, it's also a high volume channel for fraud.

What that means is it's real easy to go in, assert that you are whoever you want to be, get a password reset, sent right to you and then go on from there.

These types of situations, those are very real. That's just the state of the industry right now.

Now, moving onto a presentation, one of the suggested methods for this is what's called PKI, public key infrastructure. In English that means that what we are looking for is an electronically managed identity, hopefully with better security characteristics to counter the issues that I just spoke about.

So what do we want here? A sum total of a lot of work that I've done basically says that you are looking for a ubiquitous, common and portable and simple means to identify and authenticate health care participants.

Specifically, we want to have one credential, not an electronic key ring. That's just basic simplicity. This applies to not only patients but also to clinicians, nurses and any other participants, especially the under-served community in health care which is the IT administrators. I can hear their applause over the internet now.

The other thing is we want to have support for multiple health care settings and roles. My identity and my authentic identity could be used for my own benefit, for the benefit of a family member as a guarantor or if I was a clinician it could be used as a credential to render care for another patient so there's multiple ways that those credentials could be used.

We are looking for multi-lateral authentication and that's within an institution. If you go to any acute care institution or clinical practice, you will see multiple computer systems. The ability to go smoothly from one to another is extremely important to rendering health care. You don't want to put a roadblock in taking care of somebody, especially when they are sick.

Okay, we are looking for interoperability among health care organizations. Where I go to one physician who can refer me to a specialist who can send me to a hospital, when he can send me out for an MRI, I would just as soon not have to carry a wallet-full of identities around on that particular incident.

Also, this goes back to the issue of security, we want things to be very difficult to steal, impersonate or forge. So there's certain properties that have to be added to the mix here to get things done.

The other thing is, of course, you want the administrative infrastructure for the above. You can do any one of these things, but to do it as a harmonizeded whole, you need to have appropriate tooling and infrastructure to help the administrators establish and maintain identities, also reasonable operating costs.

Now, the cost is measured not only in dollars but in time and convenience and a few other things. People don't want to be inconvenienced so they don't want to have to pay a lot of money for this.

Also, rapid positive ROI. That really gets into the institutional case.

There are really no investment funds in health care today that especially, you know, you are looking at a one-year turn around on return on investment. If you can't show that an investment is, in fact, going to be at least break even at the end of the year, don't even ask them to spend the money because it just isn't available.

So there are some things that we have in hand that can help us resolve and start to meet these issues.

The first thing is that there's a, well, I'll use the word plethora of standards. If standards are so good, let's have several.

You start out with X-5-09 which is out of ITU, and that's currently widely available. That's the base certificate standard that's used in MKI for generating digital certificates and digital identities. It's widely implemented; however, it's insufficient for the health care setting.

In practice, it is in support of bi-lateral transactions. Everybody that's involved in health care knows that there's no such thing as a bi-lateral transaction. It's a regulated act, it's subject to laws and it's at least tri-lateral if not worse.

X-509-2000 came out which provided the ability to associate roles and attributes with people as well as their own identity. It's been published, it is unimplemented.

Now, when I used the term unimplemented it, I don't mean that there's been nobody trying it. I mean in terms of practical, commercial scale implementation, it just isn't there.

Last year, W-3-C which is the internet standards group published an XML digital signature capability so that's out there but it's also unimplemented on a commercial scale.

The latest buzz word is SAML, that is Security Assertion Mark-up Language. It's a published standard out of Oasis. There have been some draft implementations, but as a practical matter it is not implemented. All of these things are things that we could use.

They are currently not kept in harmony so as was illustrated by Brad a little while ago, we have this issue of choose your own standard.

In the health care arena, we have three standards that I could cite. There are others, but these are the key ones.

The first one is ISO 170790 which has been published. It's a health care PKI standard. It is based on X 509-2000. So essentially it has taken the health care needs, taken the more generic standard of X-509 and has applied that rationale to it.

I'm not going to say it's a perfect standard but it's out there. It's a great running start but it's unimplemented.

ASTM has ballotted and is now in final edit a certificate policy statement. It's based on X-509-95. And that's, again, it's in final edit, it has not been published.

ASTM has also published a long time ago a standard called E-17-62 which is for authentication and in particular it has an enumeration in there of health care rolls. Those rolls can be associated with certificate and can be used to say that when you, for example, digitally sign something, what it is that you are asserting. Are you asserting this signature as a patient, as a provider, as a translator, as a notary or any other variety of rolls that happen in the health care setting.

What else do we have? Well, we talked about digital signatures as a way to communicate your authenticity or bind it to a record and there's technical language underneath there so stop me if I have just become a gate but the thing is, digital signature technology is ubiquitously implemented.

Every technology platform that's out there has appropriate programming interfaces to use it. You can engage in message authentication or you can engage in authentication of pieces of data.

Now, within the signature, appropriate places exist to express the health care role that is designated in ASTM-E-1762. The problem is that the programming interfaces to value that role aren't implemented. There's a little problem there.

We need to talk to Microsoft and Sun and IBM and Verisign, RSA and help them get that in there.

Okay, we also have as part of a digital signature project that I've been associated with, use cases in the health care, at least patterns, not a complete set of use cases but good representive ones that include things like patient consent, message attachments, dictation and continuing medical records, continue medical education records. The draft of these has been okayed by some participanting STO's through ANSI-HSBI.

So we have, if you will, what I would consider to be almost more than enough critical mass to do the job, so what do we need?

First thing is harmonization. As mentioned, we have more standards than we need so what do we need to get put together? First of all, X-509-2000 and SAML are compatible at some level. X 509 static SAML is dynamic but the point is that I can use those two together in a harmonious way. There needs to be work done to describe how to do that in detail.

Then we need to start dealing with the health care standards. ISO 17090 and ASTM E-2212 needs to be harmonized. Specifically, we need to add health care rolls and attributes which are not covered in the ASTM standard. We need to provide a way to support one identity per user entity, not several, which is what 2212 calls for and we also need to get a regime for mutual trust among health care PKI's meaning that if I have like five PKI's at the credential that I have that maybe is issued by one of them, might be recognized by some sort of mutual agreement by the other PKI's and health care, if I'm trying to get well, and I'm going between people that have used different PKI's, this would be a real major issue.

We also need a standard for long term, non-repudiation. What does that mean? That means that if a medical record has been signed by a physician or a clinician of some sort, five years ago and their credential has expired-- maybe they died-- that the authenticity of that data still is there.

In other words, you cannot repudiate it retroactively just because your credential is expired. That is an area where standards work needs to be completed.

We also need to gain consensus among ANSI and non-ANSI SDO's. As I had mentioned earlier when I introduced myself, I'm involved with not only ASTM but also Dicom. That's an ANSI and a non-ANSI organization. Dicom is coming up with their own digital signature standard. Which, by the way, is not interoperable with anything that ASTM has done. This, I believe, is problematic.

What else do we need? Now we get down to the hard part-- enabling mechanisms.

Funding to encourage implementation. As I pointed out, the need for a fast ROI here and the lack of funding is, in fact, a barrier. I'm not talking about a government hand-out. I'm not talking about a magic wand. I am talking about some source of funding arising either from the private sector or government or some combination of both to get things going. You need investment capital.

The other thing is to reduce the risk. Some of the people that may be good participants in here are small niche companies. When you get into identity management, the risks that you have for this in terms of legal liability is quite high.

If you don't have a cap on that, some reasonable cap, who the heck wants to do that? I'm going to go out there and get sued and get put out of business the minute I have one mistake so there needs to be some work in there whether it's direct insurance or a liability cap in order to remove another barrier.

Then, of course, we need one, at least one PKI implementer. There seem to be more than we need right now, but PKI implementers that are active in the health care space, on a commercial wide scale, is maybe one. I'm not sure what their financial health is.

So we need to get a real implementer out there. We need to define a pilot test. There's certificate practice statements and then we have to get a variety of places, if you will, put together for demo projects. I'm suggesting that somewhere in the health information system or clinical information systems or modalities vendors, perhaps through HL-7 demo or the IHE demo or HIMSS or RSNA, that we might find an audience to get this kind of implementation going but first, of course, the funding and the risk mitigation need to be in place to even get there.

The last thing we are going to need is real implementations. That means that we have to start dealing with the real world cases of what are health care roles and attributes. When I sign something, what is it I am doing?

If I'm physician, I'm attesting to medical adequacy. If I'm a patient, I'm giving permission. If I'm a guarantor, I'm saying I'm going to pay. If I'm a translator, I'm just saying I went from Spanish to English. Okay?

The use of a signature in health care is not as simple as signing a check or a contract. We currently lack, really, fully lack that particular support.

Then we need to get the structure or network of trust among health care PKI's in place. You might think that is an early stage but you first need demonstrable practices to bring those PKI's into the forum so practically you can deal with mutual trust at a later point in the process.

So let's talk about next steps. If I were to say what's the punch list, what's the checklist of things that I would like to see happen, the first thing is that we need to find a mandate into the health care IT sector. That mandate can come from one or two sources. One of them, of course, being regulatory mandate, something that says you have got to have a digital credential of some sort to participate in the health care system.

I don't believe that the current mood of the, the political mood, allows for that, but again, that would be an enabling thing.

The second thing, of course, is an emerging killer ap(?). You know, the Lotus one, two, three of health care PKI. It would be a very nice thing to have but currently I haven't seen one so we have to grind on this a bit. I'm not saying that there are not good use cases, there are not the seeds for killer ap but currently it just hasn't come up.

We also need to deal with that funding issue, seed money, demo projects, something that gets it going because frankly I'm not seeing the money available, freely available and competing uses for that money are currently drying up.

We need to deal with the risk mitigation issue. We also have to deal with sufficient acceptance and implementation of the health care PKI standards. What does that amount to? That means that where there is just a cross-industry standard, we have to get a health care IT participant to take up that standard and apply health care requirements to it, if you will, profile it for use in health care and thin you will have something that's useful and then, of course, you wind you having to recruit the health care IT participants because you can have a grand scheme and unless, and the issue has been talking about earlier on the earlier panel, unless you have patience, they are enrolling and providers that are using those credentials, all you have is a very nice idea on paper.

So that's pretty much it. I think it's a status report of where we are at and I'm-- thank you and then we'll go to questions of the panel I guess.

MR. ABRAMS: Well, we now need to make that technical change from one person's computer to another person's computer.

And while I'm doing that, again, I'm Marty Abrams. I'm executive director of the Center for Information Policy Leadership at Hunton and Williams. We have actually done on authentication workshop this year that was a six month workshop-- actually it was 2002 and so was last year. Steven participated in sort of our program and what I want to talk about is actually much more fundamental.

It's the whole concept of acceptability. I would like to actually have folks-- I'd like before we get into the actual presentation, have folks, go over one point.

Authentication isn't asking who you are. It's also asking are you who you say you are and I think if it was just a matter of requesting who you are, it would be much simpler. The fact is that you have to have confidence that you are who you say you are is an incredibly important issue.

The second thing is I would like to refer you to a television commercial and unfortunately I don't have a video tape player here and the commercial but there is a commercial done by Computer Associates and in that computer we have, in the business setting a question of authentication and authorization and we have this poor guy who has gone through all the steps and he gets to the part where they have to do the DNA reading off his hair and he is looking over his body trying to find another follicle of hair to insert into his computer in some form or fashion to have that read and a woman walks in the room who has no hair on her head so obviously, she has gone through the authentication process for that day and is in great shape.

The fact is that the world won't accept authentication that requires us to give up our bodily parts to that extent in order to be authenticated or anything of that sort.

I think it gives you a sense of where people's impressions are about this whole process of authentication.

The other thing I want to say before we get started is, this isn't a health care problem. This is a societal problem and where we might have some difference of opinion is you can't solve it as a health care problem. You need to solve it as a society problem.

The third thing I want to say is I will use a lot less technical language than my colleagues because I'm here to talk about consumer expectation and consumer policy, not what are the technologies to solve the problem. I will leave that to my colleagues on the panel because it's really not about technologies. It's about people and people is the problem, not technologies.

And I would really like to refer people to my first slide because my first slide really tells the whole story and you can walk out of the room after you see the first slide because everything else is just a commentary on that first slide and for those who are not from California, this is a slide of techtonic plates sliding against each other and really the whole transition from an industrial-based society to an information-based society is about these techtonic plates that are grating against each other, periodically releasing energy and on one side is this sort of, this drive by society to use information to solve all problems and in that we set a goal which says authentication must reduce security risk in all cases without ever having a failure so there is never a case where someone says they are Joe and they really are Sam. We never have that issue.

But then from a consumer perspective, authentication must be incredibly easy, take to effort, does not require me to remember anything. In other words, my memory doesn't get to come into play in an authentication system and not be dependent on me actually remembering to bring my token with me so any systems for authentication that requires me to really participate in a focused fashion as a consumer doesn't work and, oh, by the way, I still want it to never have a failure way, to always work, always authenticate you with ease, not take a lot of time in doing so.

And when we think about this whole problem, we need to think in terms of the concept of trust because every organization that tries to authenticate an individual needs to be in a trusted relationship and the authentication process should not reduce that trust and in the digital world, trust a very simple. It equals VSP and trust is, of course, the fact that people trust us but the first component is value, in other words all the processes create value for me.

Security is that systems are secure and P is, which is privacy, is the appropriate use of information.

Let's start with value as we think about authentication. That means the authentication processes for me, the individual, the consumer, the patient, are simple, are easy for me, never stress me out, in other words, you are not asking me questions I can't member the answers to, don't add significantly to the cost of the transaction because I want to pay for the transaction, not for the cost of doing the transaction.

Do consumers want to pay you extra to authenticate them? I didn't think so, and absolutely never fail. In other words, at the end of the day, everything works just the way it's supposed to. It's like a toaster. I put the bread in, it comes out, never fails, and easy to use.

Let's look at security and security is I will never be harmed by a security failure. In other words, that from a consumer when authentication process that makes sure that there is never any inappropriate access. In other words, that the system is so certain that when I come in, I will be authenticated but nobody will be able to spoof who I am and when we see that there's a failure in that, it's something like identity theft, where people are spoofing who I am, stealing my identity.

We also want to make sure there are no inappropriate changes. In the world of identity theft, the big cost identity theft is it changes my history. It changes who I am. In a medical setting, if we have a failure in authentication and we have the wrong person being authenticated, the cost isn't just the financial cost, the cost will be the change in my medical history which will then screw up my life for the rest of that life.

We can't have someone who is, for example, allergic to penicillin getting penicillin because of a screw up in systems that authenticate them and link data together. And privacy is that authentication systems, we use data collected from the authentication process only for appropriate purposes. What that means is that authentication systems can't use further use of the data for money to ameliorate the costs of an authentication system.

So in other words, an authentication system needs to pay for on authentication system. You have to have the resources in place to do that.

So what does that mean? Individual expectations make authentication almost impossible. In other words, if you are really thinking about authentication, it's an almost an impossible process and technology doesn't solve the problems. Money and people solve the problems. We have to have norms around processes that people will accept.

And the key failure point is enrollment. And that's really where the plates rub against each other and we've all gone through multiple enrollments in our life and systems that need to authenticate us. For example, we all have a driver's license and remember what we had to do to enroll in that process. We all have bank accounts and we know what we had to do to enroll in those processes.

And the best systems rely on linking and identity with a history. The best authentication systems are probably in the United States are when you get security clearance with the US government. You have the FBI come in and spend multiple weeks establishing you are who you say you are by linking you back through history to show that there's been nothing where the chain has been broken.

When I was an officer at the federal reserve system, I went through a two-week process where I was authenticated by the FBI. I think there's been linkage in my history since I was a federal reserve employee and that's a great system.

Instead, we rely on combinations of what you are, what you have and what you know and they are all dependent, of course, on the prior enrollments so what you are depends on previous linkage between a biometric and an identity the simplest biometric is the picture on my driver's license. It looks like me, it must be me, but it's dependent on the fact then that when I first was enrolled in a driver's license system, that they got it right and that this picture isn't really a picture of my colleague, Lisa Soto, but it's really a picture of me so that that linkage works.

So no biometric works if the original enrollment wasn't done correctly.

What you have depends on the previous enrollment. So you are saying ah, you have a driver's license from the state of Texas, let me see that driver's licence. Well, that's only as good as the enrollment that was done by the state of Texas.

In the state of Georgia to get a driver's license, you have to go to the driver's license department with a birth certificate that says you are who you say you are and that you were born and it has a seal.

Now, to get a birth certificate with a seal in most states in the United States, you just write them a letter. To have one with a seal you assert that you are who you say you are so if you are not, so if you are willing to lie, I can get a birth certificate on almost anyone in the room, take that birth certificate to the driver's license bureau in Georgia and get a driver's license with a biometric, my picture.

Again, you see the problem, if it's something you have, you are depending on the enrollment that was done by people in the past and what you know requires access to broad, deep data bases on the part of the organization that's doing the authentication and depends on the good memory of the consumer.

If you look at most of the authentication systems online, they ask you a series of questions. Some of the questions are questions you can answer by opening your wallet. Some of the questions are questions that you answer based on your history that's seen in usually a credit reporting system and that supposedly someone who isn't you would know.

Well, the fact is that I write the mortgage check in my family so I can tell you when they ask, which of these ranges matches your mortgage amount, I could tell you that. My wife couldn't get authenticated because she never writes the mortgage check.

When we were working at TRW where I used to work on an authentication system, we tested some questions where the guessers got the answer right more often than the individual. For example, which of these retail cards did you open in a particular year, so depending on the good memory of the consumer is an incredibly difficult thing to do so what we found is that we are one, dependent on a biometric that had to be based on an earlier enrollment or, two, we are dependent on an enrollment certificate from a previous enrollment and we have no idea how good that was or we are requiring the consumer to remember things that we have now established they can't remember.

And the problems after enrollment really go into area of verification and I won't get into revocation because from a consumer perspective, that's not typically a problem. Verification after enrollment requires people to, one, remember their passwords. Now, how many people here have multiple passwords? How many people go to a site and can't remember which password matches that particular site? Gotcha.

Anybody who is over the age of 52-- and I'm 52, finds themselves increasingly having a problem with remembering which password goes with which site.

When I used to talk to my colleagues at TRW who had done information security, they said all the information security standards including these concepts of passwords were developed in an environment where the general orders the private to do something. He orders the to remember the password. It works real well in a military setting. It doesn't work as well in a health care setting. It doesn't work as well in a commercial setting.

The second thing is that if we are using a token only system, we are requiring consumers to never lose their tokens. It's not a token, but it's incredibly valuable to me. It's my Blackberry. Somewhere in Italy, there's an Alitalia flight that's flying around with a Blackberry that was mine so people absolutely lose their tokens so we have to have a system that deals with the fact that people lose their tokens.

We also have to have standards on where tokens fit and we'll get into that in a minute and that's the whole concept of tokens have to work at all points of contact.

A few years ago as a presentation out in Redmond, and the chairman, Mr.Gates, came on, they built him a door and they had a PC and he was showing he uses the same key to go in the door and to get onto his computer, solving the authentication problem.

I went back, picked up my laptop and looked at where I was supposeded to insert the key in my laptop and, last I checked, there was no place to insert that key so these tokens, even if we don't lose them, we are depending on them being workable in every setting. Online, in person, over the phone.

And cost is an issue. I can tell you absolutely that consumers aren't willing to pay for the authentication systems so if I want to get my test results from my doctor's office and my doctor says enrolling you in an authentication system to that you can pick up-- no, it won't work.

I'm not going to pay extra for the authentication system.

We also know that health care providers-- are there any in the room? The health care providers these days are incredibly frugal so that they don't want to pay for the authentication system. We also know that the states are all in deficit and most of them in violation of their state constitutions and the feds are in deficit as well so nobody really wants to pay for an easy to use, simple, authentication system and we also know that proxy solutions aren't the answer.

One of the reasons that we've had the groth in identity theft is we've used authorization devices, things like credit cardss and driver's licenses as proof of who you are so that if you have a credit card that says, it has your name on it, then you obviously are you.

The credit card is an authorization token. It is not an authentication token so we've used other things as a proxy for authentication tokens and that's been a problem and it has led to the groth in identity theft.

So the solutions, I believe, are the following.

First, let's acknowledge the scope of the problem. It's a problem, it's not a health care problem, it's a societal problem. We need to solve it, we need to solve it in a way that people will buy into; we need to solve it in a way that the costs are shared. We need to solve it in a way that the tokens we create are proportional to the need, for the level of confidence we have to have in the identity so we have to acknowledge that it's the nature of the problem. It's not simple, that nobody else has answered it very well, and that we need to be involved in a group solution.

We need to determine how much confidence we actually need for the types of transactions we do in the health care environment. How confident do we need to know that this gentleman is who he says he is and we have to, say, rank order that confidence like we do everything else in the security world.

We need in a world where we are going to move toward federated authentication systems or identity systems, we need to begin to score the tokens and the authentication that has been done so that we can then compare the level of confidence that goes along with the token with the level of risk related to a transaction so that if a person is trying to buy a newspaper at the gift shop in the hospital, the level of authentication is different than if they are trying to get the results of their cancer test or they are trying to get the results of their child's cancer test so each of those has to have a level of confidence that's required and we need the layer of security. We can't depend just on systems of authentication to have secure systems and to begin to have those layers work together and if you have any questions, my number and web site are there.

Thank you very much.

Agenda Item: Questions and Discussion

DR. LUMPKIN: Thank you. Members of the panel. I have to be very authentic about this. This was an interesting experience but in my role as the chairperson, I get to move onto questions.

DR. STEIN: John, first I would like to thank at least all the panel but I in particular I would like to thank Brad Keller. I don't know if the members of the Workgroup were aware. We ran into a problem with the banking representative and we mobilized the banking community approximately two weeks ago and found out Brad agreed to do this talk so he put it together very quickly and I really appreciate both Brad's efforts and the efforts of the banking community in providing us with a speaker on very short notice. Thank you.

DR. LUMPKIN: Not to mention the fact that we did discover that the method of authentication between banking and health care don't jibe very well and neither do their computers.

DR. STEIN: Now, to a question and it's really a question, starting with Marty but going through Brad who I think in banking may experience some of the similar problems, then to our health care people.

We have an interesting situation in health care when people don't want to be who they want to be and how do you picture authentication systems handling that?

Marty, you were very specific on this and I'm sure, Brad, there's some cases when people go to the bank and they don't want to be what they want to be to get accounts, etc.

MR. ABRAMS: I think, I'm, over the last three weeks, this whole concept-- over the last few weeks, I've spent a lot of time thinking about this question of confidence levels, what level of confidence level do you need for a specific type of transaction and then how do you score authentication systems to give you a confidence level and if you were to talk with the consumer folks in the Center for Democracy and Technology, it is doing a paper at the moment that's establishing privacy principles for authentication and in that environment they are trying to say that there needs to be proportionality and we absolutely have to determine what type of transactions in a health care environment are so low risk that we let people do them, partake in them, participate in them in a fashion where they are anonymous.

In other cases we have to-- there may be other things that we just can't afford to let them do that. For example, maybe we say that for a pregnancy test you can do that anonymously, you don't have to authenticate yourself. You can get the results based on a transaction key that goes along with that but if it's an AIDS test because we have societal interests in making sure we understand whose AIDS, we have a different level of confidence that relates to that.

DR. ZUBELDIA: It's the other way around. It's the AIDS tester that wants to be anonymous and the system won't let him.

DR. ABRAMS: I understand, but again, we have to be very honest about what the balance is and again, it is not my place to tell you where the balance is but we have to say what is the societal balance, what is the organizational balance for the organization doing the test and what is the personal balance and work those together in the privacy-- this is privacy. It's not security but the ranking of what you can do and how you can do it is more of a privacy issue and we can have a debate on that, but that's not our purpose but the point-- I'm trying to answer Steve's question.

What I'm suggesting is that proportionality is all important in this equation, that you don't have to have the highest level of authentication and the highest level of honesty for every single transaction. There can be differences.

DR. LUMPKIN: Let me just sort of jump in here with a point of clarification. Just about every state in the nation has a methodology for doing anonymous testing for HIV where you can go into a site which obviates the issue because if you want to go someplace, there is someplace to go. That doesn't necessarily exist with psychiatric care and other kinds of things but it doesn't--

MR. ABRAMS: This is not my specialty. The example was just trying to take two types of transactions, saying you can have a different level of confidence required for the two.

DR. LUMPKIN: You just happened to pick the one that was the most sensitive.

MR. ABRAMS: My apologies, sir.

MR. KELLER: Steve, as far as the bank industry is concerned, we have, I guess, the biggest difference is if you want to transact business with us, we have regulations that say you can't be anonymous. We have things like the Patriot Act and other regulations that say, you know, it's our duty now and we have our own special burdens and actually I'm very glad we don't have many of the burdens that you have after becoming very familiar with HIPAA, I'm sort of glad that it's you and not me, I have to say, in identifying everybody that moves through our system because we have obligations to report certain things.

I think we do have a similar situation where we have people what want to come in and do things on behalf of others where you have situations where people want to gain access to minors' records, we have situations, in fact, that I dealt with just last week where someone needs to take care now of their elderly parents and they need to be able to establish banking relationships in their name to manage their money and how do I make that happen and know that they are authorized to do that and which accounts they get to see and what they get to do with them becomes very complicated for me and it's very similar, I think, to what you were dealing with, how do I, as a parent, if I want access to my son's records and what do I want to do with them so I think in that way, we do have some similarities.

MR. ABRAMS: In the payments mechanism we do have a way of being anonymous and that's cash. That's part of our payment system and again, this is a matter of national norms.

In the United States we accept the fact that you can't do banking without record keeping and record keeping that is available to agencies of government and others. In the European union, the norms are slightly different and they have been fighting over those norms so that there is no absolutes in this area.

DR. LUMPKIN: As my brother used to say, you can go to the bank on that one.

MR. FITZGERALD: I would like to ask Peter a question. Peter, you started off by saying that the governments of Sweden and the Netherlands have stopped their investment in the national health information infrastructure. Now, some of that is intellectual capital and education and that doesn't go away. That doesn't mean it's a failed investment but can you elaborate on what did they stop and then now what should they do to meet their goals of promoting rapid exchange of patient care data, improve quality of care and reduce the cost of care. Do they go no place?

MR. WAEGEMANN: The part in Sweden, two different cases. In Sweden, they had three. From a country of Sweden, an organization of 200 people, full time employees, working on a national information infrastructure and doing that for years until they found, similar as the UK did, about two years ago, that all the work they had done -- models, structure models, technology model, issue models, are outdated. It doesn't really fit.

When the folks in the Netherlands started out just getting the money, getting their full time employees and getting to a point where they started working on the information infrastructure, they found the same, that they needed to reorganize to have abstract goals like the six I have outlined in the beginning of the paper you have in front of you.

If you, for instance, look at, from my point of view, at the national health information infrastructure, continuity of care, interoperability, when we are just drilling down what this really means and, then we are getting somewhere.

What is needed to have continuity of care if a patient can go from any doctor to another clinc to another hospital and for the information, at least some of the basic information is there. We have ASTM are currently working on some of these standards.

Now, these are some of the key issues. The moment you get into an overall structure and you say, what is the public health relationship, it changes so much as we are moving along at least first countries have found that they discontinue.

MR. FITZGERALD: What should they do?

MR. WAEGEMANN: So what they have been doing is re-directing it. They are right now trying to figure out what to do.

DR. LUMPKIN: Let me see if you understand. Both those countries, do they have centralized health delivery systems or are they a private sector--

MR. WAEGGEMAN: Centralized.

DR. LUMPKIN: Because I think it's important to notice that one of the advantages, as much as I hate to say this about our cottage industry system that we have in this country is that success is built on successes so that no one starts off saying point A, we are going to build a whole system and I think we have certain advantages that we can use to leverage successful experiments on computerized patient order entry system and where we run into trouble is like we've had some e-mail recently about that hospital in New York that ran into trouble is maybe they didn't build off the successes of other systems, they wanted to go alone. So I think we need to look at those countries, take the lessons that we can learn but recognize that we do have a totally different system and that there are sometimes some strengths we can use to build onto make the advances.

MR. WAEGGEMAN: Just one quick example. Germany focused on its information infrastructure, on PKI. They made for health care allow for PKI, they said this is to be implemented and go anywhere. They said years ago,that every doctor should have a computer and a card reader, or a smart reader for a smart card: Totally wrong technology. It didn't work, it was a total waste of money.

MR. MARSHALL: I think that Peter has made a good point here that there have been very good projects done that were technically adequate at the time they were done; however, they were done too slowly because they were underfunded and the follow-up project what is moving forward the lessons learned into the next range of technology has not been funded. There has been an assumption that just because you can do it on a small scale, it's a very easy leap to a large scale.

Now, most of us that have been involved in that scaling problem know that's false. However, the people that are supplying the funds haven't quite figured that out yet so I would suggest that the failure that Peter spoke about is ultimately one of failure to fund and to staff in a timely manner to get the work done.

MR. ABRAMS: I just want to add, as you are looking for the technologies, the technologies that look the most efficient often have huge cost issues related to them.

In a very practical sense, there was a credit reporting company that wanted to provide consumers a copy of their consumer report, an $8.50 product, and required them to have a digital certificate, a $50 product. So before you could get the $8 product you had to buy the $50 product.

You need to think as you think about technologies like PKI, which are really beautiful technologies, you have to think about the real cost implications. We are not willing to pay $50 for the authentication for the $9 product.

DR. HUNGATE: A question. Peter in your comment, you said the providers don't trust the input from the patient. I would say the patients are increasingly reluctant to always accept the input from providers. There's growing distrust on both parts.

With that as a background, to what extent is the Netherlands situation, the Swedish situation, a result of a dependency on a legacy approach as opposed to an internet-based approach. Is the evolution of the internet likely to change the kind of technological solutions that are possible.

I have the sense that in many of these cases, the deliberative process of reaching a decision is longer than the technological product life cycle and so the condition through the technology to be adopted have a difference. I wondered----

MR. WAEGGEMAN: When you look at this countries, there are two issues. One is a cultural issue. Clem McDonald and I were just last week in Hong Kong where the consumer or the patient is still willing to wait three to four hours in a clinic to be seen for three minutes and then to wait an additional three hours to get their paperwork.

So it's a cultural issue of what, where if a consumer comes in and this second one is really the technology issue. When you look at the Scandinavian countries where you have the highest level of internet usage and so on, people are much more into personal health records, are much more into technologies and they have much more success in implementing them.

So yes, there is a relationship.

DR. BLAIR: First of all, I want to congratulate all of our panelists. I've learned a great deal from all of you but I am going to try to see if I could solicit a little bit more information from both Glen and Peter on directions for NCVHS.

Glen, you really did an excellent job in laying out some of the problems and it echoed some of the problems Peter had said and all of you have wound up indicating the struggles to come forth with, effective ways of doing authentication, but I guess I would like to, well, let me broaden it to all of you.

If there's one thing that would be a constructive direction or recommendation for the NCVHS, with respect to the topic of authentication, could each of you tell us what you would like to see us do, what direction you would like to see us go in.

MR. KELLER: Oh, you know, if I knew what that one thing was, I would be writing a book right now. I don't know that I would be sitting in a hearing. But I have to say don't look for a silver bullet, don't look for a killer ap. It was the one very expensive lesson that we learned in banking. It doesn't exist.

You are going to find that you will have different solutions or because you are going to find that the authentication problem, being a process, and being a component to a process is going to have a different resolution in different places so don't look for a killer ap that solves your authentication problem but look for what applications can live together with a set of standards that you and the public can deal with and that's a focus to drive toward.

MR. ABRAMS: What I would do-- I think there are two things you need to think about. One is the concept of federated identity management, meaning that there are multiple parties that are in the process of authenticating an individual. Sometimes it's the employers, sometimes it's the lenders, it can be multiple parties and then having metrics related to the identity that they have created a credential around.

So that you can say that in this world, that I can accept the identity created by, that's managed by Sun Trust, that has a confidence level of 234 and I understand what that means so I think we need to think in terms of federated identity and think in terms of metrics around that.

DR. BLAIR: One thing I did forgot -- I should have said this at the very beginning, for the audience on the internet and for anybody in this room that is not aware, Peter Waegemann is my employer and I work for the Medical Records Institute so continue on with your answer please.

MR. ABRAMS: Well, I've given my answer and it's now Glen's turn.

MR. MARSHALL: I'm going to go out on a limb. When I mention the need for a killer ap or regulatory action, I would have to agree that a killer ap is not really on the horizon so let's talk about regulatory action. I'll give you a very simple one.

When the regulations or attachments are published require the attachment data to be digitally signed by the clinician, that gets the ball rolling. I'm not solving the problem when I say that of ubiquitously identifying patients.

I am talking about introducing the technology for good authentication into the health care sphere in a way that is meaningful and it is doable. If you focus on the clinicians, that would be the physician or the registered nurse or other people that actually render care. That's a great place to start.

You have the people where you can create that value proposition that Marty spoke about. So start with the attachments. I know that it's a forthcoming rule or proposed rule so a great place to start.

MR. WAEGGEMAN: I think when we look at authentication we need to say what for. If we start out with authentication in the general health care field, I think we really have to accept that as far as I see it politically, a national identifier is not going to come, but what one could recommend and what I really would say what should be mandated is that every clinic does the same as what you have when you go to an airline.

They clean up their master person index, is they ask for a government issued picture ID. So in fact, we don't have hospitals like Los Angeles County Hospital where they have 20,000Jose Gonzalez and couldn't figure out who was who. So there are ways of doing that without looking at the probably not likely implementable issues like PKI.

So my advice would be not to spend too much time on that. If you ask me, the sexiest solution right now for authentication is to have asignature on a secure PDA kind of system which is bound to a document which is identified with a fingerprint thatvisits Dr. X's that fits one way which can be done for one-tenth to one-fiftieth of a cost of a very complexPKI system.

New solutions are coming out. Let the market drive it. Don't wait, from an information infrastructure point of view, some ideas of some very complex systems which may or may not work.

DR. LUMPKIN: Okay, Kepa, the last question.

DR. SUBELDIA: I'm trying to take this back to the personal health record. Who am I? Is there -- well, I know who I am.

DR. LUMPKIN: Yea, but we've been having some doubts about you all day.

DR. ZUBELDIA: I know who I am but how do you define yourself. When I go to the deli, I get a number from a number dispenser, right? And that's all they care about me, that I have their number. If I go take my shoes fixed, the shoe company gives me a little receipt that has a number.

I can sometimes get them back without the token and if they can find them, I'll get them back and that's okay. He knows me. He doesn't need the token and if the shoes fit, that's a good sign but for the personal health record, how do I identify myself?

If I go to a doctor that knows me, no problem. He knows who Iam. If I go to a new specialist, what's my identity? Is there some sort of consensus? Is it my name and date of birth and Social Security number and address and telephone number? What is it?

MR. ABRAMS: That's the essential problem. We don't issue an national identifier at point of birth and require by law the person to keep that, the token related to that with them for the rest of their lives.

The fact is that it is a timely and costly process to establish who you are in a world where people want to go around stealing each other's identities or establish a new identity at some point in time.

I think, I mean, there are no answers to that question that don't have privacy baggage that is from here to eternity so again I think what we have to do is in those settings where you do have an interest in establishing your identity, we let you establish your identity and then we have metrics around it and then have others accept that identity that is established, for example, by Sun Trust or by Microsoft or by whomever. That's the concept of a federated identity system.

DR. LUMPKIN: We'll just go to brad and then Glen to let Peter back up.

MR. KELLER: It's possible to do some of the things that we do in the banking industry and that's to what extent can you rely on collateral sources.

For example, with a student loan, we don't necessarily go to great lengths to authenticate the student because when they come to us for a loan, they also have to be registered at the school so what's the likelihood that they are falsifying, that they want to take out this loan, that they are also registered at the school and the school has done something so if you have got a physician with a new patient, that they get some information from that patient, they also verify that that patient has insurance with a particular insurance provider where they would have had to have done something to enroll and participate in that insurance plan so have you got other collateral sources of identification that in and of themselves would be difficult to piece together as opposed to just what can an individual present to themselves autonomously and we will do that in the banking industry.

That all pooled together helped give us some satisfaction as opposed to everything coming just from one source, in this case, from the applicant.

MR. MARSHALL: As things stand right now, that's your problem. There is no ubiquitous solution. You have an absolute right to die anonymously. Or you can give up some of that right, give up some of the privacy that's associated with that and participate and bring whatever credentials are needed.

There is nobody out there that, as a universal help for that so it is still, it becomes the individual patient's problem until we have a more ubiquitous solution. I wish there was a better answer but that's what's the current state of affairs.

MR. WAEGGEMAN: Kepa, I don't understand where you are coming from. For personal health records, and I have five records out there, it's my real data, I probably have 20 or 30 out there where I just put them in, just a name, just to test because I know some of these companies are not safe and secure and there are people that I know personally in these personal health record systems and I know the first thing is they say what does Peter Waegemann have so I just put in a fictitious name.

What we have to realize is that for personal health record, there isn't a need to identify a person. It is my record and I have a choice of taking this to a provider or a pharmacy for the benefit of having continuity of care or for any other reasons of just managing it. But keep in mind we haven't talked here. We are a large groups in our population and I'm just thinking of talks I did to the mental health community. There are many people who say I very much disagree with the diagnosis put in my record two years ago. The only way out of it is to go to another clinic and say I don't know what it has been or what has been in the past to get a fair new approach for a new medic line.

So we have to realize we do not want to have everyone boxed into an identity and a fair lifetime record following them. We really must make sure whatever we do in information infrastructure that there is freedom for anonymous care, that there is freedom for not identifying one person in that record.

It's the same as banking. When I want to get $100 out of an ATM machine, they don't need to have a record there of the last 20 years if I wasn't late with payments ten years ago and denied credit 15 years ago or whatever. You only want to get the money at that point. It's relevant information from the care is what matters.

DR. SUBELDIA: Peter, if I create my own record, identify myself as Peter Waegemann, then this net work of trust that surrounds my identity that gives it validity doesn't exist.

MR. ABRAMS: If you assume somebody else's identity, you are harming not just yourself but that additional individual because you are creating data, you are creating history that then associates with the other person. Absolutely, that is a really nasty thing.

I hope what you were saying is you created a totally non-, an identity that couldn't link with anybody else so hopefully he hasn't screwed things up.

DR. SUBELDIA: This is fictitious.

MR. ABRAMS: Yes, but the point that was made is that we absolutely, every system has to have a way of you having transactions which are done anonymously, that we allow people to do anonymously and we have to decide which ones those are.

DR. LUMPKIN: I think we could go on this discussion for quite a bit. I will, with my public health hat say that there are probably only two events that are mandated by law to be covered and that is that when you are born, by law you have to have a birth certificate if you are born in this country and when you die, you do have to have a death certificate and everything else in between is the topic of further deliberations by this committee.

Our next hearing will be on the 18th of March in Atlanta and hopefully it will be warmer than it was last week.

I really would like to thank the panel. This has been a really good two days. This panel has been very helpful on thinking through a lot of the issues, sharing experience from a broad spectrum and thank you very much for coming.

And we'll see most of you on the, at the end of February at the full committee meeting. Thank you.

(Whereupon, the meeting was adjourned at 12:40 p.m.)

Transcript of the January 28, 2003 NCVHS Workgroup on National Health Information Infrastructure Hearings

National Committee on Vital and Health Statistics

National Health Information Infrastructure Workgroup

Hearing on Health and the National Information Infrastructure and the NHII Personal Health Dimension

January 28, 2003

Proceedings By:
CASET Associates
10201 Lee Highway, #160
Fairfax, Virginia 22030
(703) 352-0091

TABLE OF CONTENTS

P R O C E E D I N G S

Panel 5: Linking Individuals to Their Personal Health Information

Agenda Item: Panel 6: Authentication Issues

ASPE.hhs.gov

Transcript of the January 28, 2003 NCVHS Workgroup on National Health Information Infrastructure Hearings

National Committee on Vital and Health Statistics

National Health Information Infrastructure Workgroup

Hearing on Health and the National Information Infrastructure and the NHII Personal Health Dimension

January 28, 2003

Proceedings By: CASET Associates 10201 Lee Highway, #160 Fairfax, Virginia 22030 (703) 352-0091

TABLE OF CONTENTS

P R O C E E D I N G S

Panel 5: Linking Individuals to Their Personal Health Information

Agenda Item: Panel 6: Authentication Issues

Connect with Us

Proceedings By:
CASET Associates
10201 Lee Highway, #160
Fairfax, Virginia 22030
(703) 352-0091