American Health Information Community

Confidentiality, Privacy, and Security Workgroup Meeting #2

September 29, 2006

**Disclaimer**

*The views expressed in written conference materials or publications and
by speakers and moderators at DHHS-sponsored conferences do not
necessarily reflect the official policies of the DHHS; nor does mention
of trade names, commercial practices, or organizations imply endorsement
by the U.S. Government.*

**[\>\> Paul Uhrig:]{.underline}**

Paul Uhrig, Privacy Officer, SureScripts.

**[\>\> Alison Rein:]{.underline}**

Alison Rein with the National Consumers League.

**[\>\> David McDaniel:]{.underline}**

David McDaniel with the Department of Veterans Affairs.

**[\>\> Flora Terrell Hamilton:]{.underline}**

Flora Terrell Hamilton, Family and Medical Counseling Service.

**[\>\> Steve Davis:]{.underline}**

Steve Davis with the Oklahoma Department of Mental Health and Substance
Abuse Services.

**[\>\> Peter Basch:]{.underline}**

Peter Basch, MedStar Health.

**[\>\> Paul Feldman:]{.underline}**

I'm Paul Feldman with Health Privacy Project.

**[\>\> Kirk Nahra:]{.underline}**

Kirk Nahra, Wiley Rein & Fielding in Washington.

**[\>\> John Loonsk:]{.underline}**

John Loonsk with the Office of the National Coordinator standing in for
Jodi Daniel, who has had a death in the family.

**[\>\> Jill Dennis:]{.underline}**

Jill Dennis with AHIMA.

**[\>\> Sue McAndrew:]{.underline}**

Sue McAndrew, Deputy Director for Health Information Policy in the
Office for Civil Rights.

**[\>\> Lee Partridge:]{.underline}**

Lee Partridge, National Partnership for Women and Families. I\'m sitting
in this morning for Deven McGraw.

**[\>\> Tom Wilder:]{.underline}**

Tom Wilder with America's Health Insurance Plans.

**[\>\>]{.underline}**

We\'d like this morning before we get started we have a brief addition
to our agenda if we could introduce Rob Kolodner who is the new interim
\--

**[\>\> Matt McCoy:]{.underline}**

You have Workgroup members on the phone, too, if you would like to give
them a second to introduce themselves. Sorry for the interruption.

\>\>

That\'s all right. We have a couple of Workgroup members, at least one
on the phone, if you could go ahead and introduce yourself, please.

**[\>\> John Houston:]{.underline}**

This is John Houston from the University of Pittsburgh Medical Center,
as well as member of the NCVHS.

**[\>\> Sam Jenkins:]{.underline}**

This is Sam Jenkins from the DOD\'s TRICARE Management Activity.

**[\>\> Lorraine Doo:]{.underline}**

And Lorraine Doo from Centers for Medicare & Medicaid Services, Office
of E-Health Standards & Services.

**[\>\>]{.underline}**

And you\'re here for Tony, right?

**[\>\> Lorraine Doo:]{.underline}**

Right.

**[\>\>]{.underline}**

Thank you.

**[\>\>]{.underline}**

Rob, please, kick us off this morning.

**[\>\> Rob Kolodner:]{.underline}**

Thank you very much. It\'s a pleasure to be here. And this is a
Workgroup that, as you know, is one that a number of the other
Workgroups have looked forward to because they\'ve been operating under
the assumption that the privacy security and confidentiality issues that
are raised will be handled by this cross-cutting Workgroup and will be
in place so that they can move forward. And although there are no easy
solutions, it is work that needs to be done and there\'s progress that
can be made.

In particular, for those who haven\'t heard Secretary Leavitt in terms
of how he thinks and moves us forward, he talks about the long-term
vision and the short-term actions and what we can take. And so it\'s
very important that he really does expect, and the other Workgroups
expect, timely actionable types of recommendations from this Workgroup
so that we can assure the success of the breakthroughs to move forward.

And I think it\'s important to be prepared to bring to the Community,
and I think the target is in December, the December 12 meeting that we
have, recommendations on identity proofing and using authentication that
are practical and actionable and can accelerate the realization of these
other Community breakthroughs. And recognize that technology is going to
evolve, that confidentiality, privacy, and security policies are going
to need to evolve and to change over time and to mature.

But there really needs to be a starting point that you identify as this
is where we can start, we can move something in place so we can move the
others forward. And so we\'re really committed to your success, we\'ll
provide the resources that you need in terms of staff and other things
to be able to get to that point of the recommendations and then to move
forward to the next steps. And we look forward very much to working with
you and to successful meeting. Successful first meeting today.

**[\>\>]{.underline}**

Thank you very much. All right. In the interest of keeping things moving
this morning, we\'d like to turn to our first presentation, which will
be a little bit of essentially a 101 on the issues we\'re going to be
addressing today to give people a sufficient background so that we can
all be at least on the same starting point as we move forward. Let me
turn it over to John.

**[\>\> John Loonsk:]{.underline}**

Thank you, and good morning, everyone. Each of the breakthrough projects
has identified some common needs and Rob talked about the needs to have
some practical and actionable recommendations from this group that can
address some of these needs.

Teased out from those were some very initial activities that need to
occur, usually at the start of almost any electronic activity. The first
one is about what we would call identity proofing. The descriptions I\'m
going to give were listed in the *Federal Register*, but identity
proofing is about providing sufficient information to correctly and
accurately verify and establish an identity to be used in the electronic
environment. So there\'s some practical examples of this. For everyday
processes such as getting a passport or a driver\'s license, one needs
to bring information to show, to establish an identity. I think it\'s
particularly topical in view of some of the pretexting discussions that
have been prominent in today\'s news that this is a very complicated
issue and a very important issue in terms of establishing identities for
access to information.

The other area that\'s been identified is around authentication. Now,
these are separate but linked processes, and so authentication is about
the process of reliably verifying an identity. So having an identity
that has been identified, identity proofed. Identifying, reliably
verifying that identity that\'s claimed or presented in the process of
getting access, authorized access to data resources or other network
services. One can think of this commonly as how does one log in to a
system, for example, and associate an identity with access to
appropriate resources that that identity should have access to?

So there are different technologies for these purposes and obviously
user name/password is one that\'s commonly used in a number of different
circumstances. There are activities that include tokens, that include
biometric capabilities, or other approaches to helping to make that
association between a claimed identity and a network identity in the
context of resource access.

There were in the *Federal Register* also a series of questions that
were put forth in the context of these discussions. And the intent of
the panel today is to have the presenters work through those questions,
address those questions as they relate to these two areas, identity
proofing and authentication.

Are there any questions about the areas as I\'ve laid them out?

**[\>\>]{.underline}**

Just one quick question, John. And it came up in things like the
electronic prescription drug pilot as well as some of the initial
discussions under \-- when we were doing the HIPAA security rule.

In terms of an electronic signature, is that just a subset of
authentication, or is that something that\'s in a different part of the
forest?

**[\>\> John Loonsk:]{.underline}**

I think it classically, that would be a different tree in the forest. An
activity that this group will probably need to work on in the future.
Having the idea of electronic signature is that having had an identity
proved, having someone be authenticated to a system, the work that they
do and the context for what data they may store or change or work with
on that system, how is it recorded, that that indeed was done by that
identity in the context of that authentication.

So there\'s a logical sequence to these. There are many other follow-on
activities that can be talked about, but in the context of trying to get
to practical and actionable recommendations, these two are prominent in
both from a logical sequence standpoint and from the standpoint of
teasing them out and focusing on them as not completely isolatable, but
significantly addressable in that context.

**[\>\>]{.underline}**

Will the issues of identity constancy and identity protection/theft come
under these domains as well?

**[\>\> John Loonsk]{.underline}**

Again, major issues, and identity theft would have a number of different
facets to it. For example, does it \-- I would assume that the facet of
is the identity proofing methodology adequate to bind \-- or to bind
that identity to help prevent identity theft? Absolutely. If you\'re
talking about the issues of what, from an identity theft standpoint,
what punitive measures should be taken \-- I mean, that\'s clearly out
of scope, so \-- there is overlap on some of these issues. Identity
proofing is an effort to minimize identity theft. Authentication is an
effort to ensure that on-line access to resources are not indeed used
improperly by different identities.

**[\>\>]{.underline}**

How about identity constancy? Were you getting more at the issue of
duplication, duplicative records, or am I missing your point?

**[\>\>]{.underline}**

What I was asking specifically was, once we get somebody\'s identity
proven for a system, can we either with those same techniques by either
an improved technique or by a better policy, reduce the probability of
inappropriate use of that identity or someone handing that identity to
somebody else? So once we prove it, that\'s certainly useful, but how do
we taken in the constancy, and what techniques do we use to maintain it?

**[\>\>]{.underline}**

I think that goes back to Sue\'s comment earlier. The usability of the
data, I think if we have on our agenda maybe not for this meeting but
for the future, to look at how do we use this data. It\'s great we can
authenticate the person, identity proof the person, but if we can\'t
really manage the use of the data once we\'ve identified the person to
maintain the integrity of the data, then we\'ve not really gone
anywhere.

**[\>\>]{.underline}**

There\'s clearly a spiraling number of issues that work out from these.
But there\'s a logic to starting here, I think, and there are corollary
issues about how do you match one identity on a network with another
identity of patient data on a network, for example, but you have to \--
I think tackle this from a building block standpoint and these are very
logical places to start.

**[\>\>]{.underline}**

Any other questions for John before we turn it over to the first panel.

**[\>\>]{.underline}**

Thank you. Could we ask our first group of panelists to come up to the
front table, please. And while folks are coming up, just wanted to
remind folks at the table and certainly everyone else listening in and
sitting in, that we are \-- that this Workgroup intends to provide
recommendations on certain topics that will help facilitate the
breakthrough use cases for the three Workgroups that you can see from
the agenda, each of the panels is organized to discuss the issues of
identity proofing and authentication for one of those breakthroughs. And
our first one is for \-- I\'m sorry, the secure messaging breakthrough,
which is part of the charge of the Chronic Care Workgroup of the AHIC.

I\'ll remind everybody as they\'re speaking, to make sure their
microphones are tilted toward where they\'re speaking. I gather we\'re
having a little trouble on the phone. A lot of the microphones are
pointed up.

If we could go ahead and start your first panel. We have ten minutes
allocated for each of the speakers. If each of you could, at your turn,
introduce yourself, state briefly who you are and who you work with, and
then turn to the substance of your testimony.

I believe we\'ll be starting with Dr. Alterman, are you going to start
first?

**[\>\>]{.underline}**

Excuse me. Before we begin, I wanted to give you a heads up you\'re
going to get reminders for time. And we appreciate the written testimony
that you provided and to the extent that you can continue to focus your
remarks on the issues at hand so that we have an ample time for
conversation and ask you questions and such. And we very much appreciate
your being here today. Thank you.

**[\>\> Peter Alterman:]{.underline}**

Good morning. Thank you for knowing that people have heard me speak
before so they got the timer on me.

\[laughter\]

I\'m Dr. Peter Alterman, Assistant Chief Information Officer for the
National Institutes of Health for Electronic Authentication. I am also
the current Chair of the U.S. Federal Public Key Infrastructure Policy
Authority, an interagency chartered by the Federal CIO Council. In this
role, I am responsible for drafting, modifying, and implementing
policies that control the public key infrastructure architecture of the
U.S. Government. All Federal agencies that issue digital certificates
are required by the Office of Management & Budget to cross-certify their
public key infrastructures with the policy authority or to buy their
digital certificates from a vendor who operates its PKI under the U.S.
Federal common policy framework overseen by the policy authority. I
don\'t get enough bribe offers.

Additionally I work closely with the E-Authentication Management Office
and I\'m responsible to them for reviewing and approving PKI credential
providers. My purpose in testifying to the AHIC Confidentiality,
Privacy, and Security Workgroup is to give you background information
about the policies, procedures, and guidelines being followed by the
U.S. Government, agencies and affiliated organizations.

The Federal Government has been working for years to develop standards,
procedures, and guidelines for implementing electronic identity
management services that can ensure trusted, secure transactions over
the Internet.

I would like to summarize briefly our experience for you in the hope
that our experiences will help you analyze, plan, and implement the
appropriate strategies for ensuring secure trusted transactions among
citizens, caregivers, allied services providers, and the Federal
Government.

There are many credentialed providers in the electronic identity world.
Every application that generates and issues a user ID/password pair is
historically, every electronic application has been its own credential
provider. If you log on to an Internet service provider at home, that
provider is a credential provider. If you log on to a network at the
office, that network is a credential provider. There are so many
credential providers of user IDs and passwords that many companies
market password software products. And we all complain about having too
many passwords to remember. And the older we get, the harder it is to
remember.

The foundation of the U.S. Government\'s e-authentication approach is
that software applications should not issue credentials. Rather, they
should trust and use existing credentials issued by other providers. It
has been the avowed goal of the U.S. Government to minimize the number
of user IDs and password or digital certificates, a user needs to
authenticate to U.S. Government applications and Websites. Imagine
walking around with only one or two credit cards in your pocket instead
of 15.

Rather than add to the glut of electronic identity credentials people
must manage, the U.S. Government has built \-- has built \-- an identity
authentication infrastructure that helps a software application
recognize and trust at a known level of assurance, or LOA, electronic
identity credentials issued by other entities.

In order for this to work, an application needs to know two things: How
assured it can be that the electronic credential is actually being used
by the person who it claims to be from. I heard that question. Generally
called the level of assurance. And second, what level of assurance of
identity does the application require in order to guarantee sufficient
privacy for and security of the information being passed and stored?

The procedure for satisfying these requirements begins with a
standardized risk assessment of the software application or business
process. The E-Authentication Management Office has a very good risk
assessment tool available for free on its Website, but several others
exist and/or are in general use.

In addition to identifying the risks your system or process is
vulnerable to, and the list might surprise you, this exercise will
identify the level of assurance of identity required by the software
application in order to ensure sufficient risk mitigation.

The National Institute of Standards and Technology's Special Publication
800-63 maps risk levels to particular technologies for ensuring the
required LOA. And in fact I\'ve provided in my written testimony a page
of reference in material for your use.

All Federal agencies that field the electronic applications on the
Internet are required to implement this process by the Office of
Management and Budget. That should be of interest to you.

Included in this list are the Drug Enforcement Administration controlled
substance ordering system, which allows for secure electronic
transmission of Schedule IV controlled substances, orders from
manufacturers and distributors to pharmacists. Indeed, DEA plans to
issue high-assurance digital certificates to every single, single
practitioner who prescribes controlled substances in the U.S.A.

These electronic identity credentials will be trusted by other Federal
agency applications online at a known level of assurance since the DEA
issues its digital certificates under policies and procedures that are
mapped and published by the Federal PKI Authority and which are
recognized internationally.

Both the E-Authentication Program Management Office and, frankly, PKI
policy have extensive procedures for determining the trustworthiness of
electronic identity credentials issued by a wide variety of credential
providers, government, commercial, and academic. For assertion-based
credentials such as user ID/password pairs, the authentication program
has a procedure called the credential assessment framework. I will talk
about some \-- that in the written materials.

At substantially higher levels of cryptographically-based credentials
are required. The Federal PKI Policy Authority has an extensive
assessment process called cross-certification that assesses the
trustworthiness and security of digital certificates issued by
providers.

In addition to a dozen Federal agencies, the State of Illinois; MIT;
Lincoln Lab; Wells Fargo Bank; CertiPath, the aerospace industry
international PKI bridge; and the European Telecommunications Standards
Institute have all mapped their policies and procedures against the
Federal PKI Policy Authority policies and procedures cross-certification
is currently underway with many other entities including SAFE, the
pharmaceutical industry PKI bridge that services almost two dozen PKIs
issuing digital certificates to thousands of staff.

Public key infrastructures that are cross certified with the U.S.
Federal PKI architecture issue digital certificates that may be trusted
by applications that require higher known levels of assurance of
identity.

The U.S. Government has developed and has implemented widely a
standardized method of identifying the risks that must be planned,
planned for and mitigated when designing and fielding online
applications providing services to citizens and businesses. We have
developed and implemented standards, policies, procedures, and an
architectural approach that stress trusting external electronic identity
credentials rather than adding to the current glut of user IDs passwords
and digital certificates. I should point out for your information, and
use, that the National Institute of Standards and Technology has
promulgated a Federal information processing standard which describes
required procedures for identity proofing for issuing high assurance
electronic identity credentials for Federal employees and contractors,
and this process is generally applicable for all sorts of electronic
identity credentials.

The U.S. Government has implemented a robust architecture for
identifying, evaluating, and validating electronic credentials issued by
a wide variety of providers using varying technologies at known levels
of assurance of identity, that are directly related to the risks of
operating electronic software applications on the Internet.

My colleagues and I stand ready to advise and support your efforts as we
can. Thank you very much.

**[\>\>]{.underline}**

We\'re going to save questions from the Workgroup to the end of the
panel. Mr. Jacobs.

**[\>\> Mark Jacobs:]{.underline}**

Great, thank you. Thanks for having me today. My name is Mark Jacobs
I\'m with WellSpan Health, the large care provider in south central
Pennsylvania, also involved in the Pennsylvania State regional health
initiatives up in Pennsylvania and also working with HIMSS, and trying
to help standardize some definitions.

One of the items that we face in large integrated delivery systems to
protect electronic health information is the \-- is that we are
investing in a myriad of security solutions. We are developing our own
vertical breakthroughs, you know, and solutions and this all adds
overhead to the electronic health record. Sometimes our security impedes
care. It\'s not uncommon to hear the words lockdown, restrict access.

The American Health Information Community could provide healthcare with
two things. Minimum and reconcilable standards that are interpretable
for identity management and user authentication. And also guidelines for
role-based identity management.

Now, some of my colleagues are skeptical that the industry can
standardize itself without Federal mandates. I\'m here to share with you
our challenges and report back optimistically that we are shifting, the
paradigm is shifting, and we\'re solving the problems together.

Case providers are making investments to acquire the electronic health
record and are faced with adding an additional layer for security. We
are adding tools for convenience, also. Our challenges will be to
safeguard the patient data beyond the door steps of the provider to the
patient. My testimony today will face four areas. Number one, challenges
providers face in identity management, providers' view of identity
management, experiences relevant to secure messaging, and a possible
vision for care providers who reasonably want to protect and share
digital health information.

The greatest challenge we face is volume. And a different of
classification of caregivers. WellSpan is doubling the amount of users
we are maintaining since 2003. Most of our care providers now want
electronic access. Identity management and authentication proofing gets
more challenging for non-credentialed physicians.

The activity is increasing with the revolving door of nurses, medical
students, and nursing students. And soon the patient.

Identifying clinicians who leave or no longer need access is also a
struggle. Timeliness is also a problem of access, versus security is
often a challenge. From a clinician\'s view, user authentication,
identity proofing is time consuming and sometimes confusing.

The electronic health record may represent several clinical
applications. WellSpan has begun a process of simplifying access for the
electronic health record by branding eCare as a name to provide access
to the clinicians. The only problem is that it doesn\'t help the process
go faster; it\'s just a name.

We envision an automated online-based identity proofing process that
uses proof of address, which is something like a unique number or a
license number.

In-person identity is still ideal. Online access should require
multilayer identity verification process. Vendors are focusing on
providing three-factor identification but it\'s so costly and
technically difficult to implement.

At WellSpan, two-factor authentication is seen to be reasonably
effective in accomplishing additional access then with online proofing
thereafter.

For remote users, we saw the banking industry\'s model, we give them a
PIN. It seems to be more acceptable than a token or biometric. Routinely
the count is verified and attested to when the password is reset. Any
credentialed physician can request access to our electronic health
record. Employed physicians are pre-authorized by our human resources
department. Difficulty again rises with the non-employee physicians. We
have developed an automated verification system against our
credentialing database which verifies the alphanumeric last four digits
of their physician number, and another criteria unique to the physician
as an individual.

Secure messaging is working in our offices. More than 200 physicians are
enrolled, allowing messaging through online forums. Patients tell us
it\'s a really good tool but the staff \-- the problems come more from
the staff. Patient enrollment occurs at check-in time, where the patient
signs a consent. The instructions, an ID and password are mailed to
their homes.

Once online, the patient can access the secure messaging through the
standard forms.

In use today are four templates for ask a billing question, ask a nurse
a question, ask for an appointment, and ask for prescription refill. The
most frequently is ask a nurse a question.

Secure messaging today is one of non-urgent nature. Patient sometimes
want to understand how security and \-- how secure messaging differs
from the e-mail. We find a universal definition of secure messaging for
patients would be beneficial.

From the practice view, secure messaging allows non-urgent messages a
way to be handled that doesn\'t detract from urgent ones. Patient can
communicate conveniently with the physician\'s office without having to
call by phone. Our experience has been that it appears to be patients
appear to be very open to signing the consent for access and not raise
the privacy issues we thought they would. Password expiration seems to
trick the patients from time to time but we look at that as a necessary
evil.

In the area of secure messaging and identity proofing, there may not be
a need for different levels of authentication, merely one that works.
The same scenario can apply for physicians, clinicians, or proxies.

The process would start at in-person for initial account setup and in a
recording of the two- or three-factor digital identity.

The level of access would be dependent upon the predefined role of the
user initiating the access. The digital identity could expire after a
routine time period and then be renewed in person.

A physician would require much more detailed information while a proxy
might require less. Therefore, the identity and authorization would be
the same. But their level of access would be determined by assigned
role.

The industry is pushing three-factor identification as we said, but this
could always be adapted to secure messaging but might be overload. It is
good to use encryption when doing secure messaging. There is reasonably
cost standards that can work. The key is to decide on one and move on.

Multiple-factor identification can be employed, a PIN might be
reasonable. As we debate the solution of security risks, our patients
and doctors are moving and acknowledging the risks in favor of
efficiency.

We possibly envision a WellSpan where a patient can authenticate with a
user name and password and then possibly authenticate against an MPI, or
possibly some day maybe even national registry.

The possibility \-- the policies governing the methods of identity
verification should be specific to the targeted industry. The military
may require greater authentication than a manufacturer of tires.
Healthcare needs a lending hand in acquiring their own reconcilable user
authentication and identity proofing that is not ambiguous.

Medical information may not be as viewed as tactical as military
information, however unauthorized release of the information could be
just as devastating to the individual.

WellSpan currently uses two modified two level authentication for
access, employee care givers have unique user name and passwords in a
number for access.

I\'m not certain how we\'ll finally agree on how the security be
(indiscernible) the electronic record, but we must agree it must be
secure.

Moving forward, we need to think along the lines of the principles for
minimum necessary access, and still applies since the physician is still
the gatekeeper. Thank you.

**[\>\> Michael Weiner:]{.underline}**

Go ahead, sir. Thank you. My name is Michael Weiner. I\'d like to thank
you for giving me this opportunity to speak about security of clinical
messaging, Regenstrief Institute and the Indiana University Center for
Aging Research in Indianapolis. I conduct research in medical
informatics and geriatric medicine. I conducted studies of security of
communications between patients and their clinicians, including methods
of video conferencing, computers, fax machines, and telephones.

As a physician, I use an electronic medical records system for primary
care and in an urban population and for communicating with my
colleagues. And as a patient I\'ve used the Internet to communicate with
my own physician.

I would first like to point out the problem of health data security
originated long before personal computers were invented. Paper perhaps
provides the least method of security or the least secure method. Paper
is often misplaced, lost, intercepted and read by unknown parties.
Computers have helped us and can increase efficiency and security.
Electronic clinical messaging has shown to decrease the number of office
visits needed in a primary care setting. A third to three-quarters of
our population access e-mail and most feel e-mail would be useful for
electronic communication in the healthcare setting. Up to 35 percent
have done so.

Secure clinical messaging requires identity proofing and user
authentication. Why are these separate? Part of the result \-- or part
of the separation is practical. Identity proofing provides an exhaustive
review of credentials, whereas user authentication is meant and needed
for rapid access, easy access, and ongoing access to assist them.

Americans face multiple difficulties with secure clinical messaging.
With the increase in the size of our population, many physicians no
longer personally know all of their parents at the levels they used to.
Disabled patients have proxies but the proxies can be difficult to find
and identify, especially in a medical crisis.

And of course with a great number of disparate systems, remembering the
code is difficult, as we\'ve heard, and writing down codes can increase
the level of risk.

With electronic mail spoofing is common and easy and conventional common
electronic mail systems do not provide strong authentication.

Passwords are easily intercepted, as I was in my hotel room checking my
e-mail this morning on the wireless system, my password was being
transmitted through an open system unencrypted, that could be
intercepted by anyone with the right device.

And messages are stored on servers on the way to their destination. And
these servers are often readable by unknown parties.

What\'s needed for accurate identity proofing is, well, if we had a DNA
stamp at birth and one at the time of the proofing, that might be
perfect. The addition of credentials improves the specificity of
proofing and in-person proofing can provide an added benefit of
inconvenience and increase time that can improve our level of
confidence. One reason I\'m here today in person instead of talking with
you by telephone is to increase your level of confidence in knowing who
I am.

Without this, there\'s greater opportunity to misuse automation, and to
match multiple credentials to one person.

With in-person proofing the issue can be not whether it\'s done but how
and when. There is a difference between clinicians and patients.
Healthcare occurs one conversation at a time. For the patient, the
proofing can be accomplished directly, with the physician in the
examination room. The physician sees the patient and by definition the
person in the room is \-- and the person authorized to conduct business
with that physician.

Again, the hotel example, as I was checking out, I went on to the
computer screen in the room, and checked out using the system,
electronic system. I wasn\'t asked for a user name and password because
I was by definition, as the person in the room, the person who was
qualified to check out of that hotel room.

For clinicians this is different, and proofing requires some affiliation
within accredited institution. So institutions that provide secure
clinical messaging should be subject to standards that are \-- provide
minimum levels of security.

The same goes for user authentication. User authentication should
require only a maximum of a few seconds because of the frequency which
with this is needed in a healthcare setting. Changing passwords can help
but leads to inconvenience.

One solution is this secure ID token I\'m holding up, and it issues a
time-dependent different password every 60 seconds. I use that to access
my system in conjunction with a host name and a user name, and other
pieces of information that you wouldn\'t have if you just had this
token.

The company that makes this claims 15 years success with not a single
breach of security. But this is relatively expensive, and it\'s subject
to loss and theft.

It\'s probably more useful for clinicians than it is for patients.
Biometrics, as we discussed, provide an additional alternative, and this
generates authentication through a person-specific feature. It\'s fast,
it\'s accurate, reasonably accurate. And it\'s a viable option, mainly
in a monitored setting. But in the setting where the authenticating
machines are not monitored, this is probably not viable because it
increases risk.

We need a balance of access and privacy. Physicians need data.
Evidence-based medical practice requires a physician not just to have
knowledge of the field but to have all the information about a patient
who is receiving care.

And yet patients should control access to who has their medical records.
But this might mean granting access in advance to unknown people, such
as in the event of a medical crisis.

In terms of authentication, we need to authenticate not just a recipient
but the sender and the message itself, and the public and private key
system helps us do this. It\'s difficult to break. The PGP Corporation
is one example of a place that has been providing such a service for
many years. And yet these public key systems are not always readily
available. They\'re not terribly easy to configure. They\'re
inconvenient, and so they\'re not widely used.

I was reading about how to set up a key system on my home network of
three computers, and the instructions were about five pages long. And
that seems a little bit unreasonable to be considered convenient.

Web mail provides us with a relatively good alternative. It provides
encryption from end to end. It\'s easy, people know how to do it. It
provides access control, it provides templates, customization, routing
of messages, and documentation of a conversation which is a critical
feature to healthcare. It\'s not perfect, it\'s at risk for keystroke
log-in from public terminals, but for non-urgent messages, Web messaging
is preferred to the telephone by both patients and clinicians.

The need for security is not limited to patients or physicians. And
storage requires strong encryption, limited physical access, and audit
trails, as we know about the government can help not by specifying a
method of security, but by specifying minimum levels of protection.

Standards are needed to transfer data. And I think that\'s one thing
where we can all agree even if we disagree on the exact methods of
security. I think we can also agree that decreasing the ability to
transfer data reliably, accurately, and efficiently jeopardizes health
and health care.

In summary, many methods of security are available, many of these are
difficult to implement, and are costly and specifically addressing cost
and ease of use will go a long way toward improving security in the
health environment.

There are three points to remember in addition to these. One, personal
harm from breach of security and clinical messaging is extremely rare.
And solutions must be consistent with realistic levels of harm. Our
personal banking systems have methods of security that are less secure,
frequently, and yet routinely are used to transfer large sums of money.

Second, increase \-- we must consider whether increasing security limits
access to care unreasonably. Eliminating the telephone, for example,
would place many patients at a disadvantage with no access.

And finally, we have to consider whether increasing security will hinder
the patient-physician relationship, which is an essential foundation of
healthcare. If we choose methods that our public doesn\'t want or need,
then we haven\'t really improved comfort, service, or health.

Thank you.

**[\>\>]{.underline}**

Thank you very much. We\'re going to start off with some questions and
we have a little bit of time for both questions and discussion among the
Workgroup. Let me start off with one question and touch on a point made
in the last presentation.

One of the challenges that we\'ve been presented with as a Workgroup is
to try and drill down to the particular breakthroughs that have come out
of the other Workgroups, rather than try to address the whole universe
of privacy and security. And we\'re talking with your panel about secure
messaging in particular. One of the points made with the last presenter
involved risks, and the risks of harm are very limited, and there
haven\'t been a lot of situations where there\'s been real harm.

Should we be focusing in the secure messaging context on the kinds of
information that\'s really exchanged during those messages? I\'d like to
hear a little from the panelists about what exactly goes on in the
secure messaging. It\'s not an electronic health record, personal health
record. I wonder whether we can be pushing towards something where maybe
we don\'t need as many hurdles just in that limited context because of
the nature of the information that\'s going back and forth in that
context.

**[\>\>]{.underline}**

Maybe I can respond first. I do agree with that. The physician, in a
healthcare setting the physician needs access to the data. But when
there\'s messaging between patients and physicians, it can help and
advance and specify what kind of information should be traveling back
and forth. There are a few published guidelines about how this should
occur. One was published in the *Journal of the American Medical
Informatics Association* several years ago and recommends that
physicians establish with their patients what kind of information are
acceptable, especially regarding the urgency and the potential for
misinterpreting the data. Not just the security of the data.

**[\>\>]{.underline}**

I think that\'s a reasonable thing to expect. And it could eventually
improve privacy.

**[\>\>]{.underline}**

One other question and we can open it up to other members of the
Workgroup. We talked a lot in each of the presentations about physician
access. And there was a focus on physicians particularly. One of the
later speakers is going to talk a lot about identity theft risks and is
going to point to some of the risks of insiders who are often not
necessarily the physicians but people who work in hospitals, people who
work in doctors' offices who are not the physicians themselves. What has
your experience been in terms who have actually has access to this
information in the secure messaging context? Is it really the individual
physician who has the treating relationship or are there others in the
office that have access to this information?

**[\>\>]{.underline}**

I\'ll talk about in the hospitals. Traditionally a lot of this
information was brought forward, you have to look at the history, years
ago we didn\'t have a lot of the systems. We had information was just
more apparent than it was before HIPAA. So a lot of these folks in
healthcare in the hospital setting, they grew up, it was not uncommon to
see the same password shared between five different people.

It was not \-- it was very, very common to see the same password used
between five nurses. So everybody looks for a convenience. And I believe
that a lot of this activity has come up through this rank and a lot of
people in healthcare, especially some of the nurses were there for a
long time.

So I think the experiences pretty much grew out of that, and it\'s been
an education to try to get them to focus on unique password and log-in.
I think the physicians are probably a little easier than some of the
ancillary staff.

**[\>\>]{.underline}**

There have been efforts to provide specific access rights to specific
roles in the hospital setting, and it can be done. It\'s tricky, it\'s
difficult, there\'s turnover of staff, there\'s new patients and new
access capabilities all the time. So it\'s just a difficult matter to
arrange.

**[\>\>]{.underline}**

Other questions from the Workgroup? And for the purposes of the
transcript, if people could identify themselves as they\'re asking a
question, that will be helpful. Alison?

**[\>\> Alison Rein:]{.underline}**

Alison from the National Consumers League. I think my question follows
on to the last set. And that is, you mention, I think it was Mark
Jacobs, that people are \-- they sign up, they enroll for the secure
messaging in the provider office, the provider setting, and then
they\'re sent a letter with their user name and password. My question is
does that user name and password only grant them access for secure
messaging, or are they also interfacing with the EHR, or PHR, system
that exists, and are the user name and password for those the same? I\'m
just trying to look at, you know, what is that used for?

**[\>\>]{.underline}**

When the patients get a letter sent to their home with a user name and
password, they could go on obviously our secure Website and get a PHR,
but again most of that PHR is for them to be able to record their own
information. Like I do right now on a piece of paper right here.

So I don\'t know if the relationship is shared with the physician, but I
think that that\'s going to occur over time. It\'s all about the
relationships here.

The other point that needs to be made is also the patients using the
site for education. So the patient is \-- you know, with the focus on
patients owning their own care and being involved in that care, patients
are coming up to that. There\'s a lot more smarter consumers now than
there used to be 10, 15 years ago. So I think it\'s going to take time
to get patients up to speed and there needs to be \-- we need a Dr. Koop
of the EHR \-- the PHR. The focus on that stuff. But there needs to be
some type of a big national focus on use of the PHR.

**[\>\> Peter Basch:]{.underline}**

Peter \-- also a question first for Mr. Jacobs. Dr. Kolodner asked us to
focus on practical actionable policies for identity proofing, and in
your testimony you had a statement about barriers voiced by staff. I
think this is something we may want to understand a little bit further
because while we want to advocate policies and encourage these
breakthroughs, we want we want to make sure we understand where the
barriers are and if they are unreasonable or if they could be met with
relatively simple conditions.

**[\>\>]{.underline}**

Well, most of the barriers really focus on change within the workflow of
the physician\'s office. And that\'s what I\'m finding out. I think
Michael can give us his perspective, but I think it\'s a very, very
difficult situation and the physician\'s office is in their daily flow
and staff are under tremendous pressures. There might be limited staff.
So I think the dilemma is, you know, it\'s a change. And once they adapt
that change, and I think it\'s our job as a provider with those offices,
to help educate them. So this is an education issue, too, and helping
them understand the benefits for the workflow.

**[\>\>]{.underline}**

Just so you\'re aware, I\'m a physician as well, and we use a secure
messaging system in our office I\'m familiar with the process. The
question is to that barrier and workflow issue. Are you addressing
secure messaging as it hits the office, or identity proofing of the
patient?

**[\>\>]{.underline}**

Well, secure messaging is a separate focus, and \-- within our
organization because it\'s trying to focus on that from the E-health
initiative within our organization, the identity management issue is
obviously a focus we\'re trying to solve some issues.

So biggest issue is the different aspects and different players coming
together and we\'ve begun a process in our organization, I call it an
identity access collaborative. That\'s similar to what the community is,
a lot of different folks within the organization and large integrated
delivery system coming together. From IT, I\'m not in the physician
office on a regular basis, but the physician staff obviously know a
little bit more than I do. So I think it\'s, again, I talk about the
focus on relationships and in terms of forming these collaboratives
within these organizations, or call it a collaborative within a RHIO, to
bring thought together to help solve some of these issues.

I don\'t know if that answered your question, but \-- no?

**[\>\>]{.underline}**

Is the barrier that either \-- or any of you gentlemen have seen, that
of creating the in-person proofing in I think that\'s one of the things
we\'re looking at in this panel. If one of the recommendations we\'re
going to put forward is in-person proofing is more reliable than an
online proofing, have you noticed a barrier from medical offices,
hospitals, to in-person proofing in not specifically using secure
messaging, but creating the first identity proofing in.

**[\>\>]{.underline}**

I say, proofing one time in one system; not too hard. And authenticating
one time is not too hard either. It\'s the repetition, it\'s the
multiple systems. If I work in ten hospitals, and 20 nursing homes, I
actually go to about 25 nursing homes in Indianapolis. They\'re all
different. How am I going to be proved in every one of those places? If
I have to authenticate in a system every 10 minutes, and is it going to
take a minute each time? If it is, that\'s a long time.

**[\>\>]{.underline}**

Department of Veterans Affairs.

**[\>\> John Houston:]{.underline}**

John Houston, could I get in the queue for a question at some point?

**[\>\>]{.underline}**

Why don\'t we have you go after David.

**[\>\> John Houston:]{.underline}**

**[G]{.underline}**reat.

**[\>\>]{.underline}**

If I\'m a senior citizen, and I am accessing a number of different
providers and I have gone in for my in-person for that one provider and
then another and another provider. I\'m \-- with Mr. Alterman, I have a
hard time keeping up with my passwords. What about keeping up with the
ability to be authenticated or be verified by multiple places, how would
you recommend a method of being able to make that something manageable
for elderly patients who are large consumers of our health care?

**[\>\>]{.underline}**

Dr. Alterman, at the beginning was really on to something saying that
the certifying authority, there could be some centralization of that,
and that\'s removed from the other processes that occur. And I think by
pursuing that approach it could make things easier without compromising
security. So I like that idea.

**[\>\>]{.underline}**

If I may just followup. What you see here is that it\'s very difficult
to take an identity from place to place to place. People authenticate
themselves to government agencies like the motor vehicle bureau. At
least once every three or four years. So unless you\'re either a
pediatrician or a gerontologist, you pretty much can see people in your
practice who have already been identity proofed with a credential at
least in common use, trusted for identity all the time. It\'s the
driver\'s license. It\'s the de facto identity credential that we use in
this country. Yes, it\'s not the most secure thing. Yes, if you live in
a college town, you know how easily they are \-- I have a daughter who I
worry about that way. Especially on Saturday nights when she\'s going in
to College Park. But the identity proofing should not be done in a
centralized place, for privacy reasons. There shouldn\'t be a single
registry of identity much, at least the consensus of political will in
the country at this time is that there not be a single registry of
identities. But there are at least 50 States that do this work, and
they\'re the motor vehicle administrations. The key strategy is to
leverage what\'s already in place. And the first level of identity
proofing in this country is the motor vehicle administration. Second
one, of course, is the passport authority. We should take these
opportunities to leverage what we can. And if someone comes in to your
organization with a valid driver\'s license, that should be a good
starting place for identity proofing. It\'s not guaranteed, it can be
spoofed. There are electronic issues. We all understand this. But the
principle of relying on credentials issued by others when you can just
trust the processes others use is what we should follow.

**[\>\>]{.underline}**

A follow-on question to that. How would you manage those people. I have
friends in New York City who pride themselves in having never gotten a
driver\'s license because they never needed one. What about those holes,
those geriatrics, pediatrics, and those people who don\'t have driver\'s
licenses? How would you authenticate those people because they aren\'t
going to those known sources that are secured sources?

**[\>\>]{.underline}**

Yeah. Well, first of all, everybody is somewhere. Right? If you have \--
if you have a pediatric practice, you have parents or guardians. You can
identity proof the parents or guardians at a sufficient level of
assurance, and then rely on their assertions for their children\'s
identity. That\'s a possibility. In the geriatric case there\'s an
equivalency. There are entities who are responsible for those people.
There are people who are responsible for everybody.

Work from that and cut down the uncovered. Cut down the 20 percent, the
10 percent, the 5 percent. What we can do in New York City we can say
you don\'t have a driver license you can\'t have medical care. Let\'s
have some fun.

\[laughter\]

Seriously, there are alternative identity credentials available. I would
suspect that many of the people that you know and I know in New York
City who don\'t have driver\'s licenses have passports. All right. What
you\'re looking for is an identity credential called a breeder document
in some cases issued by a governmental entity that has at least one
biometric. Usually a photograph. Some have two, they have a fingerprint.
That\'s different. Go with that.

There are many people in this State who don\'t have driver\'s license
and have State-issued identity credentials. You know, they\'re not
driver\'s licenses, they\'re identity credentials.

**[\>\>]{.underline}**

Along that same line, you know, up in Pennsylvania we had a lot of
discussion about this same concept, and you know, with some of the folks
on the county level and versus folks on the State level, and local
level, and you know, the concept came up, you know, in terms of some
type of a countywide registry, or some kind of a countywide identifier.
Somehow that could be handled on a more granular or localized level.

The biggest issue that we face in that area is that everything\'s local.
Healthcare is local, you know, geography is local. And the
administration, it might be better to administer that locally.

**[\>\> Paul Feldman:]{.underline}**

This is Paul Feldman. I wanted to just ask Dr. Alterman, so your use of
a driver\'s license was as an example of a single biometric like a
passport you could use for the example as well? Is that \-- with respect
to the Federal information processing standard, I\'m presuming that\'s
where that\'s referenced?

**[\>\>]{.underline}**

Yeah.

**[\>\>]{.underline}**

Okay.

**[\>\>]{.underline}**

Thanks.

**[\>\>]{.underline}**

Jeff on the phone, why don\'t you go ahead with your question.

**[\>\>]{.underline}**

Great, thanks. I guess a lot of good dialogue and I\'m probably going to
dovetail a little on what was just asked ask said. You know, I think
there\'s a huge difference between identity proofing and vouching for
somebody\'s identity when you\'re trying to develop credentials versus
identity proofing when it actually comes down to deciding whether
you\'re going to provide access to an individual to information. And I
keep come back to \-- the biggest issue I see is one of scalability. I
heard as a response to the last question, people talking to me, maybe we
can do it at the State level or I guess some thought about some
local-level identity proofing. But at the end of the day, I guess I\'m
concerned because we\'re talking about 300 million people that we have
to provide this service to, and some way, shape or form, whether it be
patients in order to determine who they are, for purpose of storing
records or whatever, or individuals who need to access the record in
order to provide care or some other ancillary type of service.

I guess the question really that I have is scalability and I just \--
open it up for discussions, is what do you think \-- the scalability
issues are that we\'re going to see and some of these technologies
described in the current \-- in the first set of testimony, whether
these technologies are really designed to scale to the size we\'re
talking about.

**[\>\>]{.underline}**

I think you\'re going to see problems. These Regional Health Information
Organizations are networked. They develop a network with each other
across the country, you\'re going to eventually need some schemes that
go outside of a State, and without some form of centralization and
cross-referencing, I don\'t know what the method would be.

**[\>\>]{.underline}**

I think scalability demands decentralization. That\'s just the given.
We\'ve been in the IT business long enough in this country to know that
a single repository of anything is doomed to failure.

What is required in order to make this kind of decentralization work is
robust policies that include privacy and security. And robust technical
infrastructure to allow credentialed providers and credentialed
consumers to have a method to validate the credentials that are
presented and to have policies and procedures in place to ensure that
the credentials are sufficiently robust and trustworthy.

We\'ve got many of these policies in place. We\'re working hard to make
sure that the technical infrastructure follows along with the robustness
of the policies, this being Washington we do words better than machines.
But the thing to keep in mind is that no one really wants to pay for
infrastructure before the need is there. So there\'s always going to be
a push-pull situation. There\'s always going to be \-- as you said on
the phone, a question of whether this technology can work when you build
them up from the local block to the State block, the State block to the
regional block, the regional block to the national block. The VA and the
Department of Defense have huge nationwide, and in some cases worldwide,
patient infrastructures and medical care facilities and they\'ve been
working in this space for 20, 30, 40 years and it would be good to
consult with them and see what they\'ve done that\'s worked and what
hasn\'t worked.

**[\>\>]{.underline}**

I wanted to probe a little bit on the question that was asked originally
about standards for identity proofing for providers, clinicians and
physicians, as opposed to patients.

And whether the magnitude of the risk is different if there is a faulty
identity proofing process. And I know that \-- I believe it was you, Dr.
Weiner in your written testimony had indicated the standards ought to be
pretty much the same. And I was curious about that given there may be
some magnitude of risk issues for clinician who has access to many
patients\' records as opposed to a patient who would have access
presumably to theirs or even in a faulty process access to even one
person\'s information. So I want to see your views on magnitude of risk
issues and whether in your view the standards should be the same across
the board, regardless of the type of the user.

**[\>\>]{.underline}**

What \-- we should start probing your question by looking at it
analytically. What are the risks to who, from this individual accessing
a system. Right? Once you have an objective and defined and standardized
risk assessment on that individual, well, then you could say well, this
individual will have right access to medical records for 25,000 people.
The risk in that is much different than if you have an individual who
has got right access to a record for one individual.

So clearly an analysis of the risks had address your question directly.
As I said, there are Federal agencies going forward already to issue
high assurance identity credentials to providers. So this is kind of a
question which is in some ways being overtaken by events as we speak.

**[\>\>]{.underline}**

One note from a technical perspective, you know, if you could take a
handful of providers and put them in the room today and you ask them
what their user name and log-in process and the standards they use,
it\'s just, they\'re all over the place. And there are standards in the
industry, you could try to apply to that. You also have that same
situation from vendor system to vendor system. And there\'s nuances in
each one in terms of the security. I think somehow there has to be a
level set in terms of those standards being applied to all those
products and services and the way we log in together, the same way.

That\'s a technical piece. It doesn\'t solve the identification issue,
but the security issues within the system that we purchase today, are,
we need to come to some level set.

**[\>\>]{.underline}**

In part the answer to his question about patient versus clinician
proofing and so on, privacy is a societal question. And I have a trouble
placing a value on either the patient\'s access or the physician\'s
access that\'s higher than the other one. The other is if you look at
real frequencies of events, of breaches, they might be higher currently
from patients impersonating other patients or people in the community
trying to access health data to which they don\'t actually have
authorized access. When you compare that to what\'s probably a
relatively lower frequency of health professionals who are misusing or
abusing their privileges or seeking access to systems that they really
shunting accessing. So I think the tradeoff between the quantifiable
risks have to offset the actual frequencies of these events, too.

**[\>\>]{.underline}**

You\'re right, that should be part of the analysis.

**[\>\>]{.underline}**

David?

**[\>\>]{.underline}**

So if you could talk just a little bit more about that from the
standpoint of say, role-based access. How does a provider \-- I mean, we
have good floor standards with the privacy rule of HIPAA that tell us
you should be only accessing the minimum necessary information for your
job duties. How do you manage that when you do have a large organization
and lots of providers like a hospital system where you\'re trying to
satisfy those requirements of the minimum necessary standard but at the
same time trying to provide that access, that authentication issue
becomes very fuzzy then. How do you deal with that?

**[\>\>]{.underline}**

To address in addition to, that I was struck by something that two of
you said earlier which was that it sounded like some of those principles
of role-based access and minimum necessary have not really been
implemented in some of these settings where you have nurses \-- I was
surprised to hear that because that is something that\'s in the rules
today, I wonder if you could touch on both of those issues.

**[\>\>]{.underline}**

In our organization these were large integrated delivery systems. We
define the role-based access, for example our clinical team says a
physician will have A, B, C, D. A nurse would have A, B, C, D. It makes
that process for managing that identity management process just a little
easier. So we define these standard templates that we use, and it
definitely eases the flow. Now, there\'s certain products in large
system that fall out of the norm. If we have five systems that a
physician needs access, there\'s always that one or two they want the
extra data. But at least so you could manage the mess.

**[\>\>]{.underline}**

Yeah, you know, I think historically in hospital settings it never was
something that was managed. And a clinician could go into the hospital
system and access anyone\'s record regardless of whether that was a
treating provider or not. And that was true on paper, too. So
computerization hasn\'t really changed that. But we now have in our
hospital a similar role-based system with a few roles, and one has to be
assigned to one of those roles to create a new treatment plan or to
prescribe a drug or to do certain things. But accessing the records is
different because it can be tougher to determine which patients are
mapped to which clinicians in terms of activating data. If I\'m a
patient and I have a heart attack and transferred to the intensive care
unit who is going to on the spot grant access to those intensive care
physicians to have \-- be able to treat that patient?

**[\>\>]{.underline}**

A question for the \-- actually anyone on the panel who would like to
answer this. One of my big concerns is unintended consequences of
well-meaning people doing things that we hope will benefit the public at
large. Let\'s assume for a moment that we work this identity proofing
and user authentication through. It is scalable and this is a system
that is in widespread use across the country. I\'d like to ask the
panelists to comment a bit on two potential consequences which might be
useful, maybe not.

One is, the frequent need for patients and consumers to have surrogates
or proxies access their information. Saying locked down too tight, and
difficult. The second is that of establishing identity and
authenticating users who now rely on the telephone. Will we, if we come
up with a terrific system for electronic authentication, begin to look
at what we\'ve always assumed to be adequate, which is recognizing
somebody\'s voice, when they call in, and assume that\'s no longer good
enough?

**[\>\>]{.underline}**

The telephone is really a problem. As a physician, I was calling a
hospital across town, trying to find out what was happening with one of
my patients, the nurses didn\'t know me, and wouldn\'t tell me a thing
and I was stuck. From the patient standpoint, that\'s a problem, too.
And I\'m not sure I have the answer beyond the sort of user
authentication schemes that we\'ve talked about. As far as proxies, the
proxies become the voice and representation of that patient in those
circumstances and that\'s described in writing in advance by the patient
or established by a court system as a legal guardian, for example. Those
issues are not too murky in terms of the difficulties they pose for all
of these issues we\'ve been discussing. But it does require a process
that\'s determined in advance usually.

**[\>\>]{.underline}**

Do you think having a PIN number available to you as a provider would
help in those situations when you need to rely on the telephone to
access patient information and emergency can be?

**[\>\>]{.underline}**

It would help, it would increase \-- it would add one level of security,
one more credential, add one more level of confidence.

**[\>\>]{.underline}**

Also adds one more level of risk. If I may, Peter. The proxies and
surrogates are well understood in the field. And so you can plan for
them ahead of time, what you need to do is you need to make sure that
you have the right \-- the appropriate person who is the authorized
surrogate for the patient.

And that\'s also well-known. So as long as you just fold that into your
planning, you\'re not going to have a problem with that. Not a
substantial problem.

When you need to have, as Michael was saying, the last minute on the
telephone stuff, that\'s where all of these structured procedures can
get really risky. The point here is that this is also not an unknown
situation. So this also should be planned for. And if it\'s a PIN, you
know, recognizing someone\'s voice is a valid biometric. You know,
notwithstanding, you know, the movies where people put technologies in
place for that.

That\'s a valid biometric method. If someone who can authorize access to
a medical record on one side recognizes your voice on the other side,
that\'s a viable transaction. That should be part of your plan.

**[\>\>]{.underline}**

I think maybe one problem is when those parties don\'t actually know
each other, but the person on the phone is still authorized to have this
information or to provide this information.

**[\>\>]{.underline}**

That would be part of a plan, exactly.

**[\>\>]{.underline}**

Other questions for the panel? Sue?

**[\>\> Sue McAndrew:]{.underline}**

I\'m from the Office for Civil Rights. It may be not necessarily so
apropos to this subtopic, which is secure messaging, which I think
presumes an established patient-doctor relationship is there, and so in
person information may be somewhat less problematic. But with regard to
the broader network concept, in terms of the capability of these systems
to minimize identity proofing and accept the identity proofing that has
been done by another player in the system, both on the patient side and
on the clinician side, what is your guesstimate in terms of the
acceptability of identity proofing that has been done somewhere else?
What is your level of comfort in accepting that in terms of you\'re then
sharing the information with people outside of your particular
institution?

**[\>\>]{.underline}**

Let\'s start with the answer that it depends upon what the content of
the subject matter is. If I\'m going to your Website to pull down a
press release, you really don\'t care who I am. If I could go to the
Social Security earnings and benefits system, they sure want to be sure
they\'re giving it to the right person because they got pilloried on the
front page of the Post for not being secure about that. What really is
at stake is much more complex answer than your question would appear to
ask. And that is, it depends upon what information is being transmitted.
Number one.

If you need little or no assurance of identity, that\'s \-- so you
don\'t even have to ask. But if the information that you want to protect
is substantial, the risk of injury or harm is substantial, I mean I\'m
one of those 26 million VA people who was really nervous for a while. I
want someone who has access to those records to be very well
identity-proofed, and that information be protected very carefully. I
got a vested interest in that.

There are standards \-- so if I have someone from the Department of
Veterans Affairs looking at my medical records, I know that an employee
at VA has to be identity-proofed according to 201 and HPDA standards. I
have fair level of confidence that person is who she or he is and most
likely, especially now, has the appropriate authorization to see it.

I don\'t have that confidence to faculty member at Cornell whose
identity management scheme I\'m familiar with, and I would trust to a
somewhat secure \-- somewhat confident level of assurance of identity.

**[\>\>]{.underline}**

Follow-up on that. So let\'s assume that there\'s sensitive data. And
then let\'s assume that there is a need to share that identity, and for
others to work off that identity. What I heard earlier was a suggestion
for that there may be a common processes for it, and in fact you named a
driver\'s license, a process. Does that in fact address the issue of
sharing this identity among different users of that identity? Or is that
just a way to get to a common process in.

**[\>\>]{.underline}**

That\'s a way to get to a common process. We\'re talking about sharing
information. And who gets to share that information. Who gets to see
that information. And add to that information.

**[\>\>]{.underline}**

I just wanted to follow up on this in the context of the multi-identity
issue, the multiple log-in issue, if you will. And though you may have a
common process, that does not necessarily address the issue of shared
\-- sharing the identity or having it unambiguously exchanged in that
context. Is that correct?

**[\>\>]{.underline}**

Indeed. There are many parties in this country who are adamant that they
are allowed to have more than one electronic identity. They want to be
\-- one person, you know, they want to be Paul at AOL.com for the motor
vehicle administration they want to be Howie at Yahoo for talking to the
IRS. It\'s necessary for us to be sufficiently sophisticated in our
assessment of what\'s required in the identity management space to
respect both privacy needs and security requirements.

**[\>\>]{.underline}**

I\'m really talking about the converse of that, so to speak. But let\'s
say there\'s a physician, you\'re a patient of a physician who refers to
a hospital, sometimes treats you there and uses those systems. Sometimes
treats you in their office, uses those systems. Essentially, how would,
in this context, how would they both share your identity, or would you
in the construct of what has been described here, have to have \-- do
identity proofing in both contexts.

**[\>\>]{.underline}**

Some implementations would want you to do identity proofing in both
contexts and that in fact is a scalability issue. And it\'s also a
trustworthiness issue. The concept of identity federation is expanding
in the space these days. And if both the hospital and the physician
systems are participants in the \-- in a common identity federation and
the federation trusts the credential that same credential could be
trusted in many places and in fact should be.

[\>\>]{.underline}

We took on another concept here, which is a federated identity concept
in addition to a potentially a common process.

**[\>\>]{.underline}**

The common process should be more of a policy \-- policy process. What
kind of rules does everybody follows. What are the standards that are in
place. These are the things that can be very effectively put in place in
a centralized way that can then be dispersed widely. Yeah.

**[\>\>]{.underline}**

If I may add on to John\'s question. So how do you create a
decentralized process and yet you need some sort of centralized way of
verifying that the people that you\'re sharing with are somehow
certified as being \-- as following those rules? Those national policies
this you\'re talking about?

**[\>\>]{.underline}**

Well, you know, think globally, act locally. Concept works here. An
identity federation or an interfederated mesh of identity federations,
which is what is happening in the world today, have \-- they know each
other\'s rules, they have policies and procedures for trusting each
other. They know \-- I know how Cornell issues, for example, and manages
its user ID passwords for its faculty, staff, and students. They know
how the Department of Health and Human Services issues medium assurance
digital certificates to its staff and contractors. They have an
agreement in place a priori on what level of assurance they can trust
each other\'s credentials. It\'s building that infrastructure of trust
that allows all of this stuff to happen.

**[\>\>]{.underline}**

If I can clarify my question. For the people that you know who you\'re
working with, but what about the person who presents in California
because they\'re a snow bird but they really live in Minneapolis and you
don\'t know the relationship of that provider that you\'re working with,
how do you establish that when you might have a little network of folks,
a RHIO, or something you\'re working with that you can verify that yeah,
we\'re all on sheet music. But then what about the people that you are
working with across the country, that\'s a one-time thing because
somebody\'s presenting for an emergency?

**[\>\>]{.underline}**

Well, clearly we\'re not there today. Obviously.

**[\>\>]{.underline}**

But the question is, what kind of a vision is necessary to make that
possible? The providers, the care providers in California, being part of
an identity federation, that is also trusting the credentialed provider
in Minnesota is really the answer for that.

**[\>\>]{.underline}**

Do we have a micromodel of that in how some areas approach medical staff
credentialing through joint agreements through medical staff societies
and so you do have a sort of common germ of a process for how it works,
and that different hospitals or other entities subscribe to that process
because it is a good sort of generic model for identity proofing that
physician and granting privileges. So there are some models out there.

**[\>\>]{.underline}**

Let me jump in. We\'re at a breaking point. We have a very tight
schedule today with a hearing. Obviously, the Workgroup will have
chances both to talk among ourselves and perhaps to have some followup
questions later if the panel is willing to answer those. If we have
them. I think people should keep track of questions that they haven\'t
had a chance to ask this morning.

With that, let me thank the panel, it\'s been very helpful. Appreciate
your participation. I know it was on tight timeframes to get the
testimony ready and we appreciate your willingness to meet those
timeframes and be helpful to us today. We are scheduled to break until
12:10. We\'d like to try and get started precisely at 12:10 because we
have a tight afternoon. So if everyone on the Workgroup could keep that
in mind, please. Thank you very much.

**[\>\>]{.underline}**

We\'re going to get started in one minute, if everyone could join us.

**[\>\>]{.underline}**

Are the phone lines open? People on the phone, John, are you there?

**[\>\> John Macaulay:]{.underline}**

I can hear you.

**[\>\>]{.underline}**

We\'re going to go ahead and get started with our next panel.

**[\>\>]{.underline}**

Okay.

**[\>\> Kirk Nahra:]{.underline}**

Had a good session this morning. For the Workgroup people, we\'ve
obviously scheduled on the agenda time for both questions and
discussion. We had obviously not time for discussion on the first panel,
but that\'s much easier to do, we have other calls and other sessions in
which we\'ll be able to have a discussion within our group. We do want
to make sure we can get as many of our questions answered with the
panelists while they\'re here. So again with this panel, and with the
second one in the afternoon, we\'ll take as many questions as people
have, and if we run out of time for discussion we\'ll just handle
discussion at another point.

We\'re going to move on to panel number two, identity proofing and user
authentication methods for a prepopulated and consumer-directed
electronic registration summary and medication history as part of a
personal health record. Could each of the panelists, when it\'s your
turn to speak, introduce yourself, the organization you\'re with
briefly, and then we\'d be interested in hearing obviously your
testimony. I guess we have you lined up somewhat artificially in the
order we\'re going to have you go, if that\'s all right. So Mr. Shirky,
you can start off.

**[\>\> Clay Shirky:]{.underline}**

Good afternoon, thank you for inviting me. I\'m here representing
Connecting for Health. Connecting for Health is a public-private
partnership of over 100 stakeholders in the healthcare arena, our goal
is to improve medical outcomes, lower cost, and preserve the security
and privacy of patient data through use of healthcare IT. One of our
core operating principles is that you can\'t talk about technology
without also talking about policy. So as we address these issues we
always try and work on those two things side-by-side.

I\'m the chair of the technical subcommittee of Connecting for Health,
and road to health rights, several documents which came out this April
under the heading with the common framework, a proposed policy and
technology framework for the exchange of clinical information. In that
document in particular was work both on linking patient records, the
identification problem, linking patients to their records, and merging
different records under the single identity of one patient, and also on
the authentication problem.

Since I\'ve had the opportunity to submit written testimony I\'m going
to use my spoken testimony to cull out a few salient points rather than
repeat the written document. First point I\'d like to make is that from
our point of view, it\'s vital in discussing these issues to distinguish
between personal health records and personal health record systems. Both
are essential parts of the ecosystem, but they have to be treated
separately. The personal health records are data, the personal health
records are the soft \-- the personal health record systems are the
software that act on that data. In the same way we need both standard
e-mail formats and standard interfaces among the software that handles
e-mail in order to get a working interoperable system, we need to focus
both on the standards of the personal health itself and the standards of
the software.

My comments today are going to focus almost solely on personal health
record systems, because that\'s where the authentication happens. From
our view of both existing personal health record systems and systems
which we have reviewed which are in conceptual or design stages, we are
seeing two classes of network systems. One, which is more common today,
are personal health record systems which have been tethered to a
particular care delivery organization. A hospital will issue secure
credentials to a patient, that patient can get to their own records
through a Web browser, provided the security matches what the hospital
requires.

There\'s a second class of networks, personal health record systems,
which is on the way. These are systems being proposed by entities
outside the healthcare industry \-- financial institutions, customer
service institutions, Internet service providers, and so forth.

It\'s important, I think, to focus on that second class of health record
system providers, because they are not obviously covered by current
regulations for handling health data such as HIPAA, and we may be
dealing with large aggregations of clinical data that operate outside
the customary framework. I think we need to factor that into our
thinking as we\'re contemplating both authentication issues and also
security generally.

A goal of ours, and we believe a goal that should be widely held, is to
set a common set of standards, both for behavior and for security,
across all participants in the ecosystem, in order to maximize utility
of the personal health record for the person whose health record it is.

To the point about \-- to authentication itself. It is considerably
harder to authenticate patients than it is to authenticate other
employees in a clinical system. And I think the two problems need to be
approached separately. When you\'re dealing with employees of a
hospital, whether they\'re clinicians or technicians or file clerks or
what have you, they have employment contracts, they work for
institutions which are under significant regulatory oversight, and there
are applicable policies at the local, State, and national level. None of
those things are true of patients. In addition, as we heard this
morning, the scale of patient authentication is several orders of
magnitude larger than the scale of attempting to authenticate people
operating in a clinical environment.

As a result \-- and I want to echo the comments of Dr. Alterman this
morning, which I thought were quite apposite, we believe that the
proving and authentication problem for patient access to PHRs will
necessarily rely on many institutions that have preexisting
relationships with those patients. We don\'t believe there\'s a way to
spin out from scratch an authentication method which works against the
grain of those difficulties that I just alluded to, and which can be put
in place with any effectiveness in any short period. Instead, taking
advantage of organizations that already have relations with those
patients, and may have gone through a proofing process locally to offer
access to local resources, seems like an obvious move if the goal is to
spread the use of personal health records.

In particular, again, echoing Dr. Alterman, we believe this implies
federation as a governance structure, if there\'s no single central
authority and we are to take advantage of these institutions and their
preexisting relations. Then some method, both technological and policy
oriented, for distributing trust between and among these institutions is
critical for one set of authentications to work in multiple places, and
not to force on the patients the requirement to carry around many
different user names, many different passwords, and so forth.

In particular, in-person proofing is going to continue to be a high
value operation in a federated environment. It is certainly not the only
way, but we certainly believe that it is highly useful. Because there
are, as we were hearing this morning, effectively natural biometric
solutions in the human brain \-- face recognition, voice recognition \--
which are very hard to replicate in an electronic channel. We don\'t
believe that that replication can be achievably accomplished. So we
assume that a core component of any system is going to require some kind
of in-patient proofing.

Because the data has variable value to the patient, there are going to
be variable security requirements and variable costs. Knowing when your
next dental appointment is is very different from knowing your HIV
status, obviously. Since any form of security creates significant costs,
both for the institution hosting the data and for the individual trying
to access it, there has to be a variable level, in our view, for patient
access. Which is significantly higher for significantly more sensitive
data. We have found in particular the OMB document M-04-04 to be a
useful framework for looking through those issues and examining the
interplay between the quality of the security proofing and the
sensitivity of the data.

I think most importantly, you ask in your questions what can or should
be HHS\'s role in promoting the useful adoption of personal health
records and personal health record systems. We offer essentially four
recommendations which we believe will help spread the utility of
personal health records, and systems, while preserving privacy and
security.

The first is the set of security standards which all bodies who
knowingly handle clinical data should ascribe to, whether or not they
are clinical entities and whether or not they are HIPAA-covered. We
don\'t believe this would apply to someone using standard network
storage to store clinical documents that no one was aware of. But a
service which says to a patient, we understand that you\'re storing
health records with us, and we\'re going to act on them in a way that
takes that fact for granted, without a set of security requirements to
assure the patient that there will be some energy spent towards
nondisclosure, potentially creates a very difficult environment for
privacy and security. Because you may then get these large aggregations
of data which is not covered by any policy relative to clinical data.

Secondly, we believe that a personal health record\'s principal utility
is for the patient, and a patient be in charge of read access to that
data. The existence of the record should presumptively extend read
access to any and all parties other than the ones that the patient
designates as a proxy or surrogate, if they choose.

In particular, we don\'t believe that organizations that have a right to
access to the person\'s personal health records \-- you have just gotten
a single lab result from a single laboratory, and that is added to the
personal health record \-- we don\'t believe that that organization
should have presumptive read access to the same personal health record.

And finally, we believe that those preferences should be dynamic. That
the patient should be able, as they become familiar with personal health
records and personal health record systems, to change their view of how
access to that data should be handled.

One final point. Security is a process, and not a product. There are no
organizations who do authentication who have solved the problem both
perfectly and permanently. Even the credit card industry, who has an
enormous stake in getting authentication right, has done things like
adding three digit code to the back of the card. We believe that this
kind of forum is persistently valuable, and we urge you to continue to
examine security, the security environment as it unfolds. Not just
around authentication, but for all aspects of the personal health
record.

In particular, we\'d like to call your attention to the fact that the
largest security weakness that we\'ve seen in health care systems in the
last few years is not unauthorized access of the edge of the network, or
the capture of data as it moves across the network, it\'s in fact in the
aggregations of data at rest, such as the laptop, of a PC, or the hard
drive, other ways to getting access to whole scale databases has turned
out to be a much more significant security risk than one at a time
access.

And if the PHR record succeeds the way I believe we all hope it does, we
will be in a position of figuring out how to secure those large
aggregations of data, as well as having to secure them one at a time.
And we commend that issue to you for further conversation. Thank you
very much for the opportunity to address you.

**[\>\>]{.underline}**

Thank you very much. John, why don\'t you go ahead.

**[\>\> John Macaulay:]{.underline}**

Thank you. I\'m John Macaulay, I work with Anakam, we\'re an identify
proofing and identification firm who has had significant experience in
the financial services industry. And I would like to steal a page from
my colleague, Mr. Shirky\'s playbook and bounce around a little bit of
my written testimony. Much to the chagrin and dismay of some other folks
who helped put it together. And it was perfectly timed here to go after
Mr. Shirky, too, because of our experience in the financial services
arena. And literally, with some of the examples that healthcare perhaps
may follow some of the experience of financial services industry to
identity proof and authenticate the literally millions of users of PHRs
and EHRs in the future.

And let me start by saying by emphasizing that we have seen the future
in online banking because it tends to be \-- and I\'ll quote a document
that actually is posted on the Health and Human Services Web site, a
report done by Foundation of Research and Education of AHIMA, it is that
healthcare needs to follow the example of online financial services
industry.

There is wide \-- what we\'ve seen in this financial services arena is
widespread consumer fear, lack of adoption and attrition due to privacy
concerns. Government intervention in the form of FFIEC guidance clearly
stating that user name and password is not enough, and that second
factor authentication measures are strongly recommended.

Banks and other institutions rushing to adopt these strong
authentication measures to secure consumer facing portals and protect
their brands.

Why are fraudsters targeting banking? I think it was a notorious
criminal said that\'s where the money is. And we believe the same. We
believe that PHRs, as PHRs and EHRs proliferate and users reach the tens
of millions, fraudsters will set their sights on many of these
healthcare sites, starting with the largest user bases coupled with the
weakest defenses.

Further examination of the experience of the financial industry is
instructive as to how organizations involved with PHRs and EHRs might
avoid some of the pitfalls experienced in other areas of online
commerce. While there are valuable lessons learned from the
implementation in the financial industry, we fundamentally believe the
challenges faced by the healthcare industry require a different
approach, but with similarly and potentially similar technologies.

For example, the financial industry is able to tolerate a certain amount
of online fraud. Consequently, walks a difficult risk assessment line
that balances the costs of certain security measures versus the risks of
compromise. In contrast, for the healthcare community, breached PHRs
containing, for example, mental health, substance abuse, HIV status of
users, represent an entirely different level of risk to patients and
practitioners, as well as the brand names and public perceived trust of
system owners.

For identity management, as online fraud approaches have evolved to
greater levels of complexity, the banking industry has slowly evolved
from single factor authentication of simple user name and password,
through more complex password entropy requirements, to institutional
questions, and now is finally starting to implement two factor
authentication solutions.

Interestingly, they have used one time pass code hard tokens for
providing second factor authentication for their employees within their
enterprises for the last 8 to 10 years. These hard token systems are
time tested for security, certainly; however these institutions also
know that issuing these tokens, in some cases to millions of remote
users, was much too expensive and logistically cumbersome. Given this
fact, some financial entities decided to issue tokens to their high-net
worth clients. The problem with this approach is that it can send the
wrong message to customers, and ultimately patients: Only the wealthy
get adequate security. Such a message would be a disaster in the
healthcare community.

In terms of identity proofing, until the Patriot Act amended the banking
secrecy act to counter funding of terrorist activities, the financial
industry did not have the identity proofing and credentialing
requirements that we have in the healthcare industry. When you conducted
a financial transaction online, a bank was less concerned about whether
or not you are who you say you are, they were concerned about whether or
not you are the person who put the money in the account or your name was
on the signature card. Again, the banking industry has been able to
change through evolution rather than revolution. They have now arrived
at a point from which we might receive some benefit \-- the ability to
have low-touch or no-touch ID proofing transactions.

Some banks have needed a mechanism to acquire customers through Web, and
not require them to present themselves at a branch or office for a
government-issued ID to be verified. These mechanisms are in place, and
provide a model from which we can benefit in the implementation of PHRs
into the future.

The financial industry has evolved to a position where strong
authentication is an implicit requirement. And in many cases now,
institutions are adopting two factor authentication for appropriate
controls.

One final takeaway from the experience of the financial industry is that
the policy guidance should be as explicit as possible. Only when the
authentication standards and concomitant policy are detailed, clear and
explicit, will industry be driven to adhere those guidelines.

Armed with some insights from the experience of the financial industry,
let\'s talk about what we believe are the elements of an identity
management system that can work for healthcare industry.

To our clients, we explain how ID proofing and authentication are
component parts which fit into the broader identity management life
cycle.

The first component, registration, is when the registrant provides all
the information necessary to complete the ID proofing and credentialing
transaction, and obtain their authentication mechanism. Registration
should occur once, and allow updates to the user\'s identity and profile
in the future, once established.

The next step, ID proofing, verifies the authenticity of the claim of
identity. This depth of process controls the risk the enterprise is
willing to accept. There are electronic implementations that simply
verify that the information presented is accurate. For example, with
banks, they want to see if there is a person who has that name, Social
Security number, address, date of birth provided, but are less concerned
that the person at the keyboard is actually that person.

Alternatively, there are solutions, like obtaining a passport, that
require one to present oneself in person at the post office, present two
forms of government ID, a birth certificate, so on. Executed well, these
face-to-face identity proofing applications are very effective; however,
many times ID cards are forged, and the systems fail.

Fortunately, an enterprise can select from a variety of options
including systems that allow electronic confirmation that the person at
the keyboard is the person whose data was entered into the computer, or
proxy, yet requires no face-to-face interaction. Designed and
implemented correctly, these no-touch electronic systems can be as
effective, or even more effective, than in-person ID proofing systems.
Certainly, less costly.

The third step, credentialing, defines attributes of the individual that
will define how one\'s enterprise will work with them. For example, if
they are a physician, a system can provide access to physician
credentials such that one\'s electronic business processes can be
tailored to their credentials. Likewise, a patient could be credentialed
as being a veteran, a senior citizen, or eligible for Medicaid. All of
these are attributes of the identity, not the identity themselves.

Unlike registration and ID proofing, which typically occur once in a
business cycle, credentialing has some form of periodicity associated
with it. For physicians, one can be recredentialed based on the known
expiration date of their prior credentials. One can also recredential
more frequently, such as in the case of special licensure requirements
for medical procedures or privileges surrounding controlled substances
prescribing based on a business need to do so.

Next is the process of authenticating at a transactional level offering
second factor authentication involving the one-time delivery of a pass
code to a device. Ones that we\'ve chosen are ubiquitous, i.e., user\'s
cell phone, home phone, office phone, or an e-mail account.

The ID and credentials have been bound to the second factor virtual
identification of the registrant, and therefore ID proofing and
credentialing are no longer needed unless one\'s business needs define
the need for recredentialing as described above.

Once the authentication is completed satisfactorily, the identification
and credentials are handed off to the application to be used for the
business purpose.

While each component may have some vulnerability to a determined hacker,
the combination of the components makes fraud and beaches very unlikely.
For example, a disgruntled medical staff member may be able to get
through a physician automated Web-based ID proofing process, but it will
do no good because that same staff member cannot get past a second
factor authentication system at the transaction level.

To accomplish the latter, the staff member would need to know the
physician\'s user name, password, be using a preauthorized device, and
have in their possession the second factor token. Collectively, very
unlikely.

Interestingly, under some PKI employments, the system could be
compromised quite easily by a disgruntled staff member if the system
allowed the physician to store their private key on a particular
hardware device such as an office PC. Under this PKI scenario, the
system cannot tell who is behind the keyboard.

We understand the need for patients to have control over how their
information in their PHR is accessed and used. In our view of the PHR
business, all medical practitioners would be able to publish and request
access to the PHR. The patient would have an appropriate level of
control over what data was included in the PHR, and then who could view
it.

We support the use of the medical information exchange model, which
would be based upon well-defined standards, such as those derived from
the national information exchange model. These models all rely on
publish and subscribe model, where access to a record within a folder is
controlled by user and role-based permissions. The folder owner,
analogous to the patient, controls what elements within a folder the
subscribers have access to. The publishers, analogous to providers,
would publish data and request that it be included in the PHR, and when
the folder owner would specify who can see the data in the record.

Fundamental to this approach is an effective authorization and access
control system. A final element of such a system is the ability to issue
an additional challenge requiring second factor authentication for
anyone attempting to access a particularly sensitive portion of the PHR.

In the end, we believe that the government, in concert with industry,
should establish a minimum \-- should establish the minimum standards
for ID proofing, credentialing, and access control, and it should be
left to the system owner, the practitioner, and the patient to choose
the mechanism they use to meet this standard.

The government can set the minimum standard by referencing existing
Federal minimum standards for the information protection, such as those
alluded to in previous panelists and speakers, such as those found in
NIST special publication 800-63.

To be specific, we believe that the privacy and security of personal
health information justifies a minimum level \-- minimum of level-3
information assurance controls as defined by NIST Special Publication
800-63. One difference we see is that, unlike SP 800-63, which ties
those levels to the technical means used to achieve those levels, we
believe the levels in the PHR space should be tied to the roles of the
users within the PHR user community.

Finally, we wanted to underscore the importance of government and
industry being proactive in developing clear standards and providing
detailed and explicit policy guidance to help enforce those standards
for the benefit of all stakeholders. This approach will help prevent
some of the confusion and reactionary mind set that has hindered the
financial industry\'s ability to implement appropriate systems for
combating online fraud.

Protecting the confidentiality, privacy, and security of patient data
will come at a cost, however. The systems which require no special
hardware or user software help to mitigate the traditional high
deployment costs of hard token based systems.

Interestingly, while increased costs of security may seem like a
barrier, they are also an enabler for success. With increased security,
system function and depth of information becomes richer. It has a direct
impact on driving user adoption \-- particularly adoption by physicians.
With increased adoption by physicians, we will see a commensurate
increase in adoption by consumers, patients, which will in turn drive
unit costs down. At the same time, the value of the aggregate data helps
sustain the price point, since more participation, the data set and
function becomes more valuable.

As has been seen in numerous medical information portals, participation
in the system by physicians drives user adoption and participation. If
doctors don\'t participate, patients won\'t either.

In summary, we believe that in order to accommodate what could be a very
fast adoption rate of HIT in general over the next few years, security
systems for PHRs and EHRs should have the following characteristics. Be
based on detailed standards jointly developed by government and
industry. Allow no-touch ID proofing upon enrollment. Allow electronic
credentialing of physicians and other medical practitioners using only
the most trusted credentialing data sources.

Require second factor authentication that can be repeated within an
application for added security while accessing the most sensitive areas
within a PHR or an EHR.

Provide real-time fraud alert to patients and practitioners should a
fraudster be trying to access a PHR or EHR. Be scaleable and affordable
by using hardware that is ubiquitous in the healthcare environment.

Rely on an easy and intuitive user interface that require no software
downloads for patients or practitioners. Provide technical
nonrepudiation, data integrity, and customizable reporting for HIPAA,
CLIA, and other regulatory compliance requirements.

Chairman Feldman, Chairman Nahra, and members of the Workgroup, as a
company, like many other fine companies in this space, we are excited to
be in a position to contribute in our own small way to the future
success of PHRs and EHRs. Working together, we can contribute to
developing a PHR which contains comprehensive patient information,
available 24/7, fully endorsed by physicians, linked to relevant
resources, and secured by identity management systems which fully
protect the most important element of all: public trust. Thank you very
much.

**[\>\> Kirk Nahra:]{.underline}**

Thank you, Dr. Macaulay. Ms. Graham.

**[\>\> Gail Graham:]{.underline}**

Thank you. Good afternoon. I\'m Gail Graham. I\'m the Director of Health
Data and Informatics, for the Department of Veterans Affairs, Veterans
Health Administration. I want to thank you for the opportunity to share
our experience with you with identity proofing and user authentication
in the VA personal health record program.

On Veterans Day 2003, the Department of Veterans Affairs launched
MyHealtheVet, a gateway to Veteran health benefits and services. A year
later the VA added the personal health journal, a convenient, secure
online journal veterans can use to manage their health information.
MyHealtheVet was designed to provide health information developed
especially for veterans. In addition to the personal heath record
journal, the site provides access to health information libraries, links
to Federal and VA benefits, resources, health calculations,
self-assessment tools, and online VA prescription refills. In the future
users will be able to view appointments, copay, balances, key portions
of their records, et cetera, online.

Identity proofing and user authentication is handled in MyHealtheVet
personal health record in a tiered model that aligns increasingly with
rigorous requirements, increasing at a level of the accessed
information, as really has been pointed out by the previous two
speakers. Website visitors may access personal health record educational
content through the site\'s evidence-based health information libraries
without registering or logging in. Registration is required before users
can access additional program features. Initial registration is
accomplished using a Web-based form on the site, and complex passwords
are required in order to safeguard user information. Once registered,
users have access to self-entered information features such as health
journals and health e-logs.

In order to enable the inclusion of personally identifiable health
information from electronic health records, heavy proofing is required
through an in-person authentication, or IPA. To accomplish this level of
authentication, veterans must present at a VA facility or VA-designated
location and display photo ID or VA identification card, in addition to
a valid photo ID issued by a government agency. MyHealtheVet
administration then initiates a transactional process to match the
user\'s information with the VA master patient index using the Social
Security number as a key identifier, at this time, in addition to other
factors relative to the individual. This matching is critical to connect
the patient to functions like prescriptions, refills, which is available
currently, and health information extracts will be available later this
year.

For example, a patient seeking access to parts of his or her electronic
health record through MyHealtheVet will go to a VA medical center to be
identified face-to-face by the facility\'s health information
professionals. The health information professionals would ask the
patient for appropriate identification, and verify the patient\'s
information in the VA electronic health record system. This
authentication process would only be required to be completed once.

Once the patient was identified and authenticated, the patient would
receive access to required copies of his or her electronic health
records through MyHealtheVet. MyHealtheVet currently contains data
entered by healthcare consumer \-- by the healthcare consumer, and may
soon include a copy of the key portions of their patient medical record
extracted and integrated securely into the patient\'s personal health
record. In a future release, patients will be able to delegate access to
parts of their record or to the entire PHR to another person, such as
another healthcare provider, family member, or advocate. This is
especially necessary for VA as about 40 to 50 percent of our patients
receive care not exclusively from VA but from other providers, as well.

The functionality has been tested as part of the MyHealtheVet pilot at
nine VA medical centers. The pilot has supported more than 7,000 users
over the past several years, with positive results. The pilot enables
participants to request extracts from their electronic health record
which are copied securely into the patient\'s secure e-vault for display
in their portal. The pilot includes extracts in 18 topic areas,
including laboratory, medication histories, and progress notes.

The pilot also enables participants to delegate or grant access to
selected portions of their personal health records. Delegates and
grantees must be registered in the system, and access is managed by the
patient from an interface within the system.

Although pilot sites were given flexibility in terms of some aspects of
the implementation, identity proofing, and user authentication methods
were standardized in order to meet standard requirements of heavy
proofing. All pilot sites required pilot participants to sign release of
information documents to \-- just really to serve as a paper trail and
auditable link for us, and to provide the valid photo identification
prior to being provided access.

One potential concern in rolling out in-person authentication throughout
VA is a lack of on-site health information staff at all of our more than
1,300 sites of care, particularly in rural areas. We have worked with
the clinics to meet needs of patients in these areas without requiring
their travel to the nearest VA for in-person authentication or making it
more convenient.

The medical centers have satellite clinics, and those staff are
encouraged to ensure that patient members \-- to make sure that our
staff is available to do the in-person authentication.

Attention to users needs is not limited to the initial in-person
authentication. VA has noted that the pilot sites often request support
for retrieving user name, password information, in order to log in. As a
complement to the initial account creation process, log-in support must
likewise have systems and processes which protect account access.

For example, although participants are able to submit requests for
forgotten passwords through Web-based forms, centralized help desk team
supports all the pilot sites to ensure that high levels of security are
adhered to. Requesters are required to provide a telephone number, and
respond to several questions in order to receive password information.
If unable to meet those requirements, a password reset process is
initiated.

For a personal health record which includes medication history and
registration summary, in-person \-- initial in-person authentication is
essential. This process is recommended whether or not the PHR currently
contains sensitive or protected information, due to the potential for a
basic PHR to be expanded with additional information requiring an
additional level of security.

Over the several years that MyHealtheVet pilot has been conducted no
instances of inappropriate account access have been reported. This is
likely due to the rigorous requirements for account access including
in-person authentication, and also as a result of heavy emphasis on user
training that we plan. User training and the patient \-- really train
the patient on what is their responsibility, in protecting user name and
password.

In-person authentication has been viewed by pilot participants as in
their own best interests, because it directly enforces the kind of
security levels required to protect their health information.

The MyHealtheVet pilot has afforded the VA an opportunity to gain
practical experience with the demands and benefits of identity proofing
and user authentication for personal health records.

In VA we consider this information in the PHR to belong to the patient,
not to the organization providing the PHR system. In offering a personal
health record, a provider has entered a critical trust agreement with
the healthcare consumer which must not be sacrificed for convenience. It
is essential that health information remains private and secure, whether
it is stored in an electronic health record or in a personal health
record or on paper.

VA supports the development of guidelines and standards to ensure that
authentication and identity management of PHR systems are handled
consistently throughout the health care community. Thank you.

**[\>\> Kirk Nahra:]{.underline}**

Ms. Graham. Ms. Dixon?

**[\>\> Pam Dixon:]{.underline}**

Thank you for your invitation to testify before you today. I appreciate
it very much.

So I don\'t want to read my testimony to you, but I would like to cover
the highlights. Basically, what I would like to do first is to lay down
some very broad conceptual frameworks, that really I tried to simplify
some very dense technical concepts into things that are I think more
digestible. Then I would like to turn to identity proofing in a digital
environment.

So the first thing I want to talk about with you today is medical
identity theft. Oh, I\'m Pam Dixon, Executive Director of the World
Privacy Forum, I\'m a researcher, and basically a geek. And that\'s what
it is.

Medical identity theft. We, for one year, we researched the issue of
medical identity theft. We conducted extensive interviews with law
enforcement, government agencies, State agencies, private insurance,
police officers, so on and so forth. Basically, the people in the
trenches. We did a fairly exhaustive review of all the cases in the
matter, and I can stand before you today and say that there is
unambiguous proof that medical identity theft is occurring in the
medical sector at a fairly decent rate. We think it\'s about 2.5 percent
of all identity theft cases, and we believe that the harm in medical
identity theft \-- which is, by the way the use of identity documents or
information for receiving medical goods or services \-- we believe that
this fundamental harm is not having an eyeball on your medical chart.

You know, I really don\'t care about someone\'s eyeball on my medical
chart in a security breach. What I really care about is someone who has
my medical information, has used it for a good \-- some kind of medical
service, and then the physician who is the unwitting victim of this
thief as well, the physician enters information into that chart which is
no longer accurate for that person.

We believe this is a fundamental harm of medical identity theft, and
unfortunately there are many, many cases of this. For example, the FTC
recorded in a public document the case of a Linda Weaver who someone
stole her identity, went in and received medical services, and her blood
type was changed. And then when she went to the hospital to receive
medical services they almost gave her the incorrect blood type. This was
not due to any clinical error, this was due to an identity thief.

But what I\'d like to point out is that the real problem here is not the
one-off person, you know, a desperate person without insurance who comes
in and presents to a hospital as someone they\'re not. The real problem
here are trusted insiders. And the trusted insiders can range from
physicians to nurses to clerks. And unfortunately, there\'s also an
unambiguous evidence that doctors are indeed involved in many identity
theft schemes. And I am not trying to attack the physician community,
I\'m just saying there\'s a small percentage that are doing this. But
they\'re doing it to scale, as the caseload on this shows.

You have the recent case in Florida, where an insider took over 1,000
patient identities, sold it to organized crime, and then you had, what,
millions and millions of dollars of theft. And unfortunately,
corresponding changes in those medical files.

So the problem here is that after the crime is committed, victims then
have trouble recovering. So for example, let\'s say that your file you
discover has been changed for whatever reason, through some form of
either insider or, you know, one-off medical identity theft. Then you go
and try to change it. You go to the insurer you say you know what, my
health record is incorrect, the insurer says go to the provider. Well,
for the victims of for example the Juga (ph) crime ring that stole
thousands of identities because they literally purchased a health
clinic, and then gave healthcare to people and changed their files, the
provider was the perpetrator. So they\'re caught in a catch 22 of trying
to get corrections.

So where does this leave us? This leaves us talking about the trust
architecture that\'s really the fundamental basis of the medical sector,
and how data flows.

So basically, data flows in the medical sector. It doesn\'t matter what
you lay on top of it, doesn\'t matter how you talk about it, PKI,
transitory trust, the fundamental thing is that within the medical
sector, once you\'re an insider, you\'ve basically got the run of the
chicken coop. And that\'s just the way it is.

It has worked in a closed system. But when you lay a network on top of
that, that system really gets pressured in very fundamental ways. When
you have thousands of institutions that have access to data that
formerly only a few practitioners had access to, that\'s when you get in
trouble.

I specifically want to talk about one aspect of this, which is the
merging of treatment and payment information in the digital environment.
This is a core, core component of what I think this committee really
needs to look at. So I\'m going to read a little bit just because this
is very precise. In a paper-based world, payment and treatment systems
were largely separate. There was little commingling between the two,
other than what was absolutely necessary. But in the digital and network
world, for all intents and purposes, this information has become in some
cases and is becoming increasingly the same, and becoming merged.

And I want to talk about the most salient example of this, which is a
pilot project in California, through Cal-RHIO \-- and also this is
occurring in Tennessee and a number of other States, by the way. What it
is, it\'s called an emergency department information-linking project.
And what happens is that a patient will show up in an institutional
provider that\'s signed up for this pilot project, and then that \--
let\'s say a person presents at this provider, and they don\'t have an
EHR. Nothing in digital format shows up for them when they present.
Well, what happens is their insurance company is paying for that
information, and the insurance codes then populate the fields of the
electronic health record.

Now, what does this do, what\'s the benefit? The benefit is that someone
without a health record in digital form gets an instant, by proxy,
health record in digital form. And I have to tell you, in a perfect
world, this is a good idea. It really is. Because all of a sudden
you\'ve got a pretty good, accurate picture of that patient\'s treatment
history. Because the insurer has that information, it\'s digital, and it
can be used to populate the EHR.

But unfortunately, ahem, what happens is that this does not look at the
issue of fraud. Fraud exists to, an estimate by GAO, 10 percent of the
medical environment. And if you have that level of fraud \-- which, by
the way, no one has counted this number to any degree of accuracy, and I
couldn\'t pin anyone within the Federal Government, State government, or
anywhere else who would pin it down more clearly than that \-- if you
have a high level of fraud, then this information that\'s being used in
the payment systems to populate the treatment systems could be
inaccurate and could lead to health issues.

If medical researchers then go and use this digital data to base their
population research or studies or any other important medical research
on, then you\'ve got also statistics that could be in question, as well.
So this very simple thing ends up impacting many, many different lives
and systems. And this is just one example of how the digital environment
really changes the architecture, fundamentally.

And then I want to turn now to the whole idea of patient identity
proofing in a digital environment, with this conceptual background in
mind. So first, I think the most important thing that I could say to you
is let\'s say that there are 100 people that are going to a hospital,
and let\'s say that you develop a system that could authenticate them to
the highest possible degree of certainty. Let\'s say 98 percent. And by
the way, that would be remarkable. Usually authentication systems
aren\'t that certain.

But let\'s say you could get 98 percent certain that this was the person
who they said they were. I have to tell you, this will not resolve the
problem of fraud in the system, it will not resolve the problem of
medical identity theft. Because the vast majority of cases, according to
all the research that\'s on the books, is coming from the inside of the
system. From the trusted insiders, the people who are part of that
trusted network. Rather than the outside. So you can authenticate the
patient, but it\'s not going to solve all the problems.

And the problem then is, well, what do you do with the insiders. And I
think there\'s a panel coming up this afternoon that talks about this, I
think certainly background checks would be an excellent idea, and there
are some other very well-regulated answers that are already on the books
that could cover this.

But what about patients, because that\'s what this panel is about. In
our research, we came across a hospital that had instituted what they
call TSA style identity proving. They require two forms of document,
they photocopied them, and then added it permanently to the patient
file. And they had hired a vendor to digitize this process. And by the
way, we found a number of hospitals are doing this. So you have a
digital identity document with biometric on it, a picture, becoming part
and parcel of the electronic health record.

Well, what does this mean? What this means is that when a thief goes and
steals this, not only do they get the medical file, which is worth 50
dollars on the street \-- which is a lot of money, by the way. Other of
things go for only 2 cents, medical files go for 50 dollars. Big price
differential, it\'s a big cash cow. If you have this valuable identity
information, you have a real problem. Because now not only do you have a
problem with kind of okay medical identity theft, you\'ve got robust
identity theft. And it gives the criminal the ability to impersonate
someone very well in a trusted architecture. So that\'s probably not
your best answer to do identity proofing.

Also, in the financial sector there are a number of very important tools
that are used to prove identity today. You heard some of them today.
They use credit reports, they use anti-fraud and identity products such
as Osun (ph), (inaudible) and others. They also use near real-time
Social Security number authentication, as do many retail employers who
are doing background checks.

This kind of information is highly regulated in its use under the Fair
Credit Reporting Act. For example, when this information is used for
determining credit.

But in the healthcare sector, they\'re not used to getting this kind of
information. The healthcare sector is used to getting personal health
information. They\'re not used to getting financial information, and
other identity proofing kind of authentication information, which is
what you step into when you start talking about financial sector style
authentication.

So what does this mean? This means that this information, which is not
regulated under HIPAA, becomes very open to all sorts of abuse, as long
as it\'s not being used to determine credit, or employment. So you\'ve
got a real regulatory issue, there. So \-- I\'ll skip that, because we
already know that.

So I think one of the things I want to say is that instead of identity
proofing patient with financial sector style tools, and things that are
very valuable in their own way, I really urge the committee to pay great
attention to healthcare insiders. Not so much on the patients. There
must be a harmonization between what is reasonable and what is
necessary.

And I think what is reasonable is probably the \-- yes, I think it\'s
very reasonable for a healthcare institution to ask for a driver\'s
license, and to look at it. I think that is completely reasonable, and I
hope all healthcare institutions begin doing that.

Is it reasonable to digitally scan that document and make it a permanent
part of the electronic health record and then pop it on to a network?
Not so much. I don\'t think that\'s quite as reasonable. So I think
there has to be a harmonization of this and I think there needs to be a
discussion of all stakeholders involved and a process to find out what
is the right balance.

If this committee decides to go forward with a form of authentication
that brings anything from other sectors in that include identity
proofing documents, or any kind of anything that is not usually part of
the personal health record, the same kinds of protections that are in
the financial sector that protect this information \-- transparency,
recourse, accountability, adequate and responsible risk assessment, such
as under Graham-Leach-Bliley, that needs to come with it, too. You
can\'t just pull this kind of detailed robust information in, and also
not do risk assessments.

So I ask you to thoughtfully and soberly consider the risk to patient
health through data inaccuracy that medical identity theft brings, and
other forms of fraud. And I ask you to look at all the pilot projects
that are being conducted right now. For example, the Cal-RHIO pilot.
There\'s not been a risk assessment done, but it\'s using live patient
data, live patients are going through the emergency departments. I think
the project is interesting, and I think many things can come from it,
but I want to make sure that there\'s been a risk assessment. And I
think that\'s a term you\'ve heard a lot today. In most sectors, in the
corporate world, risk assessments are routinely done. In the financial
sector, you\'ve got Sarbanes Oxley, you\'ve got all sorts of regulation.
But risk assessments aren\'t really done the same way in the healthcare
world, and I think it\'s going to be very important to do that going
forward.

So thank you, again, for inviting me to testify, and I appreciate it
very much.

**[\>\> :]{.underline}**

All right, thank you very much to all the participants on the panel, we
appreciate that. We have approximately a half an hour scheduled for
questions from the Workgroup, is there anyone who wants to start off
with a question?

**[\>\> Lorraine Doo:]{.underline}**

Kirk or Paul, this is Lorraine on the phone. Do you want questions from
us as well?

**[\>\>]{.underline}**

Go ahead.

**[\>\> Lorraine Doo:]{.underline}**

Okay. Again, all the presentations were very interesting. I in
particular, because the topic was identity proofing and user
authentication methods for the use case that we\'re involved with on the
Consumer Empowerment of the registration summary and medication history.
And I wonder if the panelists, either all or some of them, would like to
give their three key thoughts specific to this question, which is for
this registration summary and medication history, what things must we do
for the identity proofing and user authentication?

**[\>\> Clay Shirky:]{.underline}**

This is Clay Shirky from Connecting for Health. I think the first one of
them is to take advantage of existing relationships among care delivery
organizations, and then possibly other organizations depending on
whether they present themselves in your scenario. Rather than trying to
recreate the proofing from scratch. To figure out what is out there that
can be taken advantage of at low cost and with preexisting relationships
of the patients.

The second is as a result of that, to work out some mechanism of
federated governance so you can have both high accountability and
therefore high trust in your future dealings with any organizations you
involve in that kind of proofing.

And the third is to prevent clinical data from being commingled with
proofing data. I want to echo I think some of the things that Pam was
saying. It is very tempting to use \-- obviously, the medical record is
filled with personally identifying facts which presents itself to have
an opportunity to have a very high degree of confidence of someone\'s
identity, but at tremendous risk of accidental disclosure. And so when
you were doing the proofing, certainly from the Connecting for Health
point of view, we would recommend that you limit yourself to
identifying, but not clinically relevant details of the patient.

**[\>\> Pam Dixon:]{.underline}**

This is Pam Dixon. In demonstration projects I\'ve seen of various
registration forms and whatnot, one of the fatal errors that it\'s made
is it\'s just what I would call, what Clay is calling, from scratch
authentication process. And I would echo his comments, I don\'t think
this works in the medical sector. And I think that using existing
relationships that are already identity proofed in person is really key.

I think that you\'ve really got to do some kind of in-person as a base,
and then move forward from there. Because if you don\'t do that, you
really run a lot of high risks.

I think that asking for \-- there\'s a whole lot of technologies that
you can use, but the fundamental core is that you\'ve got to really know
who this person is, usually through in-person mechanisms.

And then in terms of what you\'re asking for registration information,
it really should be quite neutral and should not be giving away
fundamental details that could, if breached, go to harm that patient.

**[\>\> Gail Graham:]{.underline}**

This is Gail Graham. I think as we introduced medication histories into
the availability in our electronic health records, that\'s when we moved
to the in-person authentication. And certainly, as this technology
evolves if we could come up something with greater reliance, but we
really felt that for the time being, anyway, that that in-person
authentication was a requirement as we put health information on their
Website on the MyHealtheVet Website.

**[\>\> Lorraine Doo:]{.underline}**

I think from the perspective of Medicare, the Medicare beneficiaries, I
don\'t disagree necessarily with the proposals, but I think it\'s a
logistical \-- a logistical challenge, let\'s put it that way.

**[\>\> Pam Dixon:]{.underline}**

I think it\'s really better to deal with that logistical hurdle up
front, because what you\'re talking about here are patients\' lives. If
you have an imposter, the risk is too high to human health and to
safety. And I think that\'s the fundamental issue, here, that really
makes the medical sector different from the financial sector.

**[\>\> Kelly Cronin:]{.underline}**

This is Kelly Cronin. I\'ve been closely involved with working in the
national \-- Office of the National Coordinator with the Consumer
Empowerment Workgroup, as has Lorraine. One of the things we\'ve been
hearing a lot about over the last nine months is the amount of market
innovation in this area, and in particular the health plans are very
aggressively moving forward and offering personal health records that
are prepopulated. And of course, we obviously have a lot of concerns
around data integrity, data quality, the \-- you know, what
authentication mechanisms they might use.

But getting to the feasibility issue, if there is a real momentum in the
marketplace right now for many different types of PHRs, and there\'s no
even real common, tight definition of what that is, what would you
recommend as a feasible option that would minimize the risks, but yet be
deployable?

So with the health plan-based PHR, what would you recommend?

**[\>\> Clay Shirky:]{.underline}**

One of the common lessons from networking is if you standardize the
data, standards promulgates faster than if you standardize the software.
If there is an agreed upon frame for the personal health record, many
different people can develop software that looks at that, consumes it,
adds value to it in various ways, provides translation services,
formatting services, so forth. Common data standards tend to be a better
platform for software innovation than common software standards do for
data innovation. Because the one thing everyone will agree on in
building personal health record systems, the heart of the system, there
should be a personal health record.

Any effort to make those records essentially subject to a common view by
all actors, including of course the patient themselves, would in our
view be the disproportionately best move for catalyzing both the growth
of the market overall, but also for its interoperability across a
variety of different participants.

**[\>\> John Macaulay:]{.underline}**

Kelly, this is John Macaulay. And Lorraine, I wanted to respond too to
the feasibility, and underlying feasibility. And I\'ll respond to the
question somewhat anecdotally, because there\'s a preponderance of
evidence \-- and I\'m not suggesting that we commingle financial data
and claims data with personal health record data. But for instance,
we\'re talking about a prepopulated data set, that can be accessed, and
those questions can be posed to consumers, consumer patients, to be able
to ascertain the original. That original transaction has to be the
registration that I referred to, that ID proofing at the front, and
before any kind of ongoing transactional authentication takes place.

This is very evident in the financial services arena, and if one thinks
on how you would obtain a credit report online, that\'s exactly this
kind of situation that occurs that has driven fraud down to negligible
levels in the financial services arena. You can go on the online credit
bureaus and obtain a report in a much equivalent manner. This is I think
evidence of feasibility.

**[\>\> Pam Dixon:]{.underline}**

This is Pam Dixon. But the credit report falls under tight regulation of
the Fair Credit Reporting Act, where you have the ability as a consumer
to go in to dispute what\'s in the credit report and to ask for a
reinvestigation of that material. So I think that your idea is very
interesting and I agree with your idea, I see it popping up all over the
place. And certainly one of the most disturbing trends is the claims
data being used to populate fields just simply because it\'s fast and
it\'s easy.

I think for data integrity purposes I think \-- and in order to minimize
risk, I do think there\'s got to be some kind of basic, deep coding
standard as opposed to high level or kind of, you know, mid-level
software standards.

You know, and I\'m talking about like OASIS, you know, really big
standard setting bodies. I think that\'s really the ultimate answer that
kind of clears that up. It takes longer, but it\'s a much cleaner
process, and it\'s a consensus process, which makes it I think a healthy
process.

But I think that as this \-- you know, process of the PHR rolls forward
we\'ve really got to look at putting those same kind of consumer
protections in there that the Fair Credit Reporting Act affords. We\'ve
got to allow people to provide ways of correcting errors that they see,
under HIPAA. We all know that we can do an amendment, but getting that
amendment is tricky, tricky, tricky, in reality.

And so I think that yes, this is good. But let\'s also look at adding
some protections in there. And, you know, I think there\'s a couple of
ways of doing that, but that\'s a different topic.

**[\>\> Gail Graham:]{.underline}**

I want to add as we explore, this has been a learning experience for us
in the personal health record arena. We\'ve worked with Dr. Paul Tang in
Palo Alto and with Vanderbilt and others who have had experiences, and
we\'ve looked at different options for the authentication. We also have
an advisory group of clinicians and health information professionals and
veterans that really balance what\'s available technically against what
we have, and we really believe that the success of these programs are on
the reliability of the patient, whether they\'re the veteran or you or
I, in keeping that information protected. So that we hope in the future
there\'s something that we could rely on for computerized match or some
electronic means, because certainly we recognize the workload that
we\'re taking on in this in-person authentication. But feel today
that\'s probably the best approach for us.

**[\>\>]{.underline}**

Lee.

**[\>\> Lee Partridge:]{.underline}**

Lee Partridge, National Partnership for Women and Families. This is for
Gail. I\'m particularly interested by something you said. When you said
you added the medication records, you decided you also needed them to be
much more careful about the identity of the patient who was asking for
that information. And you also allow your patients to do some updating
of the PHR, is that right?

**[\>\> Gail Graham:]{.underline}**

Of their vault. That information does not go back up, there is
instructions, (indiscernible) if they find something they want to amend
in their record, how to go through the established process for
amendment.

**[\>\> Lee Partridge:]{.underline}**

Right, which I think all of us think is very promising tool down the
road, because it allows for some other more sophisticated kinds of
updating, like the blood pressure reading or so on so on from home.

If your system allows that kind of updating by the patient, do you
assume that you\'ve also got to be very secure on patient identity for
that? I\'m thinking partly of making sure that somebody other than the
patient isn\'t erroneously updating the patient\'s record.

**[\>\> Gail Graham:]{.underline}**

And that really goes part and parcel with during this in-person
authentication session, we also, in participation, how important it is
for them to be cautious of who they allow delegation privileges to.
Because they can be \-- you know, pieces of their record, and for
specific periods of time, if they\'re seeing a cardiologist or if they
need just an opinion or \--

**[\>\> Lee Partridge:]{.underline}**

So I think what you\'re suggesting to us is we not only have to be
talking about standards, we also have to be talking a lot about patient
education.

**[\>\> Gail Graham:]{.underline}**

Correct.

**[\>\>]{.underline}**

I want to go back to the question of in-person versus online
authentication processes. And the question is really for you,
Dr. Macaulay, because you\'ve indicated you\'ve seen effective models of
this no-touch identity proofing. And having not had the experience of
requesting a credit report online yet, is that the model? I mean, is
that the model that you would cite as an effective example of the
no-touch identity proofing?

**[\>\> John Macaulay:]{.underline}**

That is one of the models, and it would be kind of a cross-industry
model, as well. For instance, there would be name association with phone
records going into public databases to be able to select various data
sets that would be able to uniquely identify each consumer patient. Yes.

**[\>\> Pam Dixon:]{.underline}**

May I jump in here? Just \-- I apologize for jumping in so much, but
when you ask for a credit report online, we issued two reports on this.
One of which was the basis of an FTC enforcement action against the 150
fraudulent \-- excuse me, 151 fraudulent companies that were trying to
rip off consumers, so this is a really big issue. Look, when you go
online and ask for this authentication on, for example,
annualcreditreport.com \-- which is the most secure online site I think
that\'s been created for a credit record, it\'s created \-- it\'s run by
the FTC and the three credit bureaus.

What happens is that you\'re authenticated through a process that goes
through very detailed identity information. Your mortgage, your car
payment, your residential history, your Social Security number. All
of \-- your home address. All of this information must be used to
authenticate you online at that level of detail. And here is the problem
for the medical sector.

Again, I\'m going to say it one more time, this is \-- the use of this
in the credit industry, this level of authentication, is regulated under
the Fair Credit Reporting Act. But the use of this data within the
medical sector is not regulated under \-- I don\'t think, the Fair
Credit Reporting Act or under HIPAA. And you\'ve got very detailed,
very, very sensitive authentication information that you\'re looking at,
and you\'d have to contract with a commercial data broker. And then that
commercial data broker would then know who is getting authenticated for
their personal health record, what their name is, and \-- you know, you
create a whole kind of lion\'s nest of issues there. It\'s a very
profound problem to bring in financial style authentication using the
very deep kind of identity proofing documents that they have access to,
under regulation. To bring that same thing into the medical sector is
just a Pandora\'s box. You can open it, but you need to know what
you\'re getting into.

**[\>\>]{.underline}**

Just to a follow up quickly on that. It\'s my understanding that
information that\'s collected \-- not just related to the provision of
care, but also related to the payment for that care, would be considered
protected health information under HIPAA. And is that different from
your understanding?

**[\>\> Pam Dixon:]{.underline}**

Different from \-- what?

**[\>\>]{.underline}**

Well, you were saying that HIPAA doesn\'t apply to this financial
information.

**[\>\> Pam Dixon:]{.underline}**

No.

**[\>\>]{.underline}**

But that\'s actually not my understanding. My understanding is that \--
is that information related to the payment of that treatment is
considered part of protected health information, and I\'m just trying to
clarify whether that\'s your understanding as well.

**[\>\> Pam Dixon:]{.underline}**

No, not in the type of authentication scheme we\'re talking about.
Because this really wouldn\'t be treatment information, or payment
information. This is authentication. And authentication for going online
to get your information, I think it\'s \-- I think it\'s a very, very
difficult, very complex issue. And we actually just submitted red flag
comments to the FTC and OCC on this exact issue. And unfortunately,
there is a great lack of clarity regarding this issue, and we\'re really
hoping that there\'s some \-- you know, little things that can be done
on the FTC side that would clarify these exact questions that you\'re
talking about.

**[\>\>]{.underline}**

I have an add-on question. I would sort of understand that as being
health care operations data that the covered entity would be gathering,
and it would be covered under the privacy rule of HIPAA. I guess I would
be more interested in these other organizations that are outside the
covered entity, where you have somebody else that\'s doing this for you
and, you know, how do we ensure that that business-associate
relationship gets pulled back into HIPAA? If they\'re not doing it for
the covered entity, if they\'re doing it as a service to the consumer of
healthcare, then you don\'t have a way of snagging that.

**[\>\> Pam Dixon:]{.underline}**

That\'s what I\'m talking about, that\'s really the scenario that I\'m
describing. Because when you move into authentication like this, you
really move into that kind of approach. And I\'m not saying that it\'s a
flawed approach in the financial sector, I\'m just saying that\'s the
way it is. And that\'s exactly what I\'m talking about.

**[\>\> Kirk Nahra:]{.underline}**

I\'d ask we not get into the legal debate about what HIPAA does and
doesn\'t cover. I have maybe some different views, and I think some of
the people around the room do as well. Paul, you had a question, then
Peter.

**[\>\> Paul Uhrig:]{.underline}**

Paul Uhrig from SureScripts. Clay, you touched on the issue of
accountability, and I guess I look at it from the point of view of
liability. And I think there\'s a real issue, because at a marketplace
when I ask this question people tend to run for the doors looking for
their lawyers. So what I hear is that physicians, and someone suggested
pharmacists, are on the best position to authenticate, to prove the
identity of the patient and issue the credentials for the PHR. And in a
truly interoperable world, with a PHR, that person, presumably the
person they say they are, will be able to ping labs and get labs
results, pharmacies for med history, and other providers, and download
their medical records.

But it would seem that labs or pharmacy will only want to do that if
they believe they\'ve got an implicit or explicit representation that
whoever did the identity proofing did it correctly by standard of care.
So when I ask the question will a physician who has done it be liable
and indemnify the lab or pharmacy or other provider. That\'s where
people start running for the door. So I\'m trying to figure out who \--
if you could help me with this issue, and who ultimately is going to
stand up and be liable for that identity proofing. Is it really going to
be physicians, or is it going to be somebody else?

**[\>\> Clay Shirky:]{.underline}**

It\'s an interesting \-- one of the questions you can ask about the
world as it exists today is do we have the PHR systems whose liability
is best worked out. Because the place we see PHRs most being distributed
in large \-- is in large medical groups, large clinical groups. And
certainly, both the IT expertise is high and the costs are syndicated.
But it may well also be that those are the institutions that have the
best environment for essentially providing the level of assurance.

You can imagine a small one or two doctor practice not in fact wanting
to stand up and say we will eat the entire liability for inpatient
proofing, and subsequent transmission of credentials.

We don\'t have a clean answer to that, in part because the world we
imagine is so different than the world we\'re in. But I think one of the
things we can say is that certainly some syndication of business risk is
going to be required for this, not just to look to the small doctor like
an unfunded mandate which is landing on their desk, there are lots and
lots of ways of syndicating that risk. You can imagine having a service
provider that offers this as a business relationship to multiple
individuals.

You can imagine both for profit and not for profit entities standing up
and offering this service.

So I think we share your sense that that risk is something to be
mitigated. I don\'t think there are good models right now for bringing
it down to the level of the small physician practice, to allow them to
offer this kind of value to their patients without making the risk
profile uncomfortable for them.

**[\>\> Peter Basch:]{.underline}**

Peter Basch, MedStar e-Health. I\'ve heard some conflicting testimony
about the problem with identity theft, whether it\'s increasing or
decreasing. Dr. Macaulay, you started your testimony with a call for the
healthcare industry to look at the online banking industry to set an
example. And Ms. Dixon, you talked and informed us about what I presume
is a growing problem of medical identity theft. I want to address this
question to the two of you.

First, Dr. Macaulay, could you educate us a bit more on where we stand
right now in terms of percent of fraudulent transactions, dollar amount,
that is fraudulently removed from our financial systems through the
online banking system? And perhaps even a rough sense of the number of
consumers who are touched by fraud on an annual basis, and whether
that\'s something that you think is gradually growing or disappearing.

And Ms. Dixon, if you could comment on your view as to how that pertains
to the problem of identity theft.

**[\>\> John Macaulay:]{.underline}**

This is John Macaulay. Not having the metrics at hand, I can tell you
that the general trend, and drawing largely also from the AHIMA document
that I referenced in my testimony, that there\'s a growing \-- I should
say a trend downward in terms of theft versus number of online users of
financial services community.

And in fact, we can draw upon our experience that the level of
sophistication of theft now, when we see the proliferance of the
annoying phishing e-mails that hit all of our e-mails now, is actually
an indication of the positive. Because those types of scams rely upon
operator intervention. In other words, spoofing of \-- and actually
intervention. So what that tells us is there\'s a lower incidence of
high-tech fraud, where people\'s accounts are being emptied without any
of their intervention at all.

So that\'s actually \-- you know, I admit it\'s annoying to all of us to
get those phishing e-mails, but actually it\'s evidence that we\'re
winning the war to a certain extent in the financial services industry,
because the high-tech forms of no touch by the operator are \-- we\'re
overcoming that.

So \-- and this is my story, and I\'m sticking to it \-- that the
financial services industry on the whole is experiencing lower incidence
per capita of online theft.

**[\>\> Pam Dixon:]{.underline}**

I think that\'s right. I think for some time now that the financial
industry has really clamped down on fraud. There is some extraordinary
analytical products out there that are doing this in real-time. It is a
very, very extraordinary level of personal data to do so, I think it
would make you uncomfortable to know how much. There are products, for
example, Fair Isaac has an extraordinary product that, I mean, it\'s
reduced the level of credit card fraud to less than one percent. Now,
this of course is in the financial sector, and there\'s plenty of
indication from the FTC survey in 2003, their identity theft survey
found 10.1 million people who are victims of identity theft. In 2004,
the Javelin survey, which is very similar 9.3 million, 2005, 8.9
million. So you find that those numbers are going down. And I think that
I concur with that, I think those numbers are going down.

But what\'s really happened is that the fraudsters are moving into the
medical sector. The medical sector is a place where you can find much
better cash payout than in the financial sector. A criminal who goes and
steals a credit card can make on the average of between 2,000 and 2,500
dollars. A criminal who goes into the medical sector, the averages are
around 1 million to 10 million dollars.

So I mean, if you were a criminal where would you go? You would go to
the medical sector. And the majority of cases are organized crime at
this point.

We think it\'s growing, unfortunately it\'s very, very, very difficult
to track because no one is really doing national \-- you know, cohort
studies on this particular crime. We\'re basically begging the FTC to do
this kind of study, and we really hope they do.

**[\>\> Peter Basch:]{.underline}**

Could I ask a followup question? Dr. Macaulay, so your point is that the
online banking industry has been aggressively pursuing this problem for
years, and thus making a \-- I would say a very significant dent in
fraud. Whereas Ms. Dixon, you\'re saying that we need to begin to pay
attention to this problem now, even though for many of us until today we
were not even aware of it.

**[\>\> Pam Dixon:]{.underline}**

That\'s correct. Yeah, the Centers for Medicaid, CMS, is very
interesting case study. Dr. Malcolm Sparrow from Harvard has written a
definitive book about fraud in the CMS system. And he found that fraud
was so high that he numbered it in the tens of billions, but he wasn\'t
sure how many because he couldn\'t really count it. This is after doing
an exhaustive study on fraud in the system. So there are a very
interesting number of statewide studies on fraud, particularly within
the digitized health care system. And basically his assertion is this:
What\'s really happened \-- CMS cares deeply about fraud, it\'s not like
they don\'t care; they care deeply. And they set a system up, and
here\'s how it works. So you\'re a crook, you turn in a file and you
bill for, let\'s say, Xanax or something, but the patient never ordered
it. You get caught.

So what the crook does is they don\'t lie once, they lie twice. They lie
in the medical file, then they lie to the biller, the person paying the
claim. In doing this, they effectively sidestep all the fraud detection
system, because it goes back to the architecture thing, trusted
architecture, just whole different framework. The financial sector
doesn\'t really work on that framework. But I have to tell you the
financial sector has worked on fraud for over 20 years, and really some
of this work began overseas, and we\'ve kind of picked up on some of the
progress that\'s been made elsewhere.

There\'s been good progress made and I think it\'s very positive, and I
really hope that we do this in this sector as well.

**[\>\> John Macaulay:]{.underline}**

I have something to add to that. This is John Macaulay again. I\'d like
to just pose one example of what the financial sector has done that
really literally speaks to the empowering of consumers, which is really
what we\'re talking about here. Because it\'s incumbent upon the
consumer to be aware of what\'s going on. To the extent what we found in
the financial services arena, like with some of the mechanisms that
Ms. Dixon was talking about, is that if you can give the consumer,
patient, a real-time fraud alert \-- in other words, access to their
record \-- you shorten the fraud cycle significantly. And that\'s
exactly what has eliminated or radically minimized fraud in the
financial services arena.

**[\>\> Pam Dixon:]{.underline}**

I have an interesting anecdote for you. And I apologize for using an
anecdote instead of a statistic, but the statistics are very hard to
come by in medical identity theft.

There was a major breach in the Providence health care system, you\'re
probably aware of it. Here\'s the really interesting thing. We looked at
that breach very closely, and the reason we focused on that breach is
because there was actual identity theft as a result of that breach. Not
all breaches result in identity theft, contrary to popular opinion. But
this one did, and it was almost instant.

What happened is that there was patients who \-- Providence did the
right thing, they signed people up for fraud watches, in real time. And
what happened is that patients immediate \-- a plethora of them, were
immediately contacted with two fraud alerts.

First was change of home address, or billing address. Second one was
change of phone number.

So they didn\'t get their financials impacted right away, they got their
billing address impacted right away. And this we discovered through an
interview with law enforcement in healthcare fraud. The first thing they
do, they change your billing address so you don\'t see the bills.
They\'re smart, they\'re sophisticated. We\'re not talking about mom and
pops here, they\'re experienced and they know what they\'re doing.

But in the Providence case, they \-- a lot of victims were alerted
through this system.

There\'s a second very interesting thing out of the Providence case, and
that\'s this. And I haven\'t seen it before, maybe it exists, but I
haven\'t seen it before. In this particular hospital breach, recently, I
believe it was just last week or the week before, it\'s very recent,
they added a service called credit restoration. I\'ve never seen that
from a hospital before. And that\'s kind of the red flag, oops, there
was identity theft that occurred from this breach.

So I think it\'s a very interesting case study, and we can probably all
learn a great deal about it, about how, you know, patients can find out
and, you know, it\'s going to be important going forward to look at
them.

**[\>\> Kirk Nahra:]{.underline}**

Is there a question from anyone on the phone?

**[\>\> John Houston:]{.underline}**

No, I don\'t, this is John Houston.

**[\>\> :]{.underline}**

Any other questions for the panel? We\'re right about at our ending
period. Okay, I\'d like to thank the panel very much, and I appreciate
you coming in and doing this on short time frame for us, and being so
helpful and cooperative. Thank you very much. We\'ll take 10 minutes and
try to be back here and start up again in 10 minutes.

\[break\]

**[\>\> Kirk Nahra:]{.underline}**

If people could take their seats, please, we\'d like to get started.

If people could go ahead and take their seats we\'d like to get started
with the next panel, please. All right, we are ready to get started with
our next panel on identity proofing and user authentication methods to
provide access to current and historical laboratory results and
interpretations in electronic health records. We have another esteemed
panel with us this afternoon, we certainly encourage to the extent you
can summarize, most of us have seen the testimony, and have read through
it, so happy to hear everything you have to say, but again, if you could
focus on the particular issues and the particular questions we\'ve asked
the panel to discuss. Again, I think we\'re going to go I guess from my
left to my right across the table. If that\'s all right with the group.
And I\'m not sure I\'ll be able to get your name right, is it Zaroukian?

**[\>\> Michael Zaroukian:]{.underline}**

Perfect.

**[\>\>]{.underline}**

Why don\'t you go ahead.

**[\>\> Michael Zaroukian:]{.underline}**

Thank you to all of you for inviting me to share my thoughts on the
process of identity proofing and user authentication for lab results and
EHR systems. My perspectives are going to be informed by the various
roles I play, which include the direction of implementation of an EHR
system in a large public university. My own role in primary care with my
own patients with electronic communications, secure messaging and
patient portal viewing of their own components of their record. Also,
finishing as national president of an EHR user organization and the
perspective that they need for what works for them. I\'ve also
participated in a university cyber-security initiative and privacy
board, and also serve at the moment as a principal investigator for a
RHIO planning grant in the Michigan area.

In response to the first question, I do agree that identity proofing and
authentication methodology should differentiate based on the data
reception method and the interconnectivity of the systems. I think the
results that come directly from a lab reporting system and into an EHR
system, and autopopulate the structured data fields, would not need to
have the same individual user ID proofing and individual methods.
Instead, I think you could leverage the processes that are inherent in
each recipient\'s EHR system, but again, the critical nature of that to
security as you go across systems would be very important.

It\'s a very different situation when a person directly accesses a
laboratory source system through a secure Website, and to insure high
assurance identity proofing is an important requirement I believe for
the initial site registration. Then of course repeated use of high
confidence authentication for each log-in.

The manual transfer of results from a lab system to an EHR carries
additional substantial risks, both to data integrity from people who are
in good conscience trying to do it right, but manually, and important
patient safety errors if it\'s done incorrectly, or even maliciously.
But the final decisions in this I think need to be reflected in some of
the conversation I heard earlier, in some of the testimony I read from
earlier today, and that is the notion of considering the impact in terms
of the authentication errors, threats to safety, threats to reputation,
et cetera. The overall likelihood that those errors will occur, and the
cost of implementing the strategy that you\'re expecting your users to
be able to operate under, and the burden it places on them each time
they use it.

So the act of querying the data is an important one. I think it changes
a little when you get to an EHR system of a colleague of another user.
In that situation I think you\'re needing to deal with the conditions
for working together.

If you have a centralized process for user authentication and identity
proofing that runs across the community, whether it\'s RHIO type or
other health information exchanges, then I think you have an efficient
process for doing that. But in the absence of that, in the interim,
there are important issues with regard to following policies, and those
policies could differ from one EHR system to another.

So for example, at Michigan State we might set a certain nature and set
of requirements, and that could be very different from a hospital or
another private practice\'s system. And that could create all sorts of
unmanageable types of authentication issues, as well as a whole set of
vulnerabilities across systems.

In terms of turning to the question of private industry EHR services and
expecting them, if you will, to comply with Federal information security
practices when importing data from the Federal agencies, I think that
expecting that kind of compliance is acceptable as long as the existing
statutes allow for the efficient access of authorized users at a
reasonable cost. However, if the existing statutes impose an undue
burden in this regard, then I think we need to be very careful to make
sure those are amended before they\'re required.

In terms of whether we should be expecting different kinds of
authentication for patients and clinicians, I do think that it\'s
important to respect the difference between patients and clinicians with
regard to what their tolerance is, what they perceive to be the needs,
and their own competencies, if you will, with regard to their skill at
using computers, at protecting computer information, the assets that
they may have, the IT support to be able to do the kinds of
authentication that is being expected.

And I think you can certainly expect higher amounts of that for
physicians and other system users, both because of the ability to do
organized training and the ability to provide some assets with regard to
the authentication process.

The burden of authentication, I heard mentioned earlier, I think it\'s
less critical perhaps for patients who would be occasional users of a
system and only authenticate once in awhile, but for the physicians and
other staff who might be accessing a system many, many times a day, the
efficiency of that process needs to be high, and the burden needs to be
low. Otherwise, I would see them as either being underused \-- which
would be a, if you will, a waste of the effort \-- or worse, that you\'d
start to see the same kind of authentication workarounds that we see in
other areas of passwords and other uses of computer systems, and that
would lead to a worse situation.

In terms of whether the DHHS should play a role in establishing
guidelines as opposed to industry self-policing in that area, I don\'t
see them as mutually exclusive. I think they can exist in cooperation
with each other. And I certainly as a provider myself, and I think many
of the people that I\'ve talked to, would welcome the kind of
intervention, if you will, or certainly assistance with clear and
practical guidelines that they can implement in their practices.

I think what physicians are likely to resist is the notion of imposing a
specific set of regulations, particularly if they prescribe a specific
type of identity proofing or user authentication that may not be
practical in an environment where an individual is practicing, or with
the patients he or she is serving.

I believe the certifying commission for HIT probably can play an
important role in something that would perhaps be more acceptable to
clinicians, in that we\'re already becoming more comfortable with the
certification criteria. And as those criteria advance and become more
sophisticated, I think sort of vetting the notion of new and more robust
identity proofing and user authentication components, with input from
the EHR and HIT industry as well as stakeholder providers, using latest
science and best practices incorporated into the criteria, is likely to
be an acceptable approach.

I heard some discussion earlier about the notion of in-person versus
online processes for identity proofing. I think that probably almost all
of us in healthcare at the practice level are much more comfortable with
in-person identity proofing. The one way that we\'re confident in most
of what we do with patients is the facial recognition that we have.
We\'re always the least certain when it\'s the first visit by a patient,
but the identity improves itself from visit to visit to visit. And it\'s
that notion of having a connection with the individual, and perhaps
multiple individuals in their medical home, at least their primary care
environment, might be one of the more robust ways to make sure that you
have the right person.

In my practice, we do require in-person identity proofing along with a
lot of the other methods that I heard earlier, to make sure that we have
the right person before we give out the essential credentials necessary
to register for the system for the first time, and that is a
hand-to-hand pass-off as opposed to anything that happens online. It may
even involve the initial registration in the clinic for patients who are
either uncomfortable doing it, or who may not yet have a clear sense of
the importance of doing it in a confidential way.

If we do it in that method, though, we are experiencing what I think a
lot of individuals are, and that is that it does increase the inertia.
There are some patients and some providers who won\'t bother if it takes
the kind of effort required to do authentication following an in-person
identity proofing. So we have to keep that in mind as we go forward.

I also heard some commentary about the banking industry. It certainly is
an example of approaches that are used for identity proofing and
authentication that could be applied to healthcare. I heard discussion
about two-factor identity, two-factor authentication, following identity
proofing. And certainly, the ATM card is a good example of a system
that\'s well-accepted and commonly used. So some method, if you will, of
taking something that you have, such as the card, and something that you
know, such as a personal identification number or PIN, is probably in
some way part of the solution going forward.

But we do have a challenge with regard to cards or other hardware
tokens, with regard to getting something out that\'s affordable, usable,
understandable, acceptable to individuals, and used on a regular basis.

But I do think we continue to struggle if we use single factors such as
password authentication, either by allowing simple passwords, or by I
think a danger of requiring too many password changes, and leading to
the workarounds that I mentioned earlier.

The FFIEC I think was described in the earlier testimony, The Federal
Financial Institutes Examination Council, with its guidelines. I do
think it also represents a set of guidelines that can inform our
processes. It obviously applies to a different industry, but some of the
principles are relevant. And they certainly were strong advocates of
two-factor authentication. But we still have to solve the practical
aspects of that.

My biggest concern is that without a cohesive approach, some of our
patients or some of our providers are going to have six USB keys with
minute to minute changing passwords, throw the whole thing away, and not
use any of it. So there is that issue to be concerned about.

Balancing accessibility with responsiveness to patient privacy concerns
is a huge juggling act. The reality in our environment is there\'s a
widely varying patient perception of this. We have patients who are very
comfortable sharing their most intimate detail across our public
non-encrypted system, despite the warnings and despite the presence of a
secure messaging portal. It I think underscores, number one, a
non-uniform concern that they have, compared to what I think we
perceive, and how to respond to that is an interesting question.

The clear message I think is that at least for a substantial portion of
our patients, the prioritization of convenience has to be kept in mind,
and it has to be kept very high in what\'s done, in trying to balance
that against the issues of confidentiality, and authentication accuracy
is going to be important. But I consider it a critical success factor.

On the provider side, I think at a minimum the combined burden of their
own identity proofing, their own user identification, and the results
retrieval process, has to be probably lower than the process of writing
the redundant order or test, or whatever, in order for these to be used.

And in my own environment, there are emergency physicians who could
access our portal very simply, but simply the inertia to doing that
versus what they\'re already doing appears to be too high.

So those are significant barriers. I do think that the healthcare
industry, one of the questions was the notion of the multiple assurance
levels, and whether doing something analogous to OMB Memorandum M-04-04
would make sense. I do think it would make sense, modified, for
healthcare. There is already sort of a model for that in terms of how
physicians are credentialed. I think Peter and I have had the experience
of trying to authenticate and identity-prove to a hospital both our
identities and our training and our experiences, and to certify all
those things before we\'re allowed to have privileges to do things or
the resources to do specific tasks.

At the same time, I would want to caution against recommending
strategies that require repeated authentication. The notion there is
I\'ve already authenticated to get into a secure system, now you want me
to do something else that\'s highly sensitive, and I\'ve got to
re-identify myself every time I want to do a specific act. And I think
many of us would be highly resistant to that, and would prefer that
another method be found, so that we don\'t have to repeat that task over
and over.

In terms of the issue of the type of collection of information, the type
of information that\'s held on to, and stored, I think was mentioned in
the last panel. My concern is the one that I heard elsewhere, which is
the identity theft. And so my perspective representing physicians is
that we would probably love to be able to provide the minimum amount of
personally identifiable information that\'s needed. And certainly, a
fraction at least of our patients would like to do so. And then the
question of how do we keep those securely maintained is critical.

And then finally, my concern also regards biometric data. I\'m not clear
that we know all of the potential ramifications of having our
fingerprints and thumbprints and voice patterns and all that stolen, but
the possible theft or misuse of them obviously can have wide
ramifications that could cause significant harm.

I heard something about the notion, if you will, of background checking,
and I sort of endorse that notion, but I think it\'s important, as well,
to be careful about background checking databases that might reveal
sensitive but irrelevant information for healthcare. And probably that
background checking should be for any provider, regardless of whether
they have access to an electronic system like that.

My other concern is the misidentification of an individual based on what
kind of looks like them, according to somebody\'s algorithm, but turns
out not to be, and has great damage to their own reputation or ability
to use the system.

So I\'ll stop there, and be happy to take questions as we move forward.
Thanks.

**[\>\> Kirk Nahra:]{.underline}**

Thank you very much. Ms. Jenkins, why don\'t you go ahead.

**[\>\> Liesa Jo Jenkins:]{.underline}**

Thank you very much for the work you all are doing. I come from an
Appalachian RHIO, Regional Health Information Organization, so what I\'d
like to speak to you today is really from two perspectives, neither of
which are an expert in security issues. So I want to point out that we
do have a couple of team members here from CareSpark as well. Alain
Sadeghi is the member of our team and our RHIO who really has guided us
and provided a lot of the information in the testimony that you have.
And also Chris Voigt from CGI, both of whom have worked with our team to
really address at the RHIO level some of the same issues.

But I want to speak first from the perspective of just a citizen, a lay
person, because that\'s how I come into this whole conversation. And to
let you know that I see very much the role that you need to play as a
committee, and what AHIC is doing altogether in building consensus, you
know, from lots of different directions about where the middle ground
is. It\'s not going to be 100 percent satisfactory for anyone, I think,
when the ultimate political decision is going to be around some of these
things. We\'re going to find some areas that most people can live with
and be the best stewards we can in making the decisions. So that\'s very
much how our RHIO has approached this, and I know that\'s the role that
you sit in today.

So I welcome the chance to share with you kind of the issues and the
things that we\'ve talked about in our region. Hopefully you can also
consider those same things as being ways to approach it from a national
level.

First of all, I think it\'s very, very important \-- and this has been
said over and over again \-- that we really do have to consider what is
the appropriate balance between the benefit and the risk. And in our
region in particular, where we have very poor health outcomes, where we
have high costs, where we have a lot of people who are uneducated,
without computer literacy, without, even some of our physicians don\'t
have access to broadband digital services, we continue to really
struggle against the access that people might have to use some of these
very things that we\'re talking about.

We have a lot of fraud and abuse. The gentleman from SureScripts I know
was kind of addressing some of those issues. Ours is particularly high
in the area of prescription drugs. So we\'re very concerned about those
kinds of things.

We have to balance the things that we\'re all working towards for health
improvements, cost savings, and a more effective healthcare delivery,
with all of the risk that you\'ve heard about today.

And I don\'t know about you, but if I were coming into this not so
convinced that this is an absolute necessity for us to do, I would
probably run out the door like Chicken Little screaming the sky is
falling, oh my gosh, I\'m not going to do this for the next 20 years
until people have figured out what to do.

Quite frankly, we can\'t afford that long. We cannot wait. We do have to
find the best solution that we can.

So where is that balance? We have approached it two ways, in our region.
First of all, we have people with expertise that are working with us to
figure out collectively through a regional health information
organization how we can spread the risk around, how we can collectively
pool our resources to share some of the cost it\'s going to take to put
an infrastructure in place. And a lot of the thought that\'s been given
to the security really did look at what is functional at the level of a
physician, or a nurse, or a hospital.

Secondly, what is it that we need to do that allows as much flexibility
as possible in the choices that are available for people to use for
authentication and access? So what a large hospital system is going to
use is obviously very different from the small rural practices, where
quite frankly, two-thirds of our physicians practice. So it\'s not going
to be the same in those kinds of offices, and we do have to accommodate
the variations that are there.

Thirdly, it is by necessity a mandate that we have to \-- we have to
support, we have to educate, not only our community, but those very
provider organizations that are responsible, that are held responsible,
and held accountable for what\'s going on. And right now, the
infrastructure is not in place in a lot of those small organizations.
They\'re very concerned about the liability. The physicians are the ones
who bear the legal responsibility for the records, and until we can help
assure them that they don\'t shoulder that total cost, it\'s not going
to be something that they\'re willing to take a risk to even participate
in.

I do think that the results from a very simple survey that we did were
very telling for us. We did not base our infrastructure decisions on
those results, but they did very much affirm what the conversation was
among all of those who were talking around the table.

And some very important points came out of that really simplistic kind
of survey. Number one, people are willing to share an amazing amount of
what I would consider sensitive information. But the person that
they\'re willing to share that with is their doctor, or their nurse.
That\'s who they trust with that information. And that\'s who they hold
accountable for the security of that information. Not government, not
the regional health information organization, not the IT vendors, they
hold their doctors and nurses accountable for the information.

Knowing that that\'s what the public perception is, has to be taken into
account. They\'re the ones who are going to be sued when the information
is accidentally released.

Secondly, they also said that the way they prefer to give permission for
their records to be in the system \-- in other words, in all the jargon
that\'s been going around today, how are they going to be authenticated,
how are they going to be entered into and access to the information,
their preference is to do that in the doctor\'s office. They want to
sign a piece of paper, they want to be there in person, that\'s how they
want to get into the system. And that was overwhelming in what that was.

And then finally, when we ask them about what do you perceive the
benefits to be, what do you perceive the risks to be, and we provided
them with enough choices, really, to look at to consider, then we also
ask them, you know, would you be willing to share your information. And
guess what. 98 percent said yes, they would share some pieces of
information. Varying \-- varying kinds of information around there, but
only two percent of the people, having considered all these things,
still said I don\'t want any information in the system.

Now, those two percent are very important, there\'s no doubt about that.
We have to have safeguards to make sure that those two percent have
nothing that goes across. But 98 percent of the people, general public,
are very willing to accept the risks, knowing what the benefits are to
them. As long as they understand what the benefits are to them.

So what do we do for those two percent? Our RHIO, in planning our
infrastructure, has dedicated a lot of time to thinking about how is it
that you prevent any information from coming across the system, and
being shared, for a patient who does not want that. And I think we have
some creative solutions. I won\'t even pretend that I can explain to you
how all they happen, but I \-- some very good people, very smart people,
have looked at this and validated what the plan is.

So what I want to close by saying is that one of \-- one or two key
things that I see are absolutely a necessity. We have to find a way to
help the physicians \-- and they need the list of lab results, they need
the medications, they need all those kind of things. But that\'s not who
the patients hold responsible. So we have got to have resources in place
to help the physicians and hospitals be secure. To the extent that they
can, without losing functionality and without losing the desire to
participate.

Secondly, it is a process, it\'s a journey of educating folks. When I
started into this whole arena three years ago I didn\'t understand any
of these issues. I have myself been educated, and I\'m very confident
that there are people out there who will also, like me, begin to
understand what the implications, the risks are, and make wise choices.
We look to those of you who have the expertise to help us understand,
and help us make good choices.

But I would leave you with this appeal from our region. We cannot wait
until we have all the answers 100 percent. We can\'t. And I think we
just need to be very honest, in saying we\'re going to do the best we
can with the resources we have in place, with the level of comfort that
people feel right now, this is where we can start.

And if you on the committee can help us, we will do our best to educate
on the ground about what those are, why they\'re important, and other
issues that need to be taken into account in our region. Thanks a lot.

**[\>\> Kirk Nahra:]{.underline}**

Thank you very much, Ms. Jenkins. Dr. Jolly?

**[\>\> Paul Jolly:]{.underline}**

Thank you very much, good afternoon. I\'m a staff member of the
Association of American Medical Colleges, where I hold a title as Senior
Associate Vice President. AAMC is a nonprofit association representing
all 125 U.S. medical schools, all 17 accredited Canadian medical
schools, and a whole bunch of other people in academic medicine. It\'s
all spelled out in my written testimony, but we represent all of medical
education.

By identity proofing, we understand the binding of an identity to an
actual person. This is done at the hospital when a record is made of a
birth, and it is done again at the motor vehicle administration when a
driver\'s license is issued. The MVA usually requires a copy of a birth
certificate, which proves that a person with the claimed identity was
born, but the MVA has no way of knowing that the person who presents the
birth certificate is really the same person identified by the birth
certificate.

The person who is the applicant is bound to the identity with a
photograph, accompanied by the issuance of an identification number. The
MVA then issues a token, the driver\'s license, that may be used for
authentication.

From this time forward, a person in possession of this driver\'s license
and resembling this person can successfully claim that identity. This is
kind of a model for what we do generally in all kinds of identity
proofing and user authentication.

The procedure for a passport is similar, and in some ways not as strong,
as the photograph is supplied by the applicant and not taken by the
agency at the time the passport is issued.

The Association has considerable practical experience with identity
proofing and user authentication, gained in the operation of its several
computer-based systems. In particular, the conversion of the Medical
College Admission Tests to electronic testing.

Our experience with this high stakes examination may provide lessons
that will be applicable to the healthcare professional and consumer
access to electronic health records.

Identity proofing for the MCAT exam is based primarily on examination of
a driver\'s license or passport, which takes place when the test taker
appears at the test site. Our proctor of course compares the photograph
on the document with the person\'s face, but we also read the encoded
information on the back of the driver\'s license, and the magnetic strip
or bar code that appears thereon. In this way we can identify certain
kinds of fraud that would easily be attempted by someone trying to use
someone else\'s driver\'s license, for example, to pretend to be them. A
driver\'s license with altered name or address would be exposed.

For future identity proofing, the MCAT has for many years collected a
photograph supplied by the examinee, and has obtained an inkless
thumbprint on paper. As we make the transition from paper and pencil to
a computer-based exam, these procedures are being strengthened. We will
now capture a digital photograph and digital fingerprints of both index
fingers of the test taker when he or she first appears, then use these
biometrics to verify identify \-- identity identification, when a test
breaker returns from a break or appears for subsequent examinations.
Most importantly, we intend to use the biometrics to verify the identity
of students who appear for matriculation at medical school. We want to
be sure that the person who shows up at the door of the medical school
is the same person who got a good grade on the MCAT, not his brother or
his friend.

Strictly speaking, we can never be any more certain than we were at the
initial identity proofing that a person owns the associated identity.
That\'s not terribly sure, with the systems we have in the United
States. But we can assure with a very high confidence that the identity
has been consistently maintained. If an examinee successfully assumes
another\'s identity at the time of the examination, he or she would have
to continue to use that identity throughout medical school and beyond.
Because we enroll the identity with biometrics very early in a
physician\'s career, it is less likely that a person would be motivated
to assume another\'s identity in the first place. As you can see, the
procedures we\'re using are somewhat stronger than the ones you\'ve been
hearing about so far.

An additional form of identity proofing that we have considered but have
not implemented relies on the existence of a considerable quantity of
publicly available data connected to identities. We might ask the
applicant a series of questions that others would be unlikely to know.
Sample questions might include, in which of the following cities have
you never lived. Followed by a list of four or five cities.

Or, if you come out of your front door and turn right, when you reach
the street in front of your house, what is the name of the first
cross-street you would encounter.

We can make up questions like this based on public records, and the
credit reporting industry is doing this to some degree.

We\'ve not used this method, in part because the young people who
present themselves for the MCAT don\'t have extensive public records.
But this kind of thing could be used for remote identity proofing in
some cases.

To accomplish the level of authentication described above, the
Association will create a centralized database of identity and biometric
data to be accessed by medical school registrars and other authorized
persons whenever a student needs to authenticate his or her identity.
The fingerprints will not be submitted to the FBI, and will not be used
for background checks. We emphasize to the student that the use of the
digital fingerprint protects them from identity theft whenever it can be
used, as no one else can successfully masquerade as that student. As I
should emphasize that we use the fingerprint for observed fingerprint
taking, so that some kind of an electronic capture of the fingerprint
and substitution wouldn\'t work in our case. That\'s the kind of
spoofing that could be used.

Persons who hear about this system for the first time, including
students who wish to take the MCAT, may initially have some discomfort
with the idea. Maybe you have some discomfort with the idea, associating
it with privacy concerns.

In the context in which we use it, however, we have encountered little
resistance. The MCAT has been collecting thumbprints as a deterrent to
fraud for decades, and the new system is seen as a more modern way to do
the same thing. Students also recognize that this is a high stakes
examination where fraud is a threat, and they accept the need for
preventive measures.

It also helps to point out that fingerprints and photographs are not
really secrets. As we handle things in public places and appear in
public places, we leave these fingerprints and images everywhere.
They\'re not secrets at all.

For access to laboratory data and other components of the electronic
health record, there are potentially three types of users: The patient,
the physician who ordered the test, and a physician who is involved in
the patient\'s care, but who did not order the test. For access to the
data, we need not only user authentication, but authorization. And
that\'s already been discussed earlier.

For all three types of individuals, a user name and password or other
authenticator will need to be assigned by system administration. The
authenticator could be a simple password, but stronger methods are
available and used in some places. Houston Medical Center is a good
example, where PKI tokens are used.

If the consumer has access to his or her laboratory results from the
internet, it makes no difference if access is desired from home or a
distant city. For physicians affiliated with the health system of which
the laboratory is a part, the same the true. If it should be desired to
grant access to physicians unaffiliated with the health system, however,
new problems arise. The distant physician could register with the
patient\'s health system, but in-person identity proofing would be
impractical. A consulting physician with referrals from many different
places would have to sign up with many different systems.

The best solution for such cases would probably be some form of
federated identity management, touched on by earlier speakers, where the
new speaker would authenticate himself or herself through his or her own
information system, and then access the desired laboratory with his or
her identity verified by the physician\'s own system. This can get
highly technical, and other people know that and can explain it better
than I can.

The preceding comments have been general, but I can briefly comment on
two of the specific questions.

In reply to question three, it may well make sense to have more
extensive procedures for identity proofing of physicians than for
patients, because physicians will be ordering tests as well as reading
results, and because they will have access to confidential information
concerning patients. More extensive identity proofing for physicians may
be justified.

In-person identity proofing is definitely superior to a system that
provides online registration, because the picture or the identification
document can be compared \-- sorry, the picture on the identification
document can be compared with the appearance of the applicant for
registration. Where an electronic fingerprint will be used for
authentication, as it will be for a medical student at registration,
observed collection of the fingerprint prevents spoofing with a plastic
finger, a photograph of a fingerprint, and other kinds of frauds.

Online registration may be acceptable for consumers, where the
registration entity has access to historical records involving the
claimed identity. Knowledge of which would be unlikely to be known by
anyone other than the owner of the identity.

I guess for example, if the patient had already had some experience with
the health system, you could ask questions about those experiences, and
have the student verify that they know what experiences they\'ve had.

I believe AAMC\'s experiences with identity proofing and user
authentication provide some lessons applicable to access by physicians
and consumers. And I would be pleased to answer questions when the time
is appropriate.

**[\>\>]{.underline}**

Thank you very much. Mr. Hansen?

**[\>\> Mitch Hansen:]{.underline}**

Good afternoon, Paul Feldman, Kirk Nahra, committee members and HHS
staff members. We thank you for the opportunity to testify on behalf of
ACLA, which is the American Clinical Lab Association, representing
national, regional, and local laboratories. My name is Mitch Hansen.
I\'m a vice-president for enterprise systems at Quest Diagnostics,
Incorporated, which is the leading provider of clinical testing
information and services. Each day our 42,000 employees at more than 185
laboratories in the United States, Mexico, and U.K. process over 550,000
orders for laboratory tests. This aggregates to about 145 million
laboratory orders per year. And the majority of these transactions
experience at least part of their life cycle in a secure electronic
exchange.

These are processed through our Care360 physician portal, direct
Internet access to our systems, bridge services to physician practice
management systems, and direct CPU-to-CPU connectivity to hospitals and
large clinical practices.

We are one organization in the laboratory industry. As of June 2006,
over 100,000 laboratory facilities comprising over 5,000 individual
laboratories, including hospitals and physician-owned labs, were
operating.

Our industry is a pioneer in secure electronic exchange, and we are
conscientious stewards of the massive amount of Americans\' PHI that we
process on a daily basis. We thank you for your interest our
perspective, which is informed by our high volume of experience and by a
very pragmatic viewpoint.

Before going to some specific questions, I\'d like to address how our
current foundation identity management practices work, and voice some
general concerns.

For us, strong identity management is grounded in sound business
practice, which requires business agreements that specify key operating
information roles and responsibilities of the actors in the system.

We establish unique account identification to the degree necessary,
specific patient identification, and these are established in our
laboratory operating system environments. There\'s typically a training
and acceptance period that occurs with the lab, caregiver, and third
parties as required. So that by the time this exchange goes live,
there\'s some indisputable identities established in our extended lab
domain. Data sources are known, mapped, nomenclatures understood.
Physical devices, to the extent that they\'re available, such as
hardware, IP addresses, and VPN keys, have been authenticated, and
transaction timing and quality of service issues are assured by an
actionable service level agreement.

There are, to us, from our viewpoints, some costly and significant
challenges to address from a large base of known partners and systems,
to a broad pool of unknown caregivers and consumers in a broad network.
The introduction of the consumer into this environment presents a
challenge on the basis of volume alone, and without a national patient
identifier, presents some difficult if not impossible challenges for us.

We feel there will also be a proliferation of unique IDs as individuals
present themselves in multiple roles. For example, consumer, guardian
consumer. That same person may also be a physician, or what in our
parlance is a "copy to" physician, or could be an institutional
representative.

In this environment, consumer demand, as it grows, will also represent
issues and challenges even when we execute flawlessly, and there\'s some
speculative cases in the document.

As described in our structure today, we only can serve a subset of
clinicians who have authenticated identities. As this circle broadens in
an interoperable environment, we recommend robust credentialing,
preferably with some manual component so we can always answer three
questions with confidence: Is the requester who they claim to be? Does
the requester have a right to see the general information they want,
i.e. is this really a physician versus a reporter? And third, does the
requester have a right to see the specific data requested on this
specific patient? We are not aware of universally accepted operational
definitions at this point that will automate this process.

So to go so some specific comments on the questions, number one, we
think that regardless of the method of access, we would like to see the
method for authenticating requests for lab results to retain some of the
characteristics and assurances of our current processes. Because these
have been ones that have held up well under high volume, and we have
confidence in them.

This could mean an EHR or RHIO \-- and we are doing this today, in fact
\-- establishing the patient identity locally, and acting as trusted
agents of exchange with us.

One comment I think we would like to make sure is known is that the high
transaction nature of our business, and the quality of service that\'s
demanded of us, does not lend itself to opening to broad inquiry
operational laboratory systems. The type of access being contemplated
will typically mean creation of consumer accessible front ends or
separate data warehouses, which probably will be costly to develop and
operate from our perspective.

On the second question, to answer the second part of the question first,
we do believe that EHR-type services should comply with Federal
information security practices. And to echo something that Michael said
earlier, is that there needs to be some reasonable consideration of cost
and reimbursement models for everyone in this process.

There is a concern that we want to note from our experience in this
environment, that regarding whether or not Federal projects can
prepopulate with data, some of the EHRs. Many Federal projects today are
dealing with anonymized clinical data, at least from the laboratories,
which suggest that these may not present suitable sources for direct
feeds into EHR, but there may be other sources in there that would.

On question three, we note that CLIA differentiates access results based
on State law, and that therefore, we believe that proofing mechanisms
will need to be developed that are appropriate and strong at all levels
of access, and appropriate to role, regardless of what it is.

It\'s clear that \-- and this has been articulated, that physicians and
EHRs won\'t wind up assuming accountability of wrongful disclosure in
this model. And this is something we\'ve lived with in terms of lab
results since the launch of HIPAA.

Today we do not release to non-client physicians without some strong
review or compliance coverage, and the concern here is that without
achievable authentication services and well established identity schemes
and clearing processes, this will be as burdensome to the EHR, as it is
or could be to the lab.

Regarding the HHS role and guidelines, we would recommend some sort of
security standards, a la HIPAA so that they\'re clear and on the board
and understood by everyone. We\'d suggest, and I\'ve heard this earlier,
suggest some initial product certifications in the manner that CCHIT is
progressing.

We suggest also, and this is in consideration of the ongoing nature of
this, and putting many, many Web-accessible sites out there, there\'s
going to be some need for ongoing audits and external authentication of
the security of the Websites in order to engender consumer confidence.
And a reasonable model for this might be the patient credit card
industry PCI standards, as people are familiar with those.

The reasons for this is that both consumers and providers will want data
about standard security performance in order to generate trust and
confidence in the healthcare system.

Further, it can\'t be the responsibility of each individual physician or
supplier of information in the healthcare supply chain to validate and
verify compliance with all applicable laws and regulations of their
partners in exchange.

On question five, while we believe it\'s certainly true that volume and
customer expectation will drive us toward an online proofing process of
some sort over time, the concern that both identity and purpose of
disclosure requires some continuing need for manual interaction at some
level in the proofing process, particularly at the patient level.

We want to note some specific things about the laboratory industry,
here. First, I think it\'s true in general that some consumers, in fact
many consumers, may not know the full identity of all their healthcare
providers. This is definitely true in terms of the clinical laboratory
industry. Laboratories in particular do not often have direct contact
with many of their patients. This complicates our ability to
authenticate patients individually, as you can clearly imagine, and
there are some other factors in our business, such as referral testing
from lab to lab, that can further distance the service we provide from
the patient\'s knowledge, making it even more complex.

We think that frankly it\'s worth taking a look at what we do today as
an example of sound security practices, and we also think that there are
examples in the break-through projects, the RHIOs, and projects such as
ELINCS with the California HealthCare Foundation, where we are
establishing some standards at this time.

And outside the industry \-- well, outside the industry I reference PCI
standards for ongoing audit which could be valuable, and the CCHIT
certification process.

I guess one of the positions we would take that might be different here
is that we have difficulty arriving at a point where we feel there\'s a
trade-off between access and privacy. They\'re both independent
requirements. We understand the pressure to proceed, but with the
requirement for both a confirmed identity and a purpose for access known
to the data provider, there is \-- there\'s a need to sustain that
balance and keep both strong.

My final comments are regarding the type and storage of data, which are
referenced I believe in question nine. Obviously, interoperability by
definition means the exchange of PHI. We have a very vivid experience
with the costs of storing mass amounts of data. And in order to
identify, authenticate, store, and manage the volumes of PHI that are
being contemplated from our national perspective, is quite a costly
proposition. In addition, we need to sustain sound operating practices
to ensure recoverability, as well as performance of this mass storage in
a queriable environment.

So these are major costs that are going to proceed beyond just us, as a
large provider, and affect many, many smaller RHIOs and agencies as
well.

In conclusion, Quest Diagnostics and the American Clinical Lab
Association appreciate the opportunity to present our views this
afternoon, and we look forward to working with the administration to
meet the goals of the community in this effort. Thank you.

**[\>\> Kirk Nahra:]{.underline}**

Thank you very much to the panel. We now have some time for questions
from the Workgroup, and other comments.

Any questions to start us off? Peter?

**[\>\> Peter Basch:]{.underline}**

I\'m Peter Basch, MedStar Health. Questions about burdensome nature of
two factor authentication, and use of device and/or password and PIN.

In my relationship with my bank, I cannot choose to say I find an ATM
card burdensome, I just want to use a PIN. Or I just want to use a card,
I can never remember my PIN, so I take responsibility. They won\'t allow
that.

I also find it somewhat burdensome when I go to an ATM machine and enter
my PIN and perform one transaction, and then decide I would like cash
withdrawal, they ask me to reauthenticate. And I understand why they do
that.

A previous panelist commented on the true cost of medical identity
theft, and certainly while some patients might not see it as a real
issue, I think we\'re being asked to consider it for the serious nature
that it presents.

So my question for the panelists are, number one, what is your
experience with use of two-factor authentication for both providers and
for patients? And if providers and patients were educated as to just how
important it was to protect this data, do you think that we might get
further acceptance of two-factor authentication?

**[\>\> Michael Zaroukian:]{.underline}**

Well, I certainly have a couple of views on it. I don\'t actually have
any personal experience with two-factor authentication for providers,
other than some of what I witnessed with regard to USB keys that have
minute-to-minute changing passwords. And I\'ve seen a little of that,
and that seems to fall within the realm of acceptable burden for
particular users, at least if they\'re users who keep them on their key
chain. If they leave them at home, that can be problematic, but that\'s
always the issue.

So from that perspective \-- and I would agree with you, Peter, that the
notion here is that it appears that the single authentication approach
really is too risky. I think if it\'s robust enough you can reasonably
expect authentication to happen once, except for very high stakes tasks
and key issues to decide that.

I think one of the biggest concerns is who is going to pay for this.
Right now I think those USB key examples are roughly 50 dollars a piece,
and part of the reason you and I are willing to use our ATM card is
it\'s free, and it isn\'t a high cost to those who provide it to us. And
we\'ll need to solve those problems as well.

**[\>\> Mitch Hansen:]{.underline}**

Just a comment. Obviously we have some cases where we have implicit two
factor authentication, because we\'re going through a VPN channel or we
have physical hardware in place. This is not an option that\'s always
available, and again, the cost I think is a driver in that environment.
And I find, as part of my job, candidly, within the company, there\'s
resistance to the notion of having keys for external access. There\'s
sort of the assumption that we\'re going to solve this problem without
such baggage. And that may or may not prove true. I think one of the
drivers that might help over time is that the cost of these types of
mechanisms will come down as they become widely adopted. And there\'s
more going on in Europe relative to these things, as well.

**[\>\> Liesa Jo Jenkins:]{.underline}**

The only thing that I would like to add there, our providers are
gravitating more and more to the idea of the PKI. They see federated
identity management as something that has a lot of advantages to it. But
I would also want to add something about the cost. Whatever the cost is
of assuring security, we have to recognize that it\'s going to be
multiplied many times over by what we anticipate in savings in the cost
of health care that we\'re seeing today.

**[\>\> Paul Jolly:]{.underline}**

I\'d like the add that there is a new kind of hardware that I think
offers potential for two factor identification, it\'s somewhat expensive
but would be suitable for physician identification. And that\'s a card
with an online \-- on-card fingerprint reader, the fingerprint is
actually stored on the card, and you have to put your finger on the card
in order to make it work. And it works with RFID, so it\'s not even \--
you could just swipe it with your finger on it.

That would be extremely convenient. It would be very hard to misuse,
because you have to have your own finger on it before it will work. And
those cards are available, I don\'t know what the cost is, but I\'m sure
it\'s a few bucks a card.

**[\>\> Peter Basch:]{.underline}**

Just a quick followup. If two-factor authentication is deemed too
expensive or too difficult for patients, do any of you have any
experience with either requesting or forcing strong passwords on
patients?

**[\>\> Michael Zaroukian:]{.underline}**

We do. The question is how strong is strong enough. I\'m not sure I
should reveal all of ours at the moment, since we use one factor for our
patient portal, but we do require something analogous to what you might
find on Microsoft Passport\'s password development process, where it can
show you as you make it increasingly complex whether you\'ve made it to
high complexity. So we do require that. And so far, the patients seem to
accept that.

**[\>\> Mitch Hansen:]{.underline}**

Most of what I described is related to our \-- you know, physician and
provider services. We have had \-- Quest Diagnostics did have a consumer
service \-- direct to consumer in several States, where that was
appropriate, and legal, for several years. And we did enforce what would
be termed \-- I would say minimally strong password authentication. It
was not \-- this is several years ago, and it was appropriate to the
standards at the time. I\'d be a little nervous about it today, to be
candid with you. But it basically enforced it by having the initial
registration set up, confirmed by mailing, back out to the physical
address, and the reentry at that point, and final account set up.

So, you know, there are ways to work at a \-- but there\'s still a
deterministic point for that account, I guess, compared to some of the
other concerns that I raised. Where we know when John Doe signed up and
went through that process, as opposed to many other types of inquiry
that might occur from an unknown source.

**[\>\> Michael Zaroukian:]{.underline}**

The thing I would add briefly is the patient\'s willingness to do
complex passwords in our experience is inversely proportional to how
often they have to change the password. So you have to change it
frequently, it will not be accepted well.

**[\>\> Kirk Nahra:]{.underline}**

One thing I\'d like to just ask about at this point. We\'ve heard a lot
about, on the physician side, about authentication standards and we
heard from the last panel some of the issues about insiders and identity
theft. And one of the issues, it seems to me is, you know, those people
may be authenticated, they\'re just doing things they\'re not supposed
to do. And so we haven\'t heard anything I think from any of the panels
about sort of the back end. How do you track that. I\'m wondering if any
of you could touch on any of the back end off that authentication. Do
you have the ability to figure out where people have gone, once they\'ve
been authenticated? Because again, in a lot of the ID theft settings
that\'s going to be the problem. It\'s the right person, they\'re just
doing the wrong thing.

**[\>\> Mitch Hansen:]{.underline}**

You\'re asking about the internal management of the system in the
operating.

**[\>\>]{.underline}**

Right, if someone in fact is, you know, appropriately hired, they were
hired to do a job, they were there and they\'re just taking stuff
they\'re not supposed to. Would you have the ability to go in and track
that, figure out what they did?

**[\>\> Mitch Hansen:]{.underline}**

We have extremely stringent security policies for internal employees as
well. Which is not to say there\'s never a problem with an internal
employee. But yes, we do, we have internal tracking of systems. I mean,
I\'m not \-- I would qualify that by saying I don\'t know exactly what
your request is, but the answer is we have security appliances that are
attached to the network, we track by network, we have device IDs for
every computer in the company.

In essence, it\'s two-factor authentication for everybody in the
organization. With quite an investment in internal security, because we
view internal security as important, candidly, as external security. In
fact, most breaches occur from inside organizations.

**[\>\> Paul Jolly:]{.underline}**

I think I know what you\'re asking, and I believe we do do that to some
degree. We have some sensitive information, in that we have Social
Security numbers of medical students, for example. And not every member
of our staff who can use the network system is authorized to see those.

So we have a controlled list of who is authorized to see it, but we do
log all accesses to those sensitive data, so that if someone is looking
at systematically for Social Security numbers that they have no reason
to look for, we would be able to detect it.

**[\>\>]{.underline}**

I guess a follow-on question to that. I would assume that for most
tracking systems internal to the employees, it\'s relatively easy to do
that on the employee \-- at the employee level. But for external
queries, is that as easy to do on individualized basis, or is the
technology still looking at that simply as an entity inquiry?

**[\>\>]{.underline}**\
If an internal user is identified and authenticated, we certainly can
track that just as easily as we can an internal user.

**[\>\>]{.underline}**

But by individual not by \--

**[\>\> Mitch Hansen:]{.underline}**

Yes, by individual.

**[\>\>]{.underline}**

A strategy we use, we do have a tight audit trail and we do a number of
different algorithms such as is this individual at this hour of the day
authorized to use it. For example, a staff member at 11 o\'clock at
night, are they in the right clinic, is this a patient that has been
seen by that provider, or for whom that is the responsible provider. Is
the pattern of information that people \-- that a person is looking for
similar across a broad range of patients without a clear and obvious
indication match against policies and then queried. And we actually have
had some terminations related to people who couldn\'t explain
satisfactorily what they were doing and why.

**[\>\> Liesa Jo Jenkins:]{.underline}**

And I guess I would say that in our region that we are very aware that
many of the small providers have nothing like this, and it\'s going to
be a long time before they do. So we see the role to be for the RHIO to
help kind of centralize and share some of those resources. And that\'s
very much in the direction that we\'re working. We know it\'s not
feasible to put that at the local provider organization yet.

**[\>\>]{.underline}**

Yeah, I wanted to ask a question specifically about CareSpark, in terms
because you do have that spectrum of solo physician practice all the way
up to hospital, and obviously different resources associated with that,
to what extent are the basics of identity proofing and user
authentication similar or even identical across that region?

And if you \-- you know, I assume, and maybe incorrectly so, that there
are certain minimum standards that have to be met. To what extent does
that spectrum of care providers, are they able to all do the same basic
things as it relates to, okay.

**[\>\> Liesa Jo Jenkins:]{.underline}**

I think that is very much \-- we\'re not exchanging data right now
through the RHIO, I have to say that. So we\'re just now defining the
policies, but that is very much the role that we see in our RHIO is to
help set \-- help educate people about what the minimum standards do
need to be, and kind of have some centralized resources that can support
the smaller providers to get there.

The larger providers that we have, the hospital systems, for example,
are \-- you know, sophisticated enough, and they have staff, and in fact
recent conversations with them is can they play a role in helping our
single physician offices and stuff with some of the resources that they
have.

**[\>\>]{.underline}**

Paul?

**[\>\> Paul Uhrig:]{.underline}**

I want to follow up on the audit question, it appears to me there\'s a
distinction between an audit, if somebody says there\'s a problem and
you go back and look and you can see who has gone to information; and
affirmatively detecting problems. Do you have systems that will flag
there\'s an issue, you can go look, or is it only retrospectively once
you know there\'s a problem?

**[\>\>]{.underline}**

The answer is yes and no. It depends \-- it\'s more pull than push
technology, and I think CCHIT can help us with regard to EHR criteria
with regard both to what kind of audits are possible and what kind of
reporting is automatic and is pushed back to the users.

We can see on a regular basis, because we look on a regular basis. And
we have reports, if you will, set up to be able to look to see various
of the common and important ways that somebody might misuse the system,
whether accidentally or deliberately.

But it is not the same as a dashboard, if you will, where a light goes
on and there\'s an indication that a specific individual appears to be
using it in an atypical way, and I think that would be an advance.

**[\>\> Mitch Hansen:]{.underline}**

Just a comment that we use preventive detection methods but I\'m not
quite sure it\'s exactly what you\'re requesting. In other words, we
have \-- we monitor the security environment to see whether there are
any break-ins or \-- you know, security events occurring. It\'s a little
harder to detect that if something that looks like a reasonable \-- you
know, somebody with proper rights is in the system, but is misusing it.
That\'s a little harder to do.

**[\>\> Paul Uhrig:]{.underline}**

Yeah, I\'m really going to the lab, or if someone asks you \-- you know,
query, things like that.

**[\>\> Mitch Hansen:]{.underline}**

I would agree, there\'s no \-- no dashboard that\'s going to light up
for us on that particular type of question at this point, that\'s more
of a reactive measure.

**[\>\>]{.underline}**

Alison?

**[\>\> Alison Rein:]{.underline}**

Alison Rein, National Consumers League. Earlier on, I think it was
Michael\'s presentation, you were talking about the burden of repeating
the task of reauthentication, and I was wondering if you could give an
example, perhaps, of when you think it\'s overly burdensome, and
appropriately burdensome?

**[\>\> Michael Zaroukian:]{.underline}**

Sure. One of the best examples we heard in terms of one State that\'s
dangerously close to Michigan, that is, has a board of pharmacy that is
going to require that physicians reauthenticate themselves every time
they want to prescribe certain things. Like a narcotic prescription, et
cetera, et cetera.

And although if you think about it, on the one-time level that doesn\'t
seem such a big deal, the whole notion is if you can\'t get in there in
the first place, because you have role-based permissions to do these
sorts of things anyway, and since you can audit it in a robust manner,
why the need for authentication, and whether that really represents a
barrier to doing things in a manner that\'s already not feasible within
the EHR system, is one example.

Rather than authentication for chemotherapy, as an example, incredibly
potentially dangerous if done wrong, et cetera, et cetera, the notion of
having to have it signed off by two individuals with appropriate
privileges would be an alternative strategy for those things that are
really high stakes.

**[\>\>]{.underline}**

Are there questions from anyone on the telephone? Are there other
questions from the group?

**[\>\> John Houston:]{.underline}**

I don\'t have any. This is John Houston.

**[\>\> Kelly Cronin:]{.underline}**

I don\'t have any, Kirk. We\'re going to have time at the end to go back
over some other issues, if we wanted to. If there\'s time.

**[\>\>]{.underline}**

Yeah, we have a little bit of time at the end, and we\'ll have a wrap-up
on another occasion, as well.

**[\>\>]{.underline}**

Okay.

**[\>\>]{.underline}**

Steve?

**[\>\> Steve Davis:]{.underline}**

This is Steve Davis with the Oklahoma Department of Mental Health and
Substance Abuse Services. I was interested in the CareSpark survey, as
you indicated there was general willingness to share information, but
there were some categories where people were less willing, and it was
mental health and sexually-related diagnoses and infectious disease. I
was wondering if you had a chance to follow up to see whether there were
either policy or procedural or infrastructure things that people would
accept sharing that information more.

**[\>\> Liesa Jo Jenkins:]{.underline}**

The short answer is no, we did not do follow up with those individuals.
But we have had, at the table at our RHIO, the behavioral health
organization, and they have consistently said \-- and expect to be able
to share information through the RHIO. Because they point out that a lot
of the behavioral health patients are those, you know, most at risk for
being in poor health generally. And there\'s this \-- you know, a really
serious need for those patients not to be totally blocked out of the
system because they have some sensitive information in their record.
Even someone who maybe is not being treated by a behavioral health
organization may have sensitive information in the record.

What we\'re looking for is the technical solution to filter the
information appropriately, and at that time then to make sure that we
bring those kinds of records in.

That\'s a very difficult issue, but we hear over and over again the
pleas from the people who serve patients with those kinds of conditions,
how important it is for them to receive the benefits of the electronic
health information sharing, just like all the rest of us expect to do.

**[\>\>]{.underline}**

Other questions from the Workgroup?

**[\>\>]{.underline}**

I guess one final question. In terms of the burden there\'s been some
discussion on the physician side on the authentication burden. From the
consumer side, in terms of possible methods of identification,
verification, for certain classes of individuals, are there some methods
of identity verification that may in and of itself deter them from
coming in in the first place? And are we \-- are there other methods
that are equally as effective that would be less of a barrier for these
people? I just want to make sure that in pursuing identity we\'re not
closing off health care to portions of the population.

**[\>\> Michael Zaroukian:]{.underline}**

I think that\'s a really important question from a number of
perspectives. One is computer literacy, one is the ability to maintain a
secure computer with anti-virus and spam protection, so on and so forth.
The other is the type of equipment it might have, we might say a smart
card might be a simple easy thing, but is there a way to read it.
Similarly, thumbprint biometrics. If you look at patients, again, it\'s
very hard to see clear evidence that patients in general are willing to
do two factor authentication yet, I haven\'t seen any clear evidence
where that\'s the case. There are published studies that show that it
doesn\'t take an awfully high burden, if you will, for authentication
before people will stop using it, whether they\'re capable or not. Even
fully capable individuals will stop using it. So I don\'t know that we
have good data on that population in terms of studying it,
anthropologically, if you will. But it\'s pretty clear that of the data
that are out there so far, it can\'t be very hard for them or they
won\'t do it.

**[\>\>]{.underline}**

Lee?

**[\>\> Lee Partridge:]{.underline}**

Could I just ask a quick followup on that? Lots of people, particularly
older people, wouldn\'t have their own computers, but could access a
computer at a public library. Would that be possible in your system?

**[\>\> Michael Zaroukian:]{.underline}**

Yeah.

**[\>\> Lee Partidge:]{.underline}**

So you don\'t have to be in your \-- it doesn\'t have to be at home,
it\'s wherever you are, you can go with cyber cafe. Calling from
Morocco.

**[\>\>]{.underline}**

I want to combine a comment too that was made in an earlier panel
session about the necessity of planning so that you can have proxies or
guardians to interact with the system on behalf of the patients. If you
have patients that are illiterate, or so unhealthy that they\'re
incapable of doing it for themselves or lack the transportation to get
to somewhere, they still may be receiving some kind of social services
and be able to indicate \-- or someone could act as proxy for them. And
I would say whatever is done, that really is a necessity.

**[\>\> Kirk Nahra:]{.underline}**

Other questions from anyone in the Workgroup? All right, for both the
Workgroup members and people in the audience and listening, we\'re going
to adjust the schedule a little. We\'re going to take a break at this
point for 15 minutes, then we\'re going to come back and do public
comments. There have been people in the audience who have signed up to
do public comments in the room. We also have \-- we\'re going to have
the opportunity for people to do brief public comments on the phone. All
the public comments will be limited to three minutes per person. But
we\'ll be back in \-- I guess it\'s 5 after now, we\'ll be back at 3:20,
start up again at that point, thank you.

**[\>\> Matt McCoy:]{.underline}**

If there are some members of the public who are following the Webcast
right now and would like to make a comment, you\'ll see that there\'s a
phone number up on your screen. If there\'s a member of the public who
would like to make a comment and have already dialed into the conference
call, you need only press star 1 on your phone. As the chair indicated,
the Workgroup is going to be on a break for about 10 minutes, so you can
call in now, get into the queue, and then when the public comment period
starts we will get to your question.

\[break\]

**[\>\> Kirk Nahra:]{.underline}**

All right, we\'re going to go ahead and get started, if people could
please take their seats.

We are going to turn now to the time period we have put aside for public
comment. People have signed up for oral testimony in the room, we\'re
going to cover the people who are in the room first, and then if we have
time, as I think we will, we\'ll see if there are people on the phone.
All comments should be limited to three minutes. First speaker is
Ashutosh \-- can\'t remember \-- is it \-- from Deloitte?.

**[\>\> Ashutosh Ghogale:]{.underline}**

Judith Sparrow, co-chairs Paul Feldman and Kirk Nahra, distinguished
members of the committee, and the Community. Thank you for affording me
this opportunity, it is indeed an honor and a privilege. I applaud the
work of this Workgroup in its efforts of making the Presidential
directive for a decade of health IT a success. A lot of people and
organizations all over the world are following the developments that are
happening here. With new vibrance of global service providers, a trend
that has become a known financial services and information technology,
slowly finding (indiscernible) option in the U.S. health care sector, I
think it is best to plan ahead with foresight.

The progress that has been made over the year is a strong and positive
indication that the right steps are being taken in this direction. With
planning and cooperation, we can avoid some knee-jerk reactions on a lot
of issues that are bound to come up in this journey.

I would like to suggest having some advanced forums that will allow for
more active participation from people in organizations who are observers
right now, but definitely interested in active participation.

In closing, I would like to again thank the advisory committee members
for providing me the opportunity. I hope the comments and suggestions
will be beneficial to the community and will help forward the committee
and the Workgroup cause. Thank you.

**[\>\>]{.underline}**

Thank you very much. Next is Mr. Jacobs from Allscripts. Mr. Jacobs in
the room?

Mr. Sadeghi from CareSpark?

**[\>\> Alain Sadeghi:]{.underline}**

I\'ll try to go as fast as I can. English is my fifth language, so
forgive me for my strong accent.

The comment is that a lot of things we talk about, this hardware,
software, of course based on the vendor, they tell me that they make a
software-hardware makes breakfast for you next morning.

But the problem is not going to be solved. The thing is, as someone
says, security is a process, not a product. I would say a journey is not
a destination. You need to add to that confidentiality, integrity, and
availability, I would say CIA. Plus RIA: reliability, interoperability,
and accountability. And that\'s something that\'s very important.

Other words, we know that in the real world, it\'s going to be a
combination of the two different methodologies. You can\'t just find two
factor authentication, maybe it works for in big hospitals, it\'s not
going to work for a patient. So there\'s still the use of a PKI, it will
be a lot more useful, less expensive. I have some of the data that we
can get a dollar per patient per month to use a PKI? Is it going to be
100 percent (indiscernible) proof, there is no such a thing. Still it is
a lot better than nothing else.

And also, that privacy, again, is a business issue, it\'s not a
regulatory issue. But we need to have a regulatory, we need to have a
specific standard. The standard needs to be a little bit tailored,
because it can\'t be only NIST, standard coming from NIST, because one
doctor office, they cannot afford to do everything. So it has been to be
minimal security standards pushed by government, that it has teeth like
Sarbanes Oxley in the financial industry has teeth. So something gets
done, but methodology can be mixed from COBIT NIST, ISO 17799, 2071, so
it doesn\'t matter, it doesn\'t have to be one methodology. Each of
them, they have their strength and their weakness. So we need to
(indiscernible) specific things you covered.

Those are things we talked about we said there was no \-- the main thing
we have to look at again is about identity theft. It\'s not only about
HIPAA, it\'s not only about the health industry. Identity theft costs
the United States of America in 2004 69 billion, 2005 it was almost 65
billion, and we will find out how much it\'s going to be, I would say
around 70 \-- about 70 billion. So that\'s something that we cannot
deny. So we are responsible to basically accept accountability. And that
PKI facility thing goes to the patient, you are moving the
accountability to the patient. They have the key, the private key, so
with home they\'re going to share it, they will be responsible.
Basically everybody at any level, they have to accept their
responsibility. Thank you.

**[\>\>]{.underline}**

Thank you very much. Mr. and Mrs. Gropper from MedCommons?

**[\>\> Adrian Gropper:]{.underline}**

Hi, I\'m Adrian Gropper. MedCommons is one of the coming wave of
untethered or independent PHR services that Mr. Shirky discussed in the
Connecting for Health testimony. We are the consumer\'s privacy
advocate, and not the medical equivalent of a credit bureau. We want to
make sure that we\'re seen as one and not the other, the distinction I
think he tried to make quite well.

You\'ve already heard from NIH and Connecting for Health that federated
identity management is a solution to the scalability problem for
consumers. It may be the only solution, certainly the only one I\'ve
heard here today.

I\'m here to point out that personal health record services can use
existing federated management standards, such as Liberty Alliance
Project, to provide market-based solution to consumer participation in
the national health information network. In other words, that federated
identity management, in your guidelines, can catalyze the NHIN in a
relatively straightforward way.

What can do you? Consider recommending a link between the transfer of
private health information to the NHIN, or outside of the firewall of
the caregiving institution, to the use of a mutually acceptable
federated identity. This is the way you buy something with a credit
card, in effect. You offer whichever credit card you want, and the
merchant decides to accept it or send you on your way.

In other words, no information leaves the institution unless it\'s
labeled with an opaque identifier coded by a Federal identity provider
that is acceptable to the consumer. This could be, for instance, a cell
phone vendor, a carrier, or a bank. It doesn\'t have to be anybody
involved in healthcare, on either side of \-- that\'s what I mean
federated identity would do.

So in summary, voluntary noncoercive participation in NHIN will provide
valuable public interest benefits by preserving the trust of the
consumer. Federated identity management enables independent PHR service
providers to enforce the consumers\' informed consent. That\'s what we
see our role as being. The CCR and Liberty Alliance standards exist, and
market forces will drive their combination into nationally portable
personal health records and genuine consumer empowerment. Conversely
RHIOs and Stark Law exemptions promote bundling of PHRs with ERs, and
bundling limits portability and works against the public interest in
health quality, and transparency limits both innovation and scalability.

**[\>\>]{.underline}**

Thank you very much. John from GE Healthcare.

**[\>\> John Moerkhe:]{.underline}**

John Moerkhe from GE Healthcare. I\'m also the Co-chair of the CCHIT
Security Working Group, as well as a couple of other security-related
standards.

I\'m really glad to hear that you guys are not just focusing on the
technology but are also looking at the whole concept behind the identity
proofing. Because you know, it\'s really important that we do get some
standards, some guidelines on how to deal with that policy side of it.

I think it\'s also important that we look at the policy higher than
that, that guides, really, not just what data goes in, not just how
it\'s being protected, not just how you\'re being authenticated to it.
Because right now, I\'m seeing a lot of technology solutions that are
available, but the policies that bind those technology solutions into
practical realities are not necessarily there.

I want to stress a few points that I did hear today throughout the
testimony that I think are key. One is risk assessment, and dealing with
the problems on a risk oriented way. It is important not just because
it\'s the way security really should be done, but it also addresses
applying the appropriate technology to the appropriate risk. In some
cases we see really expensive technology being applied to a risk that
doesn\'t have a high likelihood of happening.

On the other hand, we also see where a technology is missing, that
really isn\'t very expensive, applied \-- not being applied to something
that really would happen quite often. So risk-based is very important.

One of the other pieces that was brought up here was there\'s some \-- a
lot of discussion around identity. And I was really impressed by the
fact that multiple panel members brought out the point, and Adrian also
brought out the point that federated approach is really the only way
that is sustainable, the only way that is scalable.

Within certain enterprises we already have mechanisms built into the
EHRs or built into the local entity for authenticating users. Extending
that trust out into the HIE or out into the use cases is important.
It\'s just a model that leverages what you already have today. And it\'s
a model that does scale.

One of the other things that was somewhat confused and stressed today
was the concept of identity. We understand who we are, and we understand
in many cases the identity that we want to portray. Right now I\'m
trying to portray my identity as a GE employee and also as a member of
CCHIT and a bunch of other standards organizations. That\'s not the
identity that I present to my doctor.

So it\'s important to recognize that we as individuals actually have
very good reasons to have different identities. The problem comes when
you don\'t have a way to group identities that you do want to use under
a single policy.

So the important thing it\'s a policy that binds your identities, and
having multiple identities within that policy is really the problem.
Which gets back to my first point, it\'s very important to set a
framework for policies, and what are the guidelines of dealing with the
data.

So on that note, I want to thank you for letting me testify.

**[\>\>]{.underline}**

Thank you very much. Michael Nelson from Health Market Science.

**[\>\> Michael Nelson:]{.underline}**

Thank you. I have a slightly different perspective on the federated
model. With a model like that, there\'s multiple records for a person
across multiple places. As such, each record in and of itself isn\'t
complete. So the patient-centric view, if you would, is fragmented and
incomplete unless you have some means of combining or linking all those
records together.

This is particularly problematic with provider data, because provider
data is constantly changing for many reasons. Providers change their
names due to marriage and divorce, they change addresses and phone
numbers frequently, they have status changes to their State license
numbers and DEAs. They\'re known differently in these different
information silos.

As an example, today going through this MPI process that\'s going on,
the MPES, the enumerator is basically validating an applicant\'s name
the way he is known at the Social Security Administration.

Well, certainly if that applicant goes by his middle name in his
practice or at his school, or there are different variation of how he is
known throughout the healthcare industry, it becomes very difficult to
identify that provider.

At Health Market Science we manage and maintain a master file of
providers with over five and a half million individuals and
organizations, and our experience has been that each month there are
changes to two and a half percent of those records. Since health plans
and PPOs are only recredentialing their providers every three years, you
can imagine the discrepancy in the data, and the difficulty trying to
properly identify a provider in that interim period. That\'s why a lot
of provider directories at health plans or PPOs are inaccurate. That\'s
why \-- it\'s been an open secret in the health plan industry that
provider data is dirty, and it\'s just been the cost of doing business.

That\'s all going to have to change with the MPI coming into vogue.

So I guess I would suggest to the panel is consideration of a master
provider index. A national master provider index. It may not be as
apropos for small local community hospitals, but for IDNs, for referrals
from non-staff providers or from providers from different regions, for
telehealth type of transactions, when you\'re looking to authenticate an
identity, and then to authorize that provider to access data, you\'re
going to need to have this external source of data in a master index to
know that you\'ve got the right provider.

And it has other ramifications at some point. Let\'s say a patient is
referred to another provider that they\'re unfamiliar with, and that
provider puts in a request to get their data, maybe a week ahead of
time.

Like a credit bureau, the index or the people managing the index could
send a notification to the patient, this provider has requested your
information. There could be a link in there where the patient could
actually go and view that provider\'s information, and make a
determination whether they want to release that information or not.

So I guess to sum it up, I think that a centralized provider database is
a lot more manageable than a centralized patient database, because you
have fewer individuals involved. Thanks very much.

**[\>\>]{.underline}**

Thank you. That\'s the last person who signed for the in-person
testimony, do we have \-- from the operator, do we have people queued up
on the phone?

**[\>\> Matt McCoy:]{.underline}**

No, we don\'t.

**[\>\> Kirk Nahra:]{.underline}**

Okay. All right, well, that I guess will end the public commentary
section of our meeting. Paul, do you have any comments at the end of our
session today?

**[\>\> Paul Feldman:]{.underline}**

Well, first of all, we are slated to meet again next Friday. From 11:00
to 2:00, 11:00 Eastern time. It will be a public meeting, and we will be
able to let this information settle, and deliberate in preparation for
making some recommendations, potentially.

**[\>\> Kirk Nahra:]{.underline}**

Any other comments from any of the Workgroup members before we wrap up
for the day? I know everyone will be disappointed we finished a little
early today.

**[\>\> Lorraine Doo:]{.underline}**

Hey, Kirk?

**[\>\> Kirk Nahra:]{.underline}**

Yes.

**[\>\> Lorraine Doo:]{.underline}**

This is Lorraine. And I \-- could I just follow up on that last
gentleman\'s comment?

**[\>\> Kirk Nahra:]{.underline}**

Sure.

**[\>\> Lorraine Doo:]{.underline}**

Would that be all right? Because it actually had to do with one of the
other items I was going to ask the group to think about, and not
expecting a response today, because it\'s a pretty complicated issue,
but something perhaps for next week or other times. And it has to do
with the authentication of the provider. So his comments were actually
very timely. And one of the issues that we\'ve been talking about is
what\'s the definition of a provider. When it is really not the clinical
provider who is in fact probably using the system to get the information
but it\'s probably his or her staff, or the business associates that are
doing things on their behalf. So one of the items we\'re wrestling on a
couple of our own system is really that definition and how we\'re going
to create an index and monitoring system for authenticating and
continuing go verify the identity of the provider or the so-named
provider.

So we\'re not expecting an answer, but it\'s another item for us to
consider.

**[\>\> Kirk Nahra:]{.underline}**

Okay, thank you. Along those lines let me just ask the Workgroup if
there are any particular topics that we covered today that for purposes
of some of the staff work over the next week that you\'d like
summarized, or any particular gaps that you saw today in the testimony
on the topics we were trying to cover today? John?

**[\>\> John:]{.underline}**

\-- apologize, because this may have already come up and I haven\'t been
through some of these activities, but I do think that the drive and the
rise of the personal health record that I think is clearly going to come
from a lot of the community, from citizens, is I think going to create
tension. You know, that we\'ve \-- in many instances we\'ve been able to
be able to sort of manage this through plans, and through, if you will,
the healthcare system as a, quote, system that frankly doesn\'t
adequately involve the citizen. And the patient.

And I think as we move to more patient-centered care this is going to
actually put a tension on this, that I don\'t think, at least I
certainly hadn\'t and I think a lot \-- I hadn\'t anticipated as much as
I think we probably ought to kind of think about that. Because I think
this is going to create more urgency to solve this, as well, and I agree
with one of the people that testified today, to that point. So it would
be nice if staff could maybe look at that tension, and that issue, in a
sense.

**[\>\> Kirk Nahra:]{.underline}**

Other thoughts on that? You know, not to cut it off today, but if you
have \-- as you\'re traveling back home or whatever, if you have
thoughts you can e-mail them to Steve or to Paul and I, and we can go
from there.

Let me just add one other thing I guess I\'d like to understand a little
better. There was a lot of talk today about a federated identity
approach, and I\'ll be honest, I didn\'t \-- I\'m not sure I understand
exactly what means. So it would be helpful to \-- it was suggested by a
number of people, there were some comments saying it\'s not necessarily
a useful idea, but I wasn\'t exactly sure what we were debating on that
point. So I\'d appreciate something on that.

**[\>\>]{.underline}**

Good idea.

**[\>\>]{.underline}**

Anything else? All right, well, thank you all for your participation \--
oh.

**[\>\>]{.underline}**

What about Lee?

**[\>\> Kelly Cronin:]{.underline}**

Lee had some travel problems today unfortunately, so hasn\'t been able
to join us. But I think he\'s going to be lined up for next week.

I also wanted to let you know that similar to what NCVHS has done over
the years in summarizing all the testimony they get, we\'ll do something
similar where we\'ll try to provide a synthesis of everything you\'ve
heard today in a spreadsheet format. So we\'ll have it by topic area,
and also try to answer the specific questions that were posed, so that
when we start to debrief and deliberate we\'ll be able to go question by
question, and have more of an overall sense of what the input was that
we can base our deliberations on. So I think that will be helpful. In
addition to trying to dig into federated identity management and any
other specific issues that came up that might require some additional
analysis. In particular, if we feel that there needs to be some kind of
trade-off assessment, there was a lot of talk about risk assessment,
there might be data in the literature, or data from RHIOs, or data from
the labs, or some real-world experience where we can actually think
about how we might quantify or at least descriptively or qualitatively
do some trade-offs or risk assessments in our deliberations, in
determining what might be the most appropriate policy options in
different scenarios.

**[\>\> Kirk Nahra:]{.underline}**

Okay, well, thank you to the panelists who are here today for
participating. Thank you to the Workgroup, thank you to the staff for
helping get this together. And look forward to speaking with you next
week. Thank you.

**[\>\>]{.underline}**

Thank you.