[This Transcript is Unedited]
Hubert H. Humphrey Building
Room 705A
200 Independence
Avenue, S.W.
Washington, D.C. 20201
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.
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.
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 o