American Health Information Community

Confidentiality, Privacy, and Security Workgroup Meeting #4

November 2, 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.*

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

Good afternoon to everybody and welcome to the fourth meeting of the
Confidentiality, Privacy, and Security Workgroup. Just a reminder that
these meetings are designed to meet the requirements of the Federal
Advisory Committee Act and as such have been published in the *Federal
Register* and are being conducted in the public domain. Also remind you
they are being broadcast over the Internet and being transcribed and
recorded. As you speak, please speak clearly and identify yourself
before you speak. And, finally, just a reminder that no one other than
the Workgroup members are really allowed to participate unless invited
by one of the co-chairs. And then finally at the end of the meeting, we
will call in public comments. So with that, I\'ll turn it over to you to
introduce those on the phone and perhaps people here in room can
introduce themselves.

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

Thanks, Judy. Calling in today we have Steven from the Oklahoma
Department of Mental Health and Substance Abuse Services. Dennis Seymour
is here today, I believe as a designee for David McDaniel, is that
correct?

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

No, actually I\'m here. This is David McDaniel.

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

Dennis Seymour, staff member for HHS.

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

Susan McAndrew from HHS. Tom Wilder from America\'s Health Insurance
Plans. Elizabeth Holland from CMS. John Houston from University of
Pittsburgh Medical Center. And Jill Dennis from AHIMA. Flora Hamilton
from Family and Medical Counseling Services. Tony Trenkle from CMS. Is
there additional Workgroup members on the phone whose names I did not
read?

Very quickly, just a note on procedure for those members calling on the
phone. I\'ll just repeat what Judy said. Please make sure that you say
your name before you make any comments so that members of the public who
are following along via the Web will know who is speaking. That\'s it,
Judy.

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

Maybe those in the room could introduce themselves, please.

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

Paul Uhrig from SureScripts.

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

Deven McGraw, National Partnership for Women and Families.

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

Alison Rein, National Consumers League.

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

Paul Feldman, Health Privacy Project.

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

Kirk Nahra, Wiley Rein & Fielding LLP

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

Jodi Daniel, ONC.

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

David McDaniel, Veterans Health Administration.

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

Turn it over to the co-chairs.

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

Good afternoon, everybody, this is Paul. Welcome you aboard. How quickly
time flies. And we are here today to attempt to see where we can get
with some other recommendations that have been posed and drafted by
staff. You got a document last night breaking them down, newly numbered
in more useful order, thank you. Yeah. So we have a recommendation from
staff.

To, so we have a recommendation from staff to work up the document from
the bottom, which I think we can talk about the focus items before we
get back to our favorite. Secure messaging.

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

I want to apologize for setting up this document. Yesterday evening we
had all intentions of putting it up sooner, but we will try to do better
in the future and make sure that folks have more times to do this. This
is a draft for us to discuss on the 13th to hopefully finalize
recommendations, sort of an interim step. So if you didn\'t have a
chance to review or feel like you still need to make comments, you can
always let us know if there\'s something you realize after today, you
can let us know one on one and we\'ll try to reflect that in the next
version.

The first thing I would like to suggest we do before we start going
through the specifics is to ask if there\'s anything that folks felt was
not represented in here that we discussed that either we should be
representing in here or if there are issues that we haven\'t discussed
yet that we should be taking on, for a set of recommendations. If there
are things in here in the alternative that really need to be removed.

I just want to come to a high level first to make sure we have all the
issues on the table and make sure there are things that we want to pull
off the list. I guess the first question is: Are there things that need
to be added to the list of recommendations that we haven\'t covered? I
know the EHR and PHR, we had discussion on that for support of that.

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

Just another introductory comment just to refocus our thinking. Even
though we\'re calling them EHR and PHR, we are working through the
breakthroughs and it is only the limited issues of EHR and PHR that we
are attempting to make some recommendations on. We will make sure and
clearly convey that to the Secretary when we present in December. But I
think in terms of just kind of moving this conversation forward, it\'s
very important that the limitations and constraints ‑‑ or actually the
possibilities of getting to recommendations may be a function of it
being a breakthrough.

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

That\'s a good point. A good point.

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

So if anybody has any high level, add, subtract, missing, that would
be ‑‑

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

We need to talk about if we are not quite at a recommendation yet on
these topics.

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

One procedural question.

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

Sure.

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

Do the Workgroup members, should the Workgroup members plan on being
present at the meeting where this is being presented? Or is this a task
that the co-chairs will take on?

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

I think that\'s typically your choice. Typically we would have co-chairs
presenting the issues or the recommendations. But I think everybody is
welcome to come. I don\'t think it is a necessity that you be there. It
is a choice that Workgroup members can participate remotely.

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

Okay, thank you.

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

Any other substantive questions or suggestions from that was suggested?

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

All right we\'ll work from what we have when we talk about the
specifics. But we\'ll start with the recommendations. The draft
recommendations we have here. Everyone should have received a working
draft. This was based on ‑‑ that was put together based on the prior
discussions that the Workgroup had, some individual input we received
from folks. We tried to reflect that where possible. But we wanted to
bring it back to have a full discussion with the Workgroup, make sure
that we represented things accurately and that others are comfortable
with the comments that were taken on these. The first thing we tried to
do is an introduction and makes it clear that these only apply to the
near-term breakthroughs. As Paula suggested and get something there. It
would be helpful to have any comments on that so I think we could
probably see if we could get into the substance of those. If folks have
any input as to how this should be framed, any kind of general comments
that we need to raise, then we can put them in an introduction once we
actually flesh out the recommendations. The way this is organized, we
have assumptions that apply to everything, some general draft
recommendations, some ‑‑ and then we have divided them up for some
secure messaging, the specific breakthrough charges, secure messaging.
The specific PHR charge of medication and registration summary and then
the specific EHR charge of exchanging lab data. We can actually make
that a little bit more clear in each of the sections that is really the
breakthrough and not PHRs and EHRs in general. Probably I\'ll ask the
co-chairs. Do you want to start with general assumptions or the general
ones or jump right back to the back? I don\'t know if that will help
frame it or not.

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

I guess we should work on the recommendations. The general substance.

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

The general recommendations jump right to the ‑‑

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

Just for folks on the call if you\'re listening, I don\'t recall whether
these instructions were made but the document that we\'re working from
is available on the Web, I\'m imagining ‑‑ okay.
hhs.gov/healthit/cps_materials.html.

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

That\'s up on the screen for those following along on the Web. So the
way this was structured on each of these was we put out a draft
recommendation and then we had some categories for where there might be
options, assumptions that were being made in making the recommendation.
Any kind of restraints or applicable information and any scoping issues
that we wanted to make clear of something extraordinarily or broadly we
could do it there. You can notice they are not filled in. If we need to
add something in, we can do that. But wanted to capture where there were
some caveats, strengths, assumptions of the recommendations, because
they are somewhat nuanced. I guess with the PHR one, there was some talk
back and forth about we\'re talking about secure messaging, there was
some conversation with PHRs as they might connect with secure messaging.
Can that really be done in person? There were some concerns CMS had
raised with that. We felt like there wasn\'t a clear consensus here. We
just said that this required more Workgroup discussion after we got some
input from folks. And it seemed like there were a couple of ways to go
and we can talk about whether there were two options here. One is using
knowledge‑based online identity proofing, which is what I think CMS is
suggesting and then another was an in‑person identity proofing. And we
were suggesting that it might be ‑‑ or there might be a trusted
third‑party there. So I guess I would open that up to discussion. And
also ask CMS if they might want to explain some of what they are
currently doing with identity proofing for their Medicare beneficiaries
or how they\'re planning to proceed on some of their activities with
respect to identities grouping.

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

This is Kirk. Let me jump in for a second. It seems like there is a
couple of points before we get into the substance of discussion. One is
when Jodi threw out the first question are we missing anything, people
didn\'t have comments, which surprised me, I guess. I want to be clear
that the recommendations that are being talked about here in draft is
not everything we\'re going to do with the EHRs and PHRs. This is sort
of where we are at this point, some of the topics where we were
potentially at a point where we could make a consensus recommendation.
We\'re obviously going to need to come back to these issues. I mean,
they\'re going to be throughout the course of our discussion. So I
don\'t want people to think ‑‑ there\'s lots missing. To some degrees we
haven\'t gotten to most of the issues. So this is sort of a baseline
starting point.

I wonder whether we should start with the CMS discussion to give them
\--

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

That sounds great.

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

After what they\'re doing and we can dive into the substance.

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

Remember, we\'re talking about a ‑‑ summary and medication history.
Which is not ‑‑

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

It is not here. We will have to write that.

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

Have the nouns reversed.

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

Oh, thank you. Elizabeth Holland, are you on the line?

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

Yes.

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

Do you want to jump in here and give some explanation of what CMS is
doing or current thinking on the area?

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

Basically we\'re doing two different things to authenticate
beneficiaries right now. In one medication, the mymedicare.gov
application, we are issuing user IDs and passwords to get a user ID and
password, the beneficiary needs to know their Medicare number or their
health insurance claim number. And that number actually shows up on
their Medicare card. They need to input their last name, their date of
birth, their gender, and their ZIP code. Then we will send them, through
the mail, a one‑time use password. And that goes to the Social Security
Administration\'s address of record. And then they can use their ‑‑ in
subsequent times, they can use their Medicare number and this one‑time
pin that they have to change when they first log in to access the
information that\'s available through that site. And that information is
eligibility, enrollment information, information about preventive
services, as well as their Medicare claim information.

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

I lost the audio for one moment. Could you repeat those steps again,
please?

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

Okay. The items that they need to have? Or the whole thing?

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

Items they need to have.

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

They need to have their Medicare number, which is an alphanumeric number
that shows up on their Medicare card. And when the logging on, there\'s
actually a depiction of the Medicare card up on the screen and it shows
them exactly where that number appears. So they have to have that
number. They have to have their last name. And that needs to match the
last name that they have on record for that Medicare number. The date of
birth, their gender, and their ZIP code. So it\'s those five items that
they need.

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

Great, thank you.

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

Plus the one time password they receive through the mail.

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

Right. They can\'t get into anything until they get that one‑time
password through the mail.

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

So that\'s basically verifying that they are at the address of record.

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

Yes. And that their last name matches that last address of record.

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

And you\'re using a do not forward on the envelope?

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

I believe so. But that\'s one of the things we\'re thinking of not
continuing. So that right now is up in the air.

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

Not continue what?

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

The do not forward.

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

Why would that be?

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

There were issues with people not getting them. I don\'t know the all
the details. But that\'s just one of the things we\'re looking into.

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

How did somebody ‑‑ what\'s the ‑‑ you may not know this. I\'m going to
put you on the spot, but do you know how somebody actually gets a
Medicare card and if there\'s some kind of identity proofing that
happens there before they\'re able ‑‑ they\'re actually issued a
Medicare card?

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

I don\'t believe that we do any Medicare, any identity proofing. I think
it\'s all done through the Social Security Administration. Tony, if Tony
is still on the line, he did can probably speak to that better than I
could.

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

That\'s correct, Elizabeth. That\'s done through the Social Security
Administration.

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

Do you know what they do, Tony? Is this just based on Social Security
records? Or is there some other kind of process?

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

It is based ‑‑ yes, it\'s based on Social Security records.

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

And I think they do it all through the mail. I don\'t think you actually
have to show up.

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

Yeah, you can show up, but I don\'t believe you have to show up. I
believe that\'s the latest. We can verify that. But I guess I\'m not
clear why the focus is so much on the initial proofing and not also on
the entire life cycle, the process here. I guess maybe I\'m missing the
point here because to me, proofing is important, but it\'s also
important to maintain a critical control over the entire process, which
includes not only the process, but also the auditing. I guess I\'m not
clear. And I haven\'t been at all the meetings but why the singular
process on just the proofing here.

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

I thought you were going somewhere else with the comment, which is the
relationship between identity proofing and then the ‑‑ which is one time
or one time‑ish and then the authentication, which is a per-use kind of
situation. But instead you spoke of audit and what else?

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

Certainly the proofing then leads to the authentication that as they
come into the site to do the application. But I was also looking ‑‑ not
only at the proofing and the authentication and the authorization but
also the entire life cycle, which gets into how do you do revocation of
a credential and how do you audit the use of the credential?

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

I think the short answer to your question, Tony, is that we\'re just
going in stages. We started with identity proofing and authentication as
a topic for the first hearing. We heard lots of different information
about authentication. And I don\'t have the sense, although I\'m happy
to hear differently, that we\'re necessarily at a point where we have
enough knowledge or consensus on what authentication standards are
appropriate, so we\'ve focused on identity proofing just as biting off
something that we can chew in the first instance.

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

Right. But my concern is that just focusing on identity proofing in and
of itself without focusing on the other mitigation processes that are
there kind of leads to a very skewed assumption in terms of what type of
proofing needs to be used because you could focus on an in here person
proofing as something that needs to be done. But if it\'s not tied
together with other mitigation factors, it essentially becomes nearly
worthless (an in‑person).

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

Tony, let me jump in here for one second, just to tie it back. The
general assumption, one of the things that we talked about is ‑‑ this is
General Assumption number 4: that when the final identity user
authentication, it is important to understand it is part of an overall
process for issuing electronic identity. If they\'re not at equal level
the overall stress of the electronic identity ‑‑ product or service.
We\'re trying to capture that. I don\'t know if it captures it to the
full degree that you\'re stressing. But we are trying to figure this is
part of a life cycle. And there are other security measures that play
into the identity credential process. And that this is just ‑‑ that they
have to be at a consistent level. If you have a weak link, then you have
strong identity proofing and weak authentication and you haven\'t
processed much. I think we\'re trying to capture that, even though the
focus is on identity proofing and authentication, we\'re trying to
capture that in a more broad sense.

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

Let me add to that, Tony. I think that what you\'re raising is, even
beyond what Jodi said, a perfectly fair point. And we talked about this
a little bit on our last call, which was the breakthrough, for example,
on secure messaging. We were talking about identity proofing and the
context of secure messaging and we had this discussion about whether it
really made any sense to isolate secure messaging alone. And talk about
just that because it was really going to be part of some broader system.

So to the extent that we start to focus on details and recommendations
and your view is that recommendation doesn\'t make sense either now or
yet because we haven\'t addressed some of those other issues, again
that\'s a perfectly reasonable conclusion. We may certainly be there on
some of these points. So I think the point that you\'re making should be
something that we all have in the back of our minds as a general matter,
knowing we\'ve got to deal with that, but also if we\'re talking about
making a recommendation and instead your sense is well that\'s not a
recommendation that really makes sense until we\'ve gone to those other
points, certainly I\'m happy to hear that because I think that\'s ‑‑ by
trying to bite out smaller pieces, we may not be giving credence to the
bigger picture.

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

I\'m just concerned about the criteria being taken in a vacuum. And
getting to your point about secure messaging, I don\'t know if Jodi has
mentioned, but the Workgroup, the Chronic Care Workgroup, which I
co-chair, and did send forward the recommendation on secure messaging,
we have moved away from that in terms of looking at it separately and
then looking more in it as part of a network because some of the
research that we\'ve done has found that it doesn\'t make sense to just
focus on secure messaging in a vacuum because it\'s rarely used in and
of itself without being part of a larger system that may include a PHR
or an EHR.

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

Okay. So you\'ve raised these other pieces of the life cycle of what was
the term be to describe this? The life cycle of identity management?

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

Yeah it\'s an identity management life cycle we\'re talking about here.

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

So if you would, if there are specific pieces that happen in the rest of
the life cycle that you believe should inform the recommendation, then
certainly what I understand to be an opposition to reliance on in-person
identity proofing, then this would be great to hear.

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

I have not necessarily expressed an opposition to in‑person proofing.
What I\'m trying to express is that this is a risk factor that you need
to look at. And it\'s part of the risk mitigation, there\'s a number of
key points along the way to help deal with the risk area. One is
certainly what type of proof you use. But looking at it in and of
itself, it doesn\'t really address all the potential mitigation
strategies. So in‑person proofing may have validity in some cases
depending upon how it\'s tied to certain authentication uses, but in
other cases, it may not because of scalability or other types of issues,
some of which may be economic, that create a problem if you do try to do
in‑person proofing.

So I\'m not saying in and of itself that in‑person proofing is not good,
but I think it needs to be considered as one of the number of factors
you look at as you build this life cycle identity management.

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

Okay. Now, if I may go back to Elizabeth, you said, Elizabeth, that you
wanted to talk about two different items and one is Medicare.gov which I
believe we\'ve now heard?

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

Well I just have one more item on the Medicare.gov. That is that we are
right now exploring the possibility of accepting external credentials on
that site. So we\'re looking to the Federal Government\'s
e‑authentication initiative to determine if those credential service
providers out there that we would actually accept their credentials
through the site. So that would allow us not to accept the credentials
ourselves. So that\'s on our plate for the next couple years.

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

Are there folks on the Workgroup that would like to hear more about what
that means a little bit? Would that be helpful?

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

Yes.

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

Okay. Elizabeth, do you want to do it?

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

You were there yes, too.

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

I know.

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

To me it doesn\'t matter. Tony could do it as well.

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

Elizabeth, why don\'t you go ahead and walk through it? I can just
mention a couple of other things behind it that may help inform the
discussion.

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

Essentially there\'s issues with who you can trust. So the Federal
Government went about trying to develop an infrastructure so that all
different Federal agencies aren\'t figuring it out for themselves. They
tried to create a model. And come up with criteria to certify potential
service providers so that there\'s a common framework. There\'s common
business rules and there\'s a common technical infrastructure. And they
actually assess, they perform assessments of these service providers so
that an agency can choose off a list and be assured that those
credentialed service providers meet certain criteria. So it\'s a
combination of entities that are actually issuing credentials. Some are
financial services. Some are governmental.

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

Right. Two of the examples that are commonly discussed in this regard
would be ‑‑ and without comment as to whether they are appropriate or
not, motor vehicle administrations and notary public. Just to kind of
give a flavor of what this intends to be. It\'s a transitive trust, is
that what we call this? That the trust is established and then it\'s
able to be used if the initial trust is established, then. And then in
this application, mymedicare.gov trusts the entity that did the initial
identity proofing, then they would accept that credential.

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

Let me follow up just so I understand. I understand the idea, I mean if
I go to one of these trusted sources, wherever it\'s going to be, they
can confirm that Kirk Nahra is Kirk Nahra. How do you make the match to
who Medicare views as Kirk Nahra? Or that it\'s the right Kirk Nahra?
That\'s the part I struggle with. What\'s the connection?

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

What they tend to use is a same-one assertion that contains certain
information that then can be matched against agency databases. It does
not get into things such as the SSN. But it does do some matching. But
in addition to the authentication, which is a fairly low-level
authentication, it\'s a level 2 on the OMB guidance, which is basically
a password‑oriented credential, the agency also has the ability to do
further authorization depending upon the type of application that they
want the ‑‑ that the person\'s going into.

So at the Social Security Administration, for example, when we were
looking at ‑‑ when I was at SSA, we were looking at the use of the
fidelity credential. We did have additional authorization criteria that
we asked for to make sure it would match against our databases. And of
course the databases at SSA, if someone\'s not a retirement beneficiary
or current beneficiary of any type are based on information that was
given at the time the person or their family got the person an SSN, a
Social Security Number.

So that basically the idea behind this is to use medium‑level
credentials that a third‑party has that go through a fairly rigorous
audit process by GSA, the General Services Administration. And then
these are used to access fairly ‑‑ I wouldn\'t say high-risk
applications, low- to medium-risk applications on public Websites. So
for the Social Security Administration example, they were looking at
something like change of direct deposit or change of address as two of
the potential applications. They went through and did a limited one on
direct deposit. They never implemented the change of address. But those
were the type of applications that they were looking at there. It is not
meant for very high risk applications that would require, in normal
cases, PKI certificate, for example.

And GSA is responsible for, as Elizabeth said, in getting the credential
service providers to agree to certain levels of audit business rules and
other types of requirements before they \"certify\" them as service
providers. And right now they have a mixture of public and private
sector providers, as she said, that you can get to if you go out to
the ‑‑ I will it\'s cio.gov/eauthentication where you can get a list of
the current providers.

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

I think one of the reasons this is attractive to us is because we\'re
trying to minimize how many user IDs and passwords people have to
remember. So that if I know I can come in through let\'s say my fidelity
user ID and password, initially I may have to do additional registration
for Medicare, but all my subsequent uses I could log in using my one ID
and password. I don\'t have to remember different user IDs and passwords
for different applications necessarily.

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

Okay. I know Alison wants to make a comment. Is there anybody on the
phone who has a comment at this time? Okay. Alison?

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

I\'m from National Consumers League. I just wanted to clarify that this
last part of the discussion was just around sort of the level of
assurance that one would need as it pertains to the Medicare population
and as it\'s been deemed through that process with the e‑authentication.
But the e‑authentication system actually describes four levels of
assurance. And it\'s quite conceivable that different players in the
healthcare space for different needs based on whatever risk assessment
they conduct would find themselves at one of those other levels of
assurance. And I just wanted to make sure that that was clear that the
one that got described isn\'t the only one that exists win this
framework.

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

That\'s correct. Although the push within the Federal Government has
been towards the low- to medium-risk applications. But that is correct.
If there was an application that was of a higher level of assurance
required, there may be a higher level of assurance required from the
third‑party or additional diligence done at the initial stage to do
that. So, yes, that\'s correct, but that hasn\'t been the major push at
this point. However, you\'re right, if there are certain healthcare
applications that might warrant a higher risk level, then that would
have to be factored into the situation for what type of third‑party
credential would be acceptable in this case.

And regarding that, it would be no different than an internal credential
that CMS would issue, also, or whoever else was issuing the credential
from the government. It would still be the same level of assurance
needed regardless of whether it was an internal credential issued by the
agency or acceptance of an external credential, it would still have to
meet certain levels of risk mitigation to qualify.

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

Okay. I am watching the clock and I am realizing that we are going to
rapidly get to a place where we\'re not going to get through this stuff.
So I want to try and keep us on task and focused. So there\'s a couple
things going on.

First is that I would like Elizabeth to describe the second half of what
we were going to talk about here, which is on Medicare.gov. First I want
to make one comment. It appears that the conversation that we\'ve been
having so far, and correct me if I\'ve got this wrong, is about patients
only. Which is fine. I just want to make sure that we\'re talking about
we\'re all sharing the same conversation here. Is that correct?

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

Yes. So far that\'s all we\'ve talked about.

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

So could you talk about the second application so then we could maybe
have ‑‑ kind of break this all down? I\'m thinking that that\'ll happen
better after we\'ve heard the rest of this from you.

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

Okay. The second application is the Medicare prescription drug plan
finder, which was brought up online last year to help beneficiaries
compare and enroll in the Medicare prescription drug program as well as
Medicare advantage plans and other Medicare plans that may also be for
prescription drug coverage. And we needed a way for them to get into a
system quickly and get information that was tailored specifically to
them. So we developed this knowledge‑based application. For that
application we require that they know their Medicare claim number, which
we talked about before, it\'s on their Medicare card. They need to know
their effective date for Medicare. They need their last name, their date
of birth, and their ZIP code.

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

Clarification. The effective date is also on the card?

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

I believe it is, yes.

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

So what protection? What additional protection would that convey, then,
on the same data source?

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

I know those are the bits of information they ask for. I don\'t know
exactly why they chose those bits.

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

All right. I know I put you off for a second, Dave, some why don\'t you.

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

This is David McDaniel. It\'s related to this discussion about these
components. My question would be: How did you derive at these
components? I could readily get any of these things and become that
person and now have access to their information. So we really haven\'t
authenticated that person as who they are.

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

For us it\'s more of an issue of the risk of what that means. The
information they\'re getting is where you live, what plans are offered
in that area.

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

Let me paraphrase that. The second scenario, not the my Medicare, but
the prescription drugs specific, there\'s consciously been less
stringent identity because there is the risk is lower because the
information you will get if you do impersonate someone?

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

You could enroll in a drug plan, but ‑‑

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

It\'s not just ‑‑ okay. So there\'s two things you do there. One is you
learn about your choices.

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

Yes.

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

If all I do is pop in and I live in Bethesda, Maryland, there\'s 11
choices, here\'s what they are. That\'s not sensitive. But then you can
do the next step, as well?

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

You can put your drugs in, as well.

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

And find out who prescribes things?

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

Yes.

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

But it\'s not used to ‑‑ and it\'s used to enroll you in one of the
plans.

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

It can be, yes.

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

Can you change your address or contact information using that?

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

No.

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

So if I have my elderly neighbor\'s Medicare number, I\'m ready to rock
and roll.

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

You can enroll her in a plan.

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

That was done consciously because people needed help enrolling in the
plans.

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

So to use this as a good teaching example, I think MyMedicare.gov, whose
scope is quite a bit greater than the drug finder, correct? The
Medicare.gov?

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

Yes because you can get claim information through Medicare.gov.

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

You can receive claim information.

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

Your claim information, yes.

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

So then what we have here is, first of all I want to break down the
difference between the two. It appears to me from what you called out
the only thing different about the bird to authenticate is that the
MyMedicare.gov includes gender and ZIP.

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

And the sending of the password through the mail.

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

And then the password through the mail, which may or may not be coming
to as of right now do not forward and you\'re thinking about removing
that restriction.

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

Right. But it goes to the SSA address of record. You couldn\'t go in
there and change your address. You had to do that separately.

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

The password by mail consists of the ‑‑ something you know. And the rest
of it is something you are. Is that the right term nothing, sort of?
John is sitting here looking at me.

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

I\'m sorry. I didn\'t hear the full context.

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

We were having conversation about the burden for authenticating on
MyMedicare.gov and also for the drug finder. You get by mail your
one-time-use password, which presumably then you reset to something you
like. And then use that plus some data points to identify proof and get
into the system for the first time.

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

So I guess the question is it sounds like the difference is based on
risk levels and how much ‑‑ what the requirement is based on the risk
level. And it sounds like you\'ve made the determination that when
there\'s claims information, that you have taken the extra step because
there\'s more risk of the information going to a different person, is
that fair to say?

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

I think, Elizabeth, this is Tony, I think on the second one, the plan
finder, you\'re not disclosing, you\'re in the getting information
disclosed to you. You\'re inputting information on the second one. The
first one is when you get limited information disclosed to you, which
includes eligibility information as well as some history of claims
information. Is that correct?

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

Uh‑huh.

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

This is David McDaniel. So what you\'re saying is that the only
difference between the two of these is that you\'re sending the password
in the mail?

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

No. What I\'m saying is there\'s a lot of difference. The first one is
not ‑‑ the plan finder is not disclosing any personal information. And
it\'s not a ‑‑ it\'s a low-level risk application. The second one is a
higher-risk application in which you send some initial information when
you go onto the site, which gets verified against the records. And then
you get a one‑time password sent to the address of record. And then you
go in and change the one‑time password when you go online.

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

So there\'s two comparisons we\'ve got to do. One is the risk comparison
between the two devices. The other is: Okay, with those risk
differences, what have you done differently to authenticate? So it\'s
sort of mixing the two points.

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

Actually I think what we intended this conversation to be was in support
of allowing to hear what at this point appears to be a minority view
challenging the recommendation that identity proofing should be done
in-person. So we wanted to hear from you about what you\'re doing to see
if that should inform our recommendation.

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

I\'m sorry. You say this is a minority view?

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

The sense of what I\'ve been hearing and we can poll the group if that
is useful, but that in general, others in this Workgroup believe that
the working assumption to work from, not that it is hard and fast, would
be that the initial identity proofing be done in person as practicable.

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

For what type of applications and under what circumstances?

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

I think that there was some plea agreement that Paul\'s statement
related to, messaging, sorry. So now we\'re looking at ‑‑ of our group.

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

I thought you were talking about medication history here.

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

I think MyMedicare.gov is probably somewhat analogous there with the
type of information as far as registration summary and medication
history. So it sounds like CMS\'s view on that is the way you\'re doing
it now through mymedicare.gov. We should probably open the floor to hear
other people\'s perspectives on identity proofing for PHR.

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

I don\'t think that\'s correct, Jodi. I think this is what we\'re doing
for MyMedicare.gov. MyMedicare.gov is not a personal health record nor
is it a medication history and an electronic clipboard as defined by the
Consumer Empowerment Workgroup.

I think what Elizabeth is just pointing out this is how we\'re doing it
today. We have not determined if we had to support a full-blown effort
for medication history or electronic clipboard that we would use this
exact type of authentication.

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

Sorry. Thanks for clarification, Tony. I apologize.

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

I think one of the things we need to go to and maybe we should start now
is when Paul was talking about the consensus, the minority view, it was
very focused on secure messaging. At a point in time when we were trying
to talk about secure messaging as essentially an independent idea, there
were a number of people on the Workgroup, I think probably most of the
people, who thought there was a value to in‑person. And that the ‑‑ in
most situations, that would be coming up in a situation where you
were ‑‑ the patient was, in fact, with the healthcare provider. But now
what I\'m hearing, both from the Chronic Care Workgroup, and I think
from our discussion generally, is that it may not be useful at all to
think of secure messaging independently. And so having a consensus on
something that we decide isn\'t worth having an opinion on may not get
us very far.

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

This is John also. What I just thought I heard, maybe I am wrong but I
just came in, they\'re talking about two different levels of data
sensitivity, one is about patient‑entered data and the other is where
there is data presented.

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

That\'s right.

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

In the context for the conversation was simply to hear what the
practices are to inform what we may or may not do.

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

The other difference is we think about how to translate what we just
heard from the CMS with regard to these two narrow applications is that
when we think about PHRs more broadly, we\'re not just talking about a
Medicare population. So we don\'t even have a benefit of a Medicare
number. So I sort of think while very instructive, it\'s a little bit of
a different animal than some of the other conversations we may be having
with respect to other type of PHRs.

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

It\'s an example is what it is.

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

This is my bad. We\'re focused again on PHRs and medication histories
and medication summary. So before we ‑‑ I have something else to say but
I want to make sure if there\'s anybody else in the call or in the room
that has a comment at this point. Okay. Then I want to try something. It
seems to me that it is arguable whether a Medicare number sent through
the mail constitutes something you know that would be robust enough. I
think that\'s arguable. I don\'t know that we need the hash that out
here today.

But I do think that there\'s a principal involved that we may be able to
recommend around, which is that should there be to identity proof for
purposes of receiving data, which is what happens in a PHR. Medication
history is something that comes from a third‑party to you. If it\'s
yours, that\'s great. If it\'s not yours, it could be very not great. I
mean both because it could kill you and it also would have some
significant privacy concerns. It could also make you better. In any
event, should there not be some data points ‑‑ I mean if we\'re not
going to do this in person, should there not be some data point that you
know that is not widely recorded on a piece of paper, like what\'s the
last three medications that you were prescribed? When\'s the last date
that you went to the doctor to prescribe your last medication? I mean
that\'s knowledge that you have that may not be widely held. Just kind
of provoking a conversation about that. This is just kind of what comes
off the top of my head. But it receives to me that\'s what this is
intended to me. When you see that in person, all of that goes away. Your
doctor knows who you are, done.

But if we\'re not going to recommend that, then there has to be
something that overcomes that to purchase (inaudible).

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

This is John Houston. Can I step in for one second? When you present
yourself to your doctor, does your doctor actually know who you are?

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

What do you mean?

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

We deal with this periodically where we have people who have previously
stolen people\'s identity and shown up at doctors and tried to get
services. I think that\'s actually not ‑‑ that\'s something that happens
on a regular basis. And the reason why I bring that up is that again I
don\'t think we should assume that just because you show yourself at a
doctor\'s office that you are who you say you are. I think you could
find you ask for credentials and other things, but there is a certain
point where I think the gold standard is not necessarily foolproof,
either. So do we assume that that has to be where we go? Or is there
some reasonable equivalence that doesn\'t require personal
identification that gets you pretty far along the way?

Again I just want to say that it is not necessarily given that showing
up at someone\'s office will proof-positive identify you.

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

I would agree with that. On the other hand, I want to make sure that as
we go down the road to moving away from in‑person identifying procedures
that we all remember that if we\'re talking about the provision of
medical care, current medical ethics as well as e‑risk guidelines, AMA
and ‑‑ guidelines all call for medical care to be given to patients with
whom a provider has established a relationship with and not for someone
who they have ‑‑ are dealing with for the first time via secure
messaging or secure Website. So I understand that there might be other
uses aside from authenticating one\'s self to a physician or provider.
But I don\'t think we can rewrite medical ethical guidelines just by
saying that in‑person identification is not necessary.

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

There\'s a big difference between in‑person identity proofing with a
doc without an ID than with an ID, right?

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

We were talking about that a little bit yesterday in some other
discussions where to say "in‑person," we have to really talk about what
that means. Obviously if I walk in and say hi, I\'m Paul Feldman and
there\'s no other checking, that\'s almost worthless. I suppose it\'s
not worthless if I was Kirk Nahra last week and next week I say I\'m
somebody else. They can tell that. But in person means what? We talked a
little bit at our last call about government picture IDs. I know there
are some hesitations with that. And there are some situations where
those don\'t work. Whoever talked a few minutes about "foolproof." We
have "foolproof" at a couple of different levels. We have we have
"foolproof" meaning protection. "Foolproof" meaning it is for the entire
population. If you said "driver\'s license," we could probably come up
with a pretty good estimate and to how many that would serve and how
many people would have a problem with that. The accuracy of the
driver\'s license might be a different calculation. So we have to ‑‑ we
do need to think about these in a series of different steps. And I think
that one of our challenges is to be thorough and accurate in our steps
but also not to break it down into so many steps that we don\'t make any
progress.

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

Not only would you have to define what it is to be authenticated in
person, but you would also have to define what it would mean to be
authenticated not in person. And the definitions that we just got from
Medicare would work probably for a very low-risk setting where you\'re
pushing information that you could push to any number of people. It\'s
not unique to you necessarily. But when you start getting into the realm
of uniqueness of the information, this would break down, in my mind. I
wouldn\'t want my information pushed even if somebody sent me a password
that somebody could take me from my home and set up an account for me
and be managing for me that I don\'t even know exists.

So I think that there is that need for scalability based on the level of
risk and the level of data that\'s being transmitted both directions and
the uniqueness of that data.

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

I would concur with that.

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

This is Tony again. I would just like to maybe make a suggestion. Since
we are focusing specifically on the PHR medication history and
electronic clipboard, why don\'t we look at it in terms of that and what
the type of data that\'s being transmitted and the potential risk and
the harm there and then come up with maybe a number of potential
solutions. One could be in‑person proofing for certain types of maybe
not where it can\'t be scalable, then you wouldn\'t do in‑person
proofing.

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

Tony, excuse me, I apologize for interrupting. We don\'t have to do that
piece. That piece has been done and is presented to us. Our job is to
provide recommendations on identity proofing for a registration summary
and medication history. So they are what they are. They are as sensitive
as we deem them to be.

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

That\'s basically what I\'m saying. Is based on that, I think you need
to come up with a maybe several different potential solutions because
economics or scalability may present more of an issue for one type of
solution than another.

And I think a couple minutes ago maybe it was Paul was kind of making
the statement. If you do knowledge base, then maybe you need to have
these particular elements in there. Maybe that would be a more ‑‑ a
better way of coming up with several different solutions.

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

This is Tom if I might jump in here and maybe suggest a little bit
different approach. To me, identity proofing I think actually we could
make a recommendation that cuts across all the breakthroughs if we
handle it in this fashion, which is to emphasize the importance of
identity proofing. Suggest that there are various ways of identity
proofing and spell those out, including in person, knowledge-based, et
cetera.

Note that the type of identity proofing is dependent on part on the
sensitivity of the information and the risk of exposure. And based in
part on certain economics or scalability issues depending on the type of
healthcare entity that we\'re dealing with. And depending on the
consumer\'s own needs or preferences. And that as I think Tony very well
put out, that really this is only part of a continuing process. As Tony
put it, the life cycle of identity management, where you need to
continually make sure that you\'re having the right people accessing the
right information for the right purposes.

I think one of the concerns I have, I think in‑person identity proofing
is good. I\'m not sure it works in all cases for all things. And I think
maybe we\'re better served by just kind of laying out for folks the
range of options and helping them understand some of the things they
need to consider when they decide what option works best for them.

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

Alison?

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

I just wanted to add, I mean, there\'s sort of this continuum that
we\'re trying to get our arms around. And certainly at the as the level
of assurance increases, so does the potential level of cost and
inconvenience.

But part of what I heard described with the Medicare example and what
we\'re describing when we talk about in person identification with a
provider is that it\'s a relationship‑based continuum. And so I\'d like
to incorporate in whatever we have as a discussion, however we lay this
out, that there\'s an ideal strong relationship‑based component, and
there may be a certain level of identity proofing associated with that.
And then you sort of express along the continuum the more tenuous the
relationship gets, the more vulnerable you are into exposing that
information.

I guess the reason why the in-person is so appealing is because there\'s
such a strong patient provider relationship. It\'s also why in the two
applications previously, CMS was able to allow access to this
information because they have that relationship with the Medicare
beneficiaries and Social Security Administration.

There may be other PHRs, limited scope PHRs, talking here examples where
there is no such relationship. And I think we need to point those out.

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

This is Deven McGraw. It might be helpful to add in a level of
voluntariness of participation. Because in the two Medicare examples,
you could be a Medicare beneficiary and decide you\'re not going to use
MyMedicare.gov because you don\'t have to unless there\'s a component of
this site missing. Similarly with the plan finder for the part D
program, again if people decide not to use it ‑‑ so in other words,
it\'s almost like an opt‑in for both pieces. Which to me makes a
difference in terms of sort of what you\'re buying into in terms of the
level of security of data that you\'re either entering or being able to
access.

With a PHR, I think we have to put in a range of the voluntariness
because I think it\'s going to vary for different people as time
progresses whether it is really voluntary or not. It might be a personal
health record, but if I am a member of X health plan and they require me
to use one as a function of being a member of the plan, well that\'s not
really all that voluntary.

Similarly when we get on to the piece about ER, the level of
voluntariness is even less. Where sort of what we\'re going to require
for people to prove who they are continuously, to me the level of
voluntariness, are you doing this because you have to or are you doing
this because you\'re going to benefit from the program?

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

There\'s some ways where what the patient or consumer decides could
definitely be factored in. You could particularly think of that in an
authentication scenario where they\'re able to accept certain risks to
make it easier for them. On the other hand, on identity proofing, it is
directional. You not only have to worry about them assuming their
identity, you have to worry about somebody else assuming their identity.
And you have to think about how to preclude that from happening. That\'s
where it gets a little more complicated from considering voluntary
aspects.

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

In addition, when you put that factor in there, you may also have them
assuming risk that is being borne by you, as well. So you as an
organization would shy away from participating in this kind of thing
because if I allow you too much option to make it easier for you, you
also may be potentially be putting me at greater risk.

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

Right. But I presume the people would have that knowledge. I mean I just
remember we got a little into the Internet banking discussion at our
last meeting. And the sense was that there are people out there who use
it. I never would because for me, there would never be a level of
security enough for me to put my ‑‑ have a financial relationship with
an entity where I never met a single person. But yet there are lots of
people who do it. And there is a distinct possibility that somebody
could, in fact, assume your identity and have access to a lot of your
information.

But people, for ease of use, are opting in to sort of an easier ‑‑

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

They\'re accepting risk.

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

Right.

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

Although that might be uneducated risk. And that\'s a whole other issue.

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

But it may be risk as we said earlier that the system can deal with,
too. I mean if it\'s purely economics and the financial services people
bear the risk of it and they buy insurance for it, that may or may not
be a good model for healthcare system. I think we talked about this a
little bit last week. My sense is that people, at least the limited
discussion we had, we were less willing to accept that kind of risk in
the healthcare system than perhaps we were in the purely just economic
system. But again that\'s a reasonable issue for discussion.

Okay. Let\'s see where we are right now ‑‑ continue through the
afternoon and through the next meeting until we get some better clarity,
we probably have something that approaches a shared view of what a
medication summary and registration history might be. But we do not have
definitions of what either of those are available to us from the other
Workgroup, if I\'m understanding properly. So we\'re making some
assumptions about what some of these things are. Is that fair?

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

When you spoke earlier about a PHR, you assumed that medication history
was something that was pushed to it. I\'m not sure that everyone would
have assumed that, even in some of the contexts that have been
expressed. I think realistically that is what that is talking about. And
it\'s not a question of the patient populating a medication history. So
I think my interpretation is that\'s a fair assumption. And that that is
the important assumption relative to achieving a certain level. And so I
think you\'re free to move forward in that context. May state it as an
assumption, but I think that is the prevalent assumption.

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

So let\'s make sure that whatever we recommend up makes clear that
that ‑‑ and that the other pieces of it may, in fact, be ‑‑ have a lower
burden of a need for protection. But that would be the higher part of
it.

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

Other pieces being (inaudible).

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

Or yourself entered OTC stuff or whatever else you\'re taking off label
or whatever. We hope that that\'s what people do with these things is
add to it, inform the value of it by saying I\'m also taking this thing
over‑the‑counter. Because it might be incredibly important to the doc.

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

Where would you put that in the spectrum?

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

We\'re trying not to right now. We\'re trying to stay on this.

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

I don\'t mean to distract.

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

Good, thanks. That will be helpful.

So given that, we have this information that\'s going to come from
another source. It\'s disclosure. It\'s inappropriate disclosure. Has
significant confidentially privacy concerns. Apart from the healthcare
concerns that may or may not accrue. So that\'s our environment. And now
we are testing what can we do to make a recommendation for what is
appropriate for purposes of identity proofing. I will share a personal
bias not about the actual recommendation but the form of it. I don\'t
think that what we need any more of are ranges of possibilities and
explanations about sort of this it could be relatively more or less
sensitive. Medication history is sensitive full stop. If anybody wants
to challenge that, this is a really good time to do it. Because I would
suggest strongly that that is where we are with this stuff.

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

I concur with that.

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

I would concur with that, as well.

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

This actually helps. So now we know what we\'re working with right now.
We\'re working with something that is highly sensitive. We\'re trying to
talk about whether we want to do this. Whether this needs to be done in
person or it needs to be done in another fashion. Or that there are
potentially a variety of approaches but that meet certain ‑‑ but that
overall meet a certain burden that protect the patient. And, again,
remember at this point we\'re still talking about identity proofing the
patient. We\'ll get to the rest, maybe.

So from what I hear, with all due respect to MyMedicare.gov example,
that would not make me very happy. And I\'ve got at least one headshake
in the room about that.

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

I will say it out loud. David McDaniel. It would not make me happy,
either.

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

Which part?

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

That you be able to have my PHR populated with medication history based
on knowing my ‑‑ let me go back to the data.

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

And these particular criteria.

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

Admittedly it\'s not that for in‑person.

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

Exactly. To be fair, the folks from CMS said we developed this for this
specific application use. And so I\'d be interested to hear from them
whether or not they have any thoughts on what it might be for this
particular application.

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

This is Tony once again. I was going to say that was developed for that
specific application. It should not be considered as relevant to
medication history. That\'s something we would have to look at
separately.

Certainly in the short‑term, medication history today would have to, at
least for Medicare, would have to be a paying through the plans. Because
we\'re not the owners of the part D information. The plans and the
people who sign up with the plans are the owners of the Part D
medication. So for us, it would depend on what the plans were doing in
terms of medication history. But you\'re right, we wouldn\'t use my
Medicare as an example how to deal with this because it was developed
for a much different reason.

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

Yeah. For purposes of continuing the discussion using the CMS examples,
it seems to me that we can, at this point, kind of talk only about
MyMedicare.gov. The other one does not ‑‑ is not a comparable situation.

Now, I guess what I would challenge you, Tony, a little, are you
asserting that claims information is less sensitive than a medication
history?

**\>\> Tony Trenkle:**

I\'m not necessarily saying that, no. I don\'t know exactly what types
of claim information they actually have on the site because I haven\'t
seen it. Oh, Elizabeth, do you have any thoughts on that?

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

It\'s my understanding that it\'s claim information. I mean I haven\'t
seen it, either. The problem is we\'re not Medicare beneficiaries, so we
can\'t actually ‑‑

\[laughter\]

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

My guess is, let\'s assume it\'s ‑‑ isn\'t there like the basic five
points, the date of service, the --

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

Provider will have some kind of code.

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

Right. It isn\'t translated or anything like that so that they can
understand it.

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

It isn\'t translated?

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

No.

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

On the purpose of this site, then, is what?

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

It just says 99375. It\'s not telling them what level visit that is or
anything.

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

But if we\'ll assume that this information gets into the wrong hands, it
is just as sensitive as medication history. The average person isn\'t
necessarily going to know what all the drugs are, either. But if
somebody wants to misuse it, they can look what the code is, what the
drug is. They may see that the clinic is a pick the name of your
provider. That by itself may be sensitive enough.

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

Let me suggest this. If you want to get into more in-depth discussion of
what\'s on that site, we should probably bring someone to one of the
future meetings to specifically discuss that. Because I think Elizabeth
and I are operating from partial knowledge.

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

I guess we don\'t really need to know that. I think there is a sense in
the group that we\'re willing to make an assumption that this claims
information, however presented, is if not equally a sensitive, certainly
at the same sort of four buckets of sensitivity wherever we\'re going to
put this stuff ultimately, which is a broader conversation to come. But
it\'s not substantially less sensitive than the medication history.

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

I agree with that.

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

Let me go from that. Both Paul and David said they wouldn\'t like that
level of identity proofing. What was the concerns? Let\'s flesh out.
What were the problem areas as you saw it? And what would overcome
those? Because if we\'re going to try to make some recommendations, we
have to identify what\'s wrong.

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

I think these elements you\'re asking for, these knowledge‑based
elements were elements that only I could know. And it would be such that
it wouldn\'t be information that someone who could impersonate me or
someone even close to me who wants to be involved in my care that I
don\'t want them involved in my care could get.

I mean I could see my elderly father, I could be set to buffer him. In
Medicare, that might be great. Because I might be a caregiver and it\'s
helping me help this elderly person. But in the instance of me having
this for myself or personal health record, I may not want that person
involved. So consequently, these elements would need to be elements that
somehow it\'s something that I know that is not common knowledge nor is
it something that somebody could readily get access to.

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

And that would include, if I understood what the CMS folks were saying,
that would include not only you knowing those things about somebody
else, the gender, you get the card, I understand that, but being able to
get access at their mail, right?

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

Right.

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

The neighbor that checks your mail for you every day and I got your
Medicare number, your address, your date of birth, your gender, all
those things.

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

Or somebody in your household, which is another thing to consider.

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

Right.

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

So I hear at least from what you\'re saying, David, at least we need
additional data points? You would feel more comfortable if there were
additional data points.

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

Either additional data points or data points that were more
sophisticated from making them unique to me and not retrievable.

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

Just again to contextualize this. This is as an alternative to the
biometric of showing up in person and showing an ID card to a provider
and looking at it.

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

Whatever way to define "in‑person."

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

However you define it, it is not foolproof.

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

Nothing is.

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

But it is much more foolproof than this other method.

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

But the challenge, of course, is that information needs to be available
to the company that\'s selling you the PHR that is doing the
authentication. I mean you may know the information, but unless I know
it, the company that is selling the PHR, has the correlated information,
that\'s the challenge.

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

Unless there\'s a transitive trust established with a third‑party.

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

The other thing is, since I always say that I don\'t like using the
financial services sector, it is rather ironic that I\'m about to make
this statement, but when you get a credit card, a new credit card, you
have to call the number and verify the telephone number you\'re calling
from. So it seems to me that if the letter that comes from CMS with the
password had a telephone number that you needed to call in order to
activate that password, that that may somehow provide ‑‑ I\'m not sure
what others think about, but that\'s another level of assurance to your
point about sort of who\'s opening your mail?

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

But if we presume that we\'re worried about people getting the mail,
they can get the mail and open it just as easily as getting it.

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

Right. But then they would have to provide some information over the
phone to say that they are the beneficiary.

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

It is not just calling if that phone.

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

Extension of. Not limited to calling from that phone. It\'s finding some
piece of information.

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

It seems to me that one of the issues we\'re going to be talking about,
and this is a bigger picture issue, but we\'re balancing or trying to
balance ease of use with privacy, security, and all these other
concerns. I\'m not sure where to go with that. If we start making ‑‑ we
have a point that you might have all these excellent data points but if
the company on the other end doesn\'t know the answer to the questions,
that won\'t work.

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

It\'s not just the ease of use. It\'s adoption. This would be impossible
to adopt if it becomes so difficult that people won\'t do it.

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

So I guess the question is are there data points that the company might
know to you that would make to the PHR that would make you, David, for
instance, more comfortable that somebody else can\'t go on and
impersonate you?

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

I don\'t know what those are. But if you\'re talking about developing a
relationship with a trusted third‑party, you could probably pass those
data points to them and they would be ways to ‑‑ if you had a person
saying I want to sign up, Mr. Provider, or Miss Provider, for this
service, you can pass my information. I authorize you to pass my
information for this third‑party and they will set this up for me. Then
you could give them some of those elements. Now I don\'t know what those
elements are. Maybe some of these work. I don\'t know the answer to
that.

I guess I lean more in the direction of the in‑person just because of
the struggle that we have with people taking other people\'s identities
and even taking their identification card and changing the picture on it
and even in‑person becomes difficult. So to take that protection away
gives me a little angst.

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

This is Paul. I don\'t want to take us back to fundamentals. But here\'s
what I\'m struggling with. There are a lot of smart people out there
trying to figure this out, also. But with SureScripts, they come to me
to get access to medication history. We didn\'t provide it because
nobody came up with it yet. What I\'m struggling with is we trying to
come up with the exact methodology or the principles? At least m my mind
we seem to be going back and forth a bit.

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

We\'re trying hard not to come up with the exact stuff. But we will at
best be able to come up with something that\'s descriptive.

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

It may be where we end up where we were going on secured messaging,
which is in person, still to be defined. In person is the preferred
method. I don\'t think we want to come up with a recommendation that
says the only thing we think is acceptable is in person. So it seems to
me we\'re looking at in person, what that means, plus some other
alternatives we haven\'t identified yet. We may identify things that
aren\'t sufficient. I don\'t know what direction we come at it from. If
we come up ‑‑ I mean I\'ll be interested whether everyone is on the same
page. Obviously the CMS people will be. More people are on CMS\'s page
or where David and Paul are in terms of elements they laid out being
problematic. I\'m not sure where we\'re going to be on that. But that\'s
with spectra. And we can work from the low end of the spectrum and say
this doesn\'t work, this doesn\'t work, this doesn\'t work. We can work
of sort of from in person and think what the closest things in person
are. But I think we\'re going to have something that says in person plus
some other kinds of alternatives. And it may be that we may end up
punting on the other alternatives.

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

Then the implementation I think what you will find is the consumer will
either opt in or opt out based on their comfort level based on the risk.
If I was in a situation where I wasn\'t comfortable with the risk, I
would opt out and wouldn\'t participate.

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

How does the opt-out happen I want to impersonate you? I\'m at a loss at
how your opt-out prevents me?

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

That\'s a good point, Paul.

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

That\'s one that we don\'t have a control for.

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

Bad people are going to do bad things regardless of how descriptive we
are.

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

Quite frankly the scenario that my Medicare has with the person, you
helping your father or helping your neighbor is exactly what those
people are going to want in most of those situations. I guess you do
have those opt‑ins. But if the neighbor is trying to steal your
information ‑‑

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

We talked a little bit surrogate in this as far as having some mechanism
or proxy. Having some mechanism for that in an official capacity rather
than in the informal let me just take the information and make it
happen.

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

I\'m sorry. This is Paul again. I want to react to what you said. I got
the impression that you\'re saying there aren\'t that many bad people
out there trying to get the information. All right. Because that\'s what
I\'m sort of reading into it. Because we talk about people getting
divorces, it happens every day.

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

Good people become bad people given circumstances. (Inaudible)

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

Let me throw this out. We obviously have a different perspective from
the VA and CMS to very large governmentally‑organized populations. We
don\'t really have OPM\'s perspective, I suppose, on this. It\'s
interesting that those perspectives, at least at this point, are so
different. Probably the two biggest populations. If you add the Federal
employees, that\'s probably the three biggest populations.

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

For instance we give a Veteran\'s Information Card and they have to get
that in person. They have to come in and sign up for the Veteran\'s
Information Card. The Veterans Information Card becomes a document
because it has the person\'s picture on it. They can present it and make
sure it is the person. And the information gets swiped off the card at
that point. We don\'t even put information on the card. So there\'s no
embossed information on the card. It\'s all on the strip on the back.

So we do that today with our VIC card.

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

I just wanted to go back to the question about what the outcome here can
be. This is a complicated area. There is no doubt about it. A lot of
people have thought about aspects of it. But it would be ‑‑ as much as
it\'s attractive to look for broad principles, it would be good to look
for principles that establish a threshold that needs to be, a basement.
And I think to do that we\'re going to need to a finer granularity, as
well. Because we\'ve just gone over the fact that in person, for
example, is not sufficient. And what in person, when we refer to in
person, we can talk about a variety, some bad, some good to identity
proofing. And we need to get another layer down in terms of talking
about in person identity proofing where a picture ID is matched against
the person. In person identity proofing where there is some sort of
criteria for a long‑standing relationship with a physician who meets
certain criteria.

And there may be non‑in-person criteria that meet that threshold for
establishing that, as well. But I think we have to get to that finer
grain granularity before it will start to mold together.

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

Do you want to take a stab at that? Now that you are going? I know
you\'ve thought about it before.

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

I\'ve thought about it before, but I\'m not sure I can just articulate
those thresholds. I think that for me, you can articulate an in‑person
identity proofing and you can pretty well establish that you need ‑‑ you
can look at some of the examples where you need to bring this, this, and
this. And then in addition to your physical presence and the picture and
the matching of the physical being to the picture, you can establish
that. I can see how that can be articulated and you could get to that
specificity.

In terms ‑‑ and then there seems to be two other bins. One is
third‑party in the context of at what level can you trust a third‑party?
Whether what are the expectations of a third‑party that you can trust
the identity proofing that they\'ve done with an individual. I think
there\'s value in articulating that that there may be groups that will
go down this road of this being their business practice to offer
identity proofing as a commercial service if it can be validated at a
certain level. And you could even envision a future where there was some
testing of their abilities to do that that could assure people that
there was validity in that. I think there are examples of that, as well.

And then but the harder one for me to envision immediately is this
non-in‑person. There are some various permutations of it around things
that are mailed out or identifying of a phone that they\'re calling from
which seem to go a long way toward getting you there but don\'t
necessarily get you out of the household issues. Don\'t get you to the
specific individual because you can\'t quite get that level of
assurance.

I think the challenge is could you construct a combination of those? Or
the right permutations of those and include something that you may have
received. Something about your physical presence in terms of a phone
number and certain things about your individual that would meet that
threshold. I think that\'s not clear to me that that\'s ‑‑ can be
accomplished.

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

What occurs to me as you say that is given that the adoption of PHRs is
going to be fueled by the executive order to have them adopted through
the Feds or for federally-paid insurance it appears to me that what
would be ‑‑ what should already have happened is that this would be part
of a spec, the spec for certification through CCHIT is how I would look
at it.

So given that that hasn\'t happened, there is an easy punt out of this
if we want it, which is to simply say that a certification standard
around identity proofing were being able to push data to the HR needs to
happen. And we can articulate what some of those elements might be to
help inform what the criteria should be for certification.

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

I guess my response would be to that that I think certification offers a
methodology. There are two aspects to certification, right? There is the
fact that they have been working to develop criteria, but there\'s also
the fact that they test to those criteria.

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

That\'s right.

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

And for me what certification offers, unambiguously in this regard, is
the potential down the line to be able to test to certain criteria. But
it doesn\'t necessarily mean that they are the ones that have to develop
those criteria in this regard. In fact, I would hope that ‑‑ because
that\'s a downstream process. And I would hope that there could be an
opportunity to develop those criteria and work them before it gets to
that. Certainly they have a process for developing criteria, but this is
not on their road map for accomplishment. And I just don\'t think it\'s
going to happen in the timeframe necessary to meet these needs, to
develop those criteria.

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

I\'m aware that it\'s not going to happen in our timeframe, but it kind
of ‑‑ understanding of one could have a PHR project and how that
doesn\'t have that security built in on the front end.

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

Let me ask this to John. Is it something that would be possible for us
to set some guideline criterias and minimum floor as well as have a
recommendation that CCHIT should put this on the road map? So
understanding it might not happen in this next cycle, but that it is
something, if in fact the group thinks it\'s something, as Paul is
suggesting, should happen down the road, that it\'s still the
recommendation?

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

I just wanted to point out the Consumer Workgroup is talking about the
possibility of having a recommendation with respect to PHR
certification. They may even get to drafting one over the next few
weeks. And so far what there seems to be emerging consensus around is to
do it for both security requirement and for interoperability
requirements but not for functionality at this point because the market
is too immature.

But given that, what John was saying is there\'s no sort of criteria
that\'s been developed outside of what HL7 has been doing in determining
some conformance criteria and functional model for PHRs. And I think
that no one\'s really thought about carefully what a timeline would look
like if in fact CCHIT would move forward early next year with early
planning and thinking about certification. But it\'s very likely going
to be a multiyear process.

If you\'re thinking about that as one of your levels or one of the
options, you just need to think about maybe that\'s a longer-term
possibility that still warrants a recommendation and could be consistent
with the other Workgroup, but that if you also want to think about for
the terms, for the purposes of a demonstration project for the
breakthroughs, that you\'d also want to have something that would be a
recommendation that would be applicable to implement one of those
projects.

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

The CCHIT group, I mean that\'s sort of certifying a product or an
application. And so where I\'m having a little bit of a challenge is
understanding ‑‑ we\'re not talking about, I think, expecting that the
applications are going to be able to do this necessarily, that it might
be the third‑party function that is totally separate from it. So I guess
I\'m just trying to figure out how instructive this part of the
conversation is to our broader goal.

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

I think it\'s helpful in recognizing the fact that there maybe needs to
test capability down the line and that that is substantial. And so
recognizing that. There is the issue of how do you, particularly with a
third‑party, how do you exchange those credentials and how do you
validly? So it begins to look like a network issue. So that may be
relevant, as well. But I do think that it would be unfortunate if we had
to wait for a CCHIT to have solutions recommended for some of this.

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

It sounds to me as though this might be a possible recommendation but
not necessarily as a substitute for coming up with some guidelines on
our own that would operate for the breakthroughs in the interim before,
in fact, there was a criteria or a process for that criteria. Is that a
fair statement?

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

That ultimately we want CCHIT to include this as part of their testing
routine? Yes. Is there anyone on the call or in the room that would?

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

Would you repeat that recommendation one more time, please?

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

Let me see if I can try to do it. That CCHIT should include in its
testing regime prior to issuing certification the planner and strength
of identity proofing.

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

To your point CCHIT doesn\'t come up with standards, as I understand it;
right?

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

They develop criteria. But frequently it\'s based on other work that\'s
been done elsewhere. And then they do testing.

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

Right. And then the other thing that CCHIT is not doing is evaluating
relative strength of feature components compared to another one.
They\'re intentionally doing that pass/fail. It has something or it
doesn\'t have something. And at least for the EHL products, they are
staying away from a relative scoring.

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

Yeah. I mean I think that the recommendation still stands, which is that
because you can do ‑‑ what they do is inspect ‑‑ a lot of what they have
been doing is inspection testing which can lead to multiple criteria.
You could have one approach or another and that still could be
inspectable. But I think it certainly would be reasonable for this group
to make a recommendation about the fact that there would be an
expectation that eventually identity proofing and authentication
methodologies would be part of certification process for relevant
products.

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

Testing them?

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

Testing them.

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

It sounds like CCHIT wants to have a black and white?

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

No, it doesn\'t have to quite be that. It is. According to the criteria,
you ether pass or you fail. But the material can be written in such a
way that they can accommodate a level of something or two alternatives
to an implementation. It doesn\'t have to be quite that binary.

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

Okay. Well my thought is it would be good to do that except this is only
one of probably 20 or 30 different criteria that this Workgroup really
needs to establish for CCHIT, then.

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

Probably.

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

And I don\'t think we have to think of them as the only output.

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

I understand.

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

We could think about next steps in the NHIN process and the
opportunities for how things can be advanced through that. And there are
obviously relationships to what kinds of standards need to be developed
and to meet expectations for levels of security, as well. So there are a
number of different pieces that could be responding to recommendations.

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

No doubt. I\'m just thinking that this issue is going to be a very good
outlet for some very detailed things we\'re going to come out of this
Workgroup.

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

John, Paul, who knows? Maybe functional requirements would be.

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

Yeah. I agree.

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

Okay. Where are we?

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

So I think we\'ve established ‑‑ this is a good discussion. It sounds
like we\'ve gotten some consensus, I think I\'m hearing, on the fact
that this should be included in the recommendation even though it\'s a
longer-term recommendation, but that we should probably work and some
more specifics. So we should probably get back to talking about
specifics and see if there are some guidelines we can provide as far as
minimum criteria for identity proofing, for either in person or for any
other alternative, third‑party or non-in‑person if we could get there.

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

Yes.

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

I wonder if we could go even a little farther than that. I\'ve been
sitting back and listening. And what I think I\'m hearing is that there
is some consensus still that there is advantages to in‑person proofing
for those types of scenarios where there is an in‑person relationship.
So that at a minimum, so that we would recommend in person identity
proofing for where there is that opportunity, for that face‑to‑face
relationship. So it wouldn\'t be either an either/or criteria for
in‑person or criteria for remote or Internet‑based or whatever, but that
if you do have the in‑person relationship, you really should be going
the in‑person route with criteria to follow, obviously.

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

And the third‑party method is ‑‑ I mean I am presuming that we are
sharing that it\'s contemplated to be in person. So it\'s another form
of in‑person with a third‑party. Obviously there\'s yet another level of
complexity possible full. A third‑party that isn\'t in person. But I
think we should avoid even going there.

So okay.

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

I was just going to suggest that it\'s going to be hard to construct
those thresholds in the level of detail in this setting. And that it
might be good to ask the staff to try to construct a draft threshold for
those criteria that could be then considered.

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

What\'s the sense of the room on that and the e‑room on that?

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

Can I offer another input that might help you all?

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

Please.

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

We are just now receiving some final draft deliverables from a PHR
environmental scan where they looked at over 50 vendors in the market
now. Through the test and the Consumer Empowerment Group, we heard that
some of the higher enrollment rates are among the employer‑offered PHRs
right now. Since employers may have both the means of doing in‑person
identity proofing but also having a reliable method of doing identity
proofing because they know their employees, that they may actually
have ‑‑ and we may even be able to dig down in some of the aspects of
the report or talk to people in the data collection to find out if in
fact they did uncover a reliable method that employers are currently
using.

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

I think that\'s consistent with what we\'re contemplating doing. It
would simply if in some of the detail potentially.

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

Right.

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

Yeah.

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

Do you have a sense of how the employers deal with dependents?

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

That\'s the big flaw in the employer method is it only works for the
principal and not for the rest of the family, typically.

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

Although I think some are accommodating caregivers. I think we\'d have
to look into that more to give you a good answer.

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

I guess my question here we\'re talking about employers. Do we assume
we\'re talking about the large employers of the world or your one and
two employers?

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

We actually heard testimony from small employers. But we did hear from
Omaha Meat Packing, which is not a large employer, but they have a very
robust program that is part of the enrollment program. Even those with
lower health literacy and English as a second language.

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

I think that the other thing that we probably need to say is it\'s clear
from the conversation that there is no single method that will serve
everyone in every situation. So it\'s important that we actually present
these various methods, because otherwise we will leave big chunks of
people out.

Okay. So do we have a consensus here to task staff to attempt to ‑‑ how
close are you to getting some of that information?

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

We have deliverables now. In fact they will be reporting on their
findings on Monday in the Consumer Empowerment Workgroup meeting. So we
will share it with you in a matter of days.

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

And anyone who has the time and space would be good to listen in to the
call on Wednesday. 1:00 to 5:00? 1:00 to 4:00?

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

1:00 to 5:00.

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

You get extra points for that.

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

Actually we will have a good presentation from Intuit, who has a ton of
experience with consumers and security with offering with all of their
other applications.

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

So if I can turn, it sounds like I\'m hearing some consensus that
in‑person should be done where it is an obvious possibility because
there\'s an in‑person relationship.

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

Define what that is.

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

That there needs to be some alternative method for where it\'s not
feasible approach. And that we ‑‑ ONC will try to go back and propose
some more meat based upon this PHR report and some of the other examples
that we\'ve seen to try to report back to the Workgroup. Is that a fair
characterization of where we are?

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

Yeah, I think the only thing I might wonder about, you said that there
needs to be another approach. And I think there are many needs to have
another approach, whether that approach can be constructed that meets
the expectation is what\'s partly what\'s being tested.

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

Apart from in person, yes.

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

Finer language around in person what that may be the option in that
regard.

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

To make the point. Would we consider in person identity proofing to
include the phone call from the office staff at a provider\'s office
that I\'ve been seeing for 20 years and saying do you know what? I know
you want this PHR, what\'s the mechanism for the call? Who calls whom? I
want this PHR and I want you to do something to turn it on. Do you
really need me to come in? I don\'t think so. We\'ve been talking on the
phone for 20 years. You know my voice. You know my phone number on the
caller ID.

Whether that\'s in person or not ‑‑

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

Somebody with a gun to your head on the other line.

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

We\'ve already talked about that way of identity proofing someone
outside of the scope of the PHR just when you\'re establishing who they
are for verbal receipt of a result. I think doing testimony at our last
in‑person meeting, we talked about that voice recognition not being,
again a perfect method, but something that is in wide use at medical
offices now.

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

Right. So to raise the issue is simply to help inform what staff is
going to try to describe. So I guess that in person may be more
accurately biometric involved.

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

Through personal contact.

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

Through personal contact.

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

Right.

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

You may be getting stuck on some terms that actually if we get away from
them it would be very helpful.

And before we take a break, which I think we are soon, I know I\'m in
need of, do we want to give a quick shot to see how this conversation
changes with respect to identity proofing and PHRs for providers? Are
there issues for others for the PHR providers, not health care provider
necessarily?

\[multiple speakers, laughter\]

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

We have been talking about the patient side. Talk about the other side.
I\'m not sure we want to start that.

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

The vendor idea, or the provider populating that.

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

Those would be very different issues. Because the vendor is supplying a
blank PHR. I don\'t think we care that much about the product. But the
vendor who is populating it with medication history or lab data is
something obviously that is critically important.

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

So are we talking about either the health plan or the healthcare
provider that is populating this PHR?

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

Or the pharmacy.

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

Are you talking about authentication of that entity? And their
authorization to populate? Because that gets into authorizations.

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

Yes, it does.

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

I guess the question is: Are there identity proofing issues with respect
to the other parties in this transaction that we need to address?

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

Sure.

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

Sure, but I think the question is ‑‑ I\'m not sure I would start with
that today. I\'m a blank slate today.

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

I\'m struggling with it. Because I wouldn\'t have come up ‑‑ we need to
talk about it.

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

For example, certainly on the provider side presumably, you\'ve heard a
lot of testimony, even at the in‑person about sort of lacks controls on
who gets in and out of these controlled, who can see these records. I
think we need some discussion on that. But I think that\'s bigger.

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

I thought your question to be by proofing, who is supplying the data.
That\'s what I heard your question to be.

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

Oh, okay.

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

Which is maybe the healthcare provider may be the PBM, may be the
hospital, may be the plan?

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

And then it sounds like the point, Kirk, that you brought up, I think,
about somebody accessing the data.

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

Or who.

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

I would say sure to that question. That\'s a different question.

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

No. Besides authorization, just because saying a health plan is
authorized to do it doesn\'t ‑‑ there\'s 5,000 people that work for that
health plan. We know who it is.

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

The identity, you\'re authorizing who within that entity has rights to
do what within that application.

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

That\'s one model. And there\'s also ‑‑ there\'s a lot of complexity
under those. I think the simplest thing would be to pick up how
providers get identity proofed. Individual providers who are
participating in the exchange. And then you\'ve got third parties and
people who are using and managing data in association with those. But
definitely much more to talk about in that respect.

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

For now then I think when I was reading through this, it occurred to me
that it wasn\'t specific enough to patient authentication. So I just
threw out this document, if we could make that explicit, that, I think,
would be helpful.

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

Restricted to patients.

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

That we\'re talking about recommendations for patients getting identity
proofed.

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

I think one of the comments in whatever report we prepare would be that
we didn\'t do the rest of this. And we believe that some of this work
will continue to need to be done.

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

Jodi can I ask a question? Is there any comparative analysis of other
countries that have faced this issue? Australia, U.K.?

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

Single ID.

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

Every other country?

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

Well Australia does it by region. The UK does it nationally. I mean
everyone that\'s far enough along to cite as an example has a
single-payer health care system.

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

Funny how they go together, isn\'t it? So shall we take a 10‑minute
break good? We\'re a couple minutes before 3:00. So we\'ll come back at
3:00. Good. Thank you.

\[break\]

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

Hey, Matt?

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

Yes.

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

Let\'s get started, please.

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

Okay. Welcome back, everybody.

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

So we are now going to discuss the secure messaging, number one, and
probably the only one, right?

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

Yes.

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

Recommendation, which is \-- let me just read it. It\'s not so long.
Clinicians or other ‑‑ that offer messaging services should implement
some form of in‑person patient identity proofing procedures for
patients. In some circumstances such as existing patients who have a
long history with a clinician, this may be accomplished by use of
historical data and practice knowledge. This may be allow patient to
begin using secure messaging with the practice even if their next
schedule in‑person visit will not take place for sometime.\"

So it seems to me that the key conversation here to be able to adopt or
to move this forward or not would be the conversation about what is the
relative security and privacy risk of this ‑‑ not encounter, but event,
a secure, which we haven\'t defined, right? Secure message?

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

Or information in a secure messaging exchange.

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

So making the assumption that it is secure. I guess that\'s the point.

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

I think that was, right, definitional.

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

How is the other Workgroup doing with that?

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

In terms of defining what secure is?

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

Yes.

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

That they really booted that over to you.

\[laughter\]

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

How nice of them.

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

I think one of the assumptions that we have here is ‑‑ I\'m trying to
find it. No, there isn\'t.

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

Yes, it does. The scope. This recommendation only pertains to secure
messaging. So, seriously ‑‑

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

Repeat your question, sorry.

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

You\'re telling me that the Workgroup tasked with developing
recommendations around developing secure messaging between patient and
provider do not have anything definitional or supportive of what
constitutes a secure message?

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

That Workgroup was the Chronic Care Workgroup. And one of their charges
given to them was to advance the consideration of secure messaging. And
I think that they were working from an assumption ‑‑ and Jodi, you can
correct me if I\'m wrong ‑‑ they were working from assumption of a term
of art in terms of what that represented as secure messaging
representing a communication between a patient and a provider. But I
don\'t know that they defined what \"secure\" meant.

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

But I think they were saying that simple e-mail was not it.

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

It was defined in several different ways. One was it was not about
simple e-mail. They were talking about structured conversations that
related to the kind of content. And so they were defining it in the
context of the Web portal‑based access to a communication.

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

Right and as a provider, I have seen this used frequently as a term of
art to refer to either encrypted e-mail or server‑based communications
that are messaged to providers and patients via e-mail triggers. But
I\'m sure there are better definitions that exist.

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

For the sake of common denominator, this is Dave McDaniel, could we not
go back to the ‑‑ if a secure standards will point to those as at least
having an industry standard for what would constitute a secure
transmission?

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

Where in the security? I don\'t know that there\'s anything.

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

There isn\'t in the security world. It basically talks about the value
of using encryption, but that\'s about it.

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

As an implementation standard, yeah?

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

It\'s even addressable. It isn\'t even required, if I\'m correct.

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

That\'s correct.

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

I\'m not sure what the outstanding question is. If the outstanding
question is: Do you need to consider secure e-mail as part of this scope
of this versus secure messaging done through a Web portal? I think
that\'s a valid question for which you could get ‑‑ we could try to work
a definitive answer for you. I think there was some fluidity in the
group as to what the approach ‑‑ whether secure, there was a secure
e-mail solution that would meet some of the expectations. Because it
doesn\'t usually structure the content and et cetera. But some of the
identity grouping issues are going to be the same regardless.

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

But should we care whether ‑‑ an e-mail seems to be a subset of
messaging. Should we really care? As long as it\'s secure and we can do
appropriate identity proofing?

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

I think it may become more relevant discussion as you talk about
authentication methodologies. But I would concur that it\'s not as
relevant in identity proofing. And that many of the issues are the same.

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

So then ultimately it becomes, for purposes of identity proofing, the
conversation is: Is there anything that this transaction is more or less
sensitive than the receipt of medication history? That\'s kind of how we
have been basing the conversation today.

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

Well, the other variable, which is just listening to the earlier
conversation, if people say, \"Oh, I don\'t want to do identity proofing
for secure messaging, I\'ll just send it by e-mail,\" which, frankly,
that\'s going to happen. Like I said, I don\'t know how that plays out.
We have talked a lot about whether secure messaging, however it\'s
defined, has that much value in our discussion as a freestanding issue.
I mean I do know, I guess both Deven and ‑‑ were talking about the
importance of the person as far as an education component perhaps more
than a privacy security component. I don\'t know ‑‑ if the answer is
without a lab test, could you send me the results by e-mail instead of
leaving them on the voice mail? I assume they\'re going to do that
because they will do that. In some ways we do have to define what we are
talking about in order to eliminate ‑‑ to not impose burdens that will
be inappropriate and not followed.

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

I think everyone was ‑‑ and, again, I don\'t mean to speak
authoritatively for the group but there was consensus that e-mail is a
form of messaging. The concern was: Are there viable ways of making it
secure? That are adoptable in a broad context. And then whether it meets
the criteria for structured messaging.

I mean, I think you could easily attack this in your recommendations and
have a definitive statement about what you\'re talking about. I think it
still begs the question that I heard Paul asking, which was ‑‑ so
forgetting the e-mail component for a second, in the Web‑based access,
is there a differential inconsideration for the type of information in
secure messaging from the type of information in medication?

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

And as you will hear me say over and over as we do this work, the answer
from my point is no, it is not sensitive information.

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

Yeah, I would agree with that.

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

It\'s information that could be sensitive.

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

Right.

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

Yes.

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

But you don\'t ‑‑ because you don\'t know whether or not a certain
patient finds this particular piece of information sensitive ‑‑

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

Some of the information that\'s exchanged in instant messaging would be,
everyone agrees, not sensitive, but not differentiate on that basis.

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

But almost is it fair to say that it is seldom not PHI?

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

Absolutely.

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

Well that doesn\'t mean that some patients might not consider it less
important to them. So to some people it might be considered sensitive.
But it is PHI, and I think we have to treat it as such.

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

The other thing when we\'re getting back into this discussion of is it
an e-mail versus a secure message, from the provider perspective, what
constitutes a transmission that they then keep as part of their clinical
record?

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

That\'s a totally different can of worms. It has nothing to do with
privacy, though.

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

I want to make sure we\'re characterizing the exchange appropriately. So
I think I\'m hearing that you\'re saying that probably one of the
assumptions we\'d want to make is that for secure messaging, one is a
secure communication. It is not simple e-mail. Whether it be a Web
portal or some kind of secure e-mail. So it sounds like the Secure
Workgroup, sending some kind of secure message. I think you\'re adding
the point that the assumption is it would be part of the ‑‑

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

Right. I think that\'s part of the differentiation between just, you
know, an every mail that I might ‑‑ e-mail that I might shoot off to my
provider or vice versa that doesn\'t fall under the umbrella of secure
messaging.

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

We still would not preclude a patient and doctor from e-mailing each
other.

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

Right.

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

As far as what we\'re talking about.

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

That\'s interesting. I hadn\'t considered that. But that actually is
helpful that it\'s part of your medical records. But then I guess I\'m
not sure which way that goes. Does that mean that it has to be something
that is kept as part of your medical record in order for us to, A,
consider it secure messaging and, B, be worried about identity proofing?

Let\'s say it\'s communication that is not part of your medical record.
For example, test results. Test results are going to be in the record
independently of how they\'re communicated to you. The e-mail may not be
part of it.

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

I would disagree. As a provider, I would say that any communication
between doctor and patient, whether it\'s a hallway conference, phone
call, e-mail, secure message, letter has to be documented in the medical
chart. Good medical practice would even say that ‑‑ actually would
demand that supplying the patient with test results is something that
you document. Not just that the results are in the record for someone to
see, but the fact that the results were transmitted in some way or
another. And typically some communication went along with it that
described the test results, normal, abnormal, what to do about them,
should always be considered part of the medical record regardless of
their mode of transmission.

So I think that describing something as being part or not part of a
medical record is kind of immature as part of our discussion.

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

I think I was sort of at the same place, which is I\'m not sure how
much ‑‑ if that is going to be in the record, I\'m not sure if that
advances it. And there may be some level of ‑‑ for example, that may
presumably mean that today an e-mail is part of the medical record as is
something you send by whatever we\'re going to define as secured
messaging.

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

It sure should be. If you have an e-mail with a patient and say, \"Your
blood pressure is inadequately controlled, double your blood pressure
medication,\" and you don\'t make that part of the medical record and
the following day the patient sees your partner and doesn\'t know that
your dose has been doubled, it could be a very serious problem. So for
someone who uses e-mail and secure messaging in practice, we make it a
standard practice to document every communication with patients.

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

So is there not then benefit to making that recommendation that it is a
part of medical record rather than making the assumption that people are
following that as a best practice but make it as a recommendation that
it is considered?

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

I\'m not sure it is in the scope of this Workgroup.

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

I think it is out of scope.

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

I would agree. This is Tony. Based on our discussions with the Chronic
Care Workgroup, I think that is out of scope. I think really we need to
keep it limited in this case.

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

Okay. So I guess back to the question Paul posed. Does anyone agree with
that information? And whether or not the standards for identity proofing
are consistent with what we\'ve already been discussing with respect to
PHRs and medication history? As part of the CHR?

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

I have only one variation. I agree that the information is just by
itself is not important and sensitive. I question whether there may be a
slightly different standard. Because from where I come from, if you look
at the matter of the bad actor, is authenticated to PHR, they send a
query and can get all the med history. There is no check subsequently as
to really who it is.

It seems to me in secure messaging, it\'s a two‑way conversation. So if
it\'s really not the person\'s patient, it\'s like an ultimate check. If
somebody gets on and says, \"Doc, do I have X, Y, and Z?\", that may be
an odd question that the doctor receives and it may trigger an alarm. Is
it different than just a PHR to send out?

**[\>\>\
]{.underline}**The other thing, the e-mail could be just as sensitive.
The phone call to be sensitive. Today we\'re not sitting down imposing
all kinds of ‑‑ maybe that\'s out of scope because we\'re not asked
about that.

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

I can get a lab test result on the telephone and nobody makes sure I am
who I am.

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

They do something. They\'re obligated under HIPAA to do something.

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

They ask who you are. Typically the person making the call knows you and
recognizes your voice. That\'s not to say they wouldn\'t be fooled. But
some primitive attempts with biometric \-- with phone calls.

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

But the receptionist ‑‑ I know I\'ve called for test results.

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

I think it is different in some offices.

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

I wonder what the take-home from that is. Because to be honest, I do
have great concerns that we set the threshold so high in this domain
that we cannot achieve what we need to achieve.

So I think we continuously have to revert to looking at the operating
practices and make sure that we don\'t. Because that\'s part of the
message there.

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

Right. I agree with that, John. It seems to me ‑‑ Paul\'s question, I
think we all agree on the answer to Paul\'s question. The secure
messaging information certainly could be just as sensitive as any of
those other categories because it\'s the same information. So we have to
agree with that. I\'m not sure what that does for us.

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

The difference, though, is that what you\'re describing is sort of a
one‑off. So I call, I get a lab test. But the continuous nature and the
potential to access much more information I think is where it starts to
concern me.

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

So you would say even though the information is the same, it is
different? The PHR different from a secure message? Is that her you\'re
going from this?

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

Secure message is different from a phone call?

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

Or random e-mail.

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

Random e-mail you would have a conversation.

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

I guess what I\'m saying is when you call to get a lab result, it may be
something you do once a week. But it could also be a one‑off thing. But
if you\'re talking about engaging in a dialogue with a healthcare
provider, there\'s a whole range of clinical, personal health
information that could be discussed through that process.

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

Sure. But the reality of this is this is kind of a bizarre ‑‑ this winds
up being a bizarre situation. We\'re attempting to recommend identity
proofing for secure messaging and we are not supposed to be doing so for
non-secure messaging, if you will, by e-mail or phone call or whatever.
If I understand the charge properly. And then to take your very good
comment that if ‑‑ that there again sets the burden high and we won\'t
get adoption, but the practice that everybody agrees to ‑‑ agrees is
happening is there isn\'t secure messaging going on all over the place.
So what are we doing to promote adoption of appropriate messaging by
making a recommendation for this when we know that the current practice
is not secure and we\'re not attempting to ‑‑ we\'re specifically not
addressing it?

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

There\'s some very good points there. A couple things I\'d tease out
from that. One is that I think there\'s value in establishing some level
of commonality among these things. Because in reality, many of these
things are going to be done as a package.

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

These things being?

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

These different functions that we\'ve just named. And it\'s really not
completely realistic to expect them each to have different thresholds of
access. So I think it is helpful to establish that in general, the
content of secure messaging is of an equivalent nature to push
medication history. And that is something that is helpful.

I would, in terms of the e-mail thing, which was talked about, there\'s
a difference between a patient sending an e-mail to a clinician, which
you can\'t really prevent as long as the e-mail address is available,
and then the method by which the clinician communicates back to the
patient. I don\'t think it\'s overextending to suggest that largely the
secure messaging that is being described here is being described as
\"the method\" for consideration for how clinicians will communicate
back to patients in this context. And the effort would be to try to
encourage them to use that secure channel instead of an unsecured e-mail
channel for communications that have clinical content.

So I don\'t think these are two totally parallel and divorced things,
but that the conceptualization of secure messaging is that that\'s the
direction that the working group expects clinical conversations to go.

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

Let\'s play that out a little bit. So if the overall goal is to
encourage adoption of secure messaging as a better mechanism for those
communications, then it seems to me that our place is ‑‑ we\'re not
going to be the encouragement function, particularly. No special reset
is going to make it easier to communicate than it is today. So the issue
we have to look at is: Are we looking ‑‑ do we think that the
confidentiality, privacy, and security issues are so substantial that
the thresholds we need to impose are significantly tougher than they are
today, which may be an impediment on the adoption? Can we live with as a
group something that doesn\'t make it much harder and therefore whatever
else is being done to encourage adoption will work? Or are we going to
say no, we\'ve got these very stringent high level to adopt? We can\'t
make it easier to adopt on privacy security grounds than it is today
because they can do it without nothing.

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

I think the original impulse behind doing this was that it was to
encourage adoption of this method, which means to encourage product
development, et cetera. And I think what we\'re supposed to be doing
here is to make recommendations about how these products should look. I
think that it\'s entirely appropriate for us to also say that this
conversation raises significant concerns about the current state of
business and that that may be enough. That may be enough to get us
muttered about under the breath of many providers of every national sort
of them.

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

I think that\'s a very good point. As someone who used secure messaging
and am very familiar with issues with provider adoption, I would say the
barrier to secure messaging is not identity proofing or not the fact
that this Workgroup has come out with recommendations or not. It
barriers have to do with general barriers with communication with
patients as opposed to providing services for patients. And they tend to
be economic. And they\'re seeing the same reasons why physicians don\'t
get on the phone with patients or don\'t answer the letters is the same
reasons that they wouldn\'t respond to secure messages. And that\'s
something that will hopefully get fixed by somebody else. And I would
agree it was Paul who made the recommendation that what we need to do is
assume that secure messaging will be pushed forward, we want to make
sure that secure messaging systems have appropriate privacy and security
bounds surrounding them.

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

And you would agree to make a comment that wraps to sort of say that
there are significant concerns in doing it otherwise as is commonly in
practice today? Just sort of cull it out, to make sure that everybody
gets that we\'re not suggesting that that ‑‑ certainly it\'s beyond the
scope, but also make explicit that we\'re not validating those
practices.

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

Yes, I would agree.

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

Does anyone have more to say about that? Because I think we can move on
to the next one, which is pretty damn exciting. What was our next one
up?

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

Whether we approve this recommendation?

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

Sorry. Yes I think we should read.

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

I think you jumped kind of quick. I did kind of jump kind of quick. SM1.

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

This seems fairly similar to what we were talking about with PHRs,
although there was some conversation about potentially other methods
besides in person key relationships. The question is: Are we assuming
that for secure messaging, we are in the same places where we were with
PHRs and we\'ll go back to try to come up with some guidelines on that
guidelines on that? So we will revise this, come back with something
consistent for secure messaging and for medication history and propose
that back to the group to discuss.

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

Okay. Super.

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

Oh, before we move on to the next thing, have you gotten any notice of
folks wanting to make public comment?

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

We don\'t put up the phone number until you guys ask for it. We can
certainly put it up if you want to try to take some calls right now?

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

No. Not just to take them now but to see if anybody wants to make
comments so we can time the meeting appropriately.

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

I don\'t have any way to gauge it until we put a number up on the screen
and see if anybody dials in or not.

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

Is it fair to say we have no one in the room who will be making public
comments? At least we have that. So we are just talking about potential
of telephone?

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

Can you just turn it on for everybody for a minute and see if everybody
wants to make a public comment? And we\'ll sort of queue it up if they
do?

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

Okay. I will jump in. If you don\'t hear from me, you can just assume
that nobody\'s called in.

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

Okay, thanks.

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

Can somewhere in the document that will be prepared address the fact
that ‑‑ and this goes to a point that struck me earlier ‑‑ but we sort
of disaggregated the secure messaging from the PHR, but the testimony we
heard at the last meeting was that in fact they\'re using the same
methodologies to achieve both. And so I want to make sure that we make
adequate ‑‑ have adequate discussion of that because certainly I don\'t
think we want to ‑‑ we don\'t want to make any assumptions about what is
or is not happening out there currently. And the recommendations may be
very different if we\'re talking about both simultaneously. So what
would be helpful? I\'m sorry?

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

Just an acknowledgment that you can\'t divorce these two, because very
often they may be using the same authentication to do both things.

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

I think we should be explicit about that. And I think subsequently where
we\'re going is that looking at essentially the same recommendation for
secure messaging as we were with medication history from PHRs. I mean we
sort of linked the to up by making the same recommendation on both
sides.

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

Based on the comment that you\'re making, which is that in fact these
often are linked.

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

Not only because they\'re the same level of sensitivity, but because
they\'re linked.

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

Right. But I want to raise the red flag with doing that because that may
be what\'s happening right now, because most working ‑‑ or PHRs that
provide rich value to patients are likely to be tethered to a healthcare
provider or institution. And I don\'t imagine ‑‑ and I would prefer to
think that as we have this more networked environment, that that won\'t
be a necessary condition. And I don\'t want to preclude people from
participating in a PHR independent of that. So I want to acknowledge ‑‑

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

It\'s both sides of that.

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

There\'s this whole world out there that we hope will be evolving. And
that\'s really the tougher authentication nut to crack.

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

Absolutely. Let me play that out a little bit. We sort of linked up ‑‑
the medication history was viewed as a PHR issue, right? Not an EHR
issue? I assume the way ‑‑ I know we haven\'t worked on definitions of
EHR. I thought of it in my own mind as something that is generated by
something other than the providers.

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

Not necessarily.

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

I think of the EHR as the provider side.

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

That\'s the provider\'s record. But a lot of the providers, then
institutions that have moved ‑‑ that advanced pretty far in this process
offer their patients a portal or a PHR.

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

So maybe the provider provides this information for the PHR. But I think
if we could say in general terms, not that we have clear definitions of
these terms, but the PHR is something that the consumer ‑‑ it\'s sort of
for the consumer\'s use and control. And EHR is for ‑‑

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

For example, I know we talked about health plans providing PHRs. And at
that point I think there\'s no link to secure messaging with the
provider and a PHR provided by health plans because those would be
disaggregated there.

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

I\'m not totally clear what the issue is there. There could be a couple.
I wanted to ask to try to have clarification. It seems to me you have
established that you should be considering some of these things in the
same way from the standpoint of the information that they contain.

You could also look at potentially patient access to EHR data, which in
the same light. Which is: It is being offered to a patient. It is, in
some ways, hard to differentiate that from medication history that\'s
pushed at them.

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

And was the issue of looking at them in the similar level, so to speak,
that some of the tethered products may have ‑‑ be better advantaged in
doing identity proofing or authentication than freestanding? Because
I\'m not sure that will bear inspection. I\'m sure partly through their
existing relationships, they may have that. But I would hope that
criteria that were developed for the level of identity proofing and
authentication would be agnostic to whether ‑‑ however the service was
being provided.

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

That\'s my point. I don\'t want to go so far down this road with our
recommendations that we\'re making an implicit assumption that while
I\'m very much in favor of strong provisions for identity proofing, I
think a lot of the value of PHRs eventually is going to be having them
completely independent from these entities that patients may have a
strong relationship with now. So I want to make sure that we
characterize the breadth of possibilities. But that wouldn\'t
necessarily affect your view of the identity issue, is that fair to say?
Or am I missing that?

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

No, I think it does. I think it makes it ever more challenging, then, to
figure out in the absence of in person identification, then, what you
do. In order to have that level of assurance. Is that clarified?

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

Right. I think it makes the whole ‑‑ it makes important for us to get
somewhere on the conversation about the third‑party method, if you will.

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

Right. I just don\'t want there to be inherent bias in our
recommendations, I think is our point.

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

About imagining what the paradigm is going to be for a PHR. Maybe
that\'s a much more succinct way of saying it.

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

Okay. So what\'s next? I\'m sorry I\'m not good with the numbers here.

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

Do you want to do the general ones?

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

I think we should do the EHR? So we\'re going to move on and consider
the recommendations for EHRs number 1 and 2. Page 6 of the document. The
first one says that the source document or documents used to perform
identity proofing should be securely stored and maintained separately
from the patient\'s EHR or other clinical data. And this was a
recommendation with respect to the harm that can come from the
persistence of the identity establishing documents in a medical record
and being bandied about, I guess.

Does anyone have any comments that would ‑‑ or any objection to this?

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

Well let me add some more. It seems to me the source documents that are
used for identity proofing, if any, because we are also thinking about
situations where identity proofing may not involve source documents.

\[laughter\]

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

And are you also describing certain information that may come from those
source documents and holding that separately?

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

That\'s a good question. So driver's license number versus a copy of
your license?

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

Yes.

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

There is no need.

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

You don\'t want the data.

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

So the source documents or information, the data points contained
therein.

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

It\'s got to be unique data points to put there. My name is on my
driver\'s license. You can\'t say you will not include my name there.
But unique data elements on the source document.

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

I do think that that is logically symmetrical. I think you may want to
do some due diligence in looking at, for example, the existing EHR
projects to determine their ability to do so. What kind of data they
actually record in this regard, because frequently those are the data
that are used for patient identification. Not necessarily progress.

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

Authentication.

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

Or patient identification.

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

You\'re talking about a patient ID number?

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

I thought what we were identifying here is that as you\'re building
information about the patient, that you may want to hold that separate
from the clinical data.

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

No, I understand. I agree. I have a question, though. And I probably
should know the answer to this but I don\'t. Is it standard that medical
offices do retain copies of source documents as opposed to just keeping
a list of what source documents were used to identity proof?

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

I\'ve seen it both ways. This is Jill Dennis. In fact, my own doctor
likes to take a copy of just about everything I have in my wallet when I
walk in the door.

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

I know the reason for that is typically because if there are problems
with billing and a payer wants further ID, we typically need to have
those. But I\'m not sure that that\'s really necessary besides front and
back of a health insurance card. And I don\'t know that we would, again,
be asking for a higher level of work that\'s now being done.

In other words, if we reframe this to say if source documents are
maintained, they should be maintained separately. Because I\'m not sure
that they should be.

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

You don\'t want this to be read as a recommendation that says you need
to keep this stuff.

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

Correct.

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

That to me is a fair point. If you don\'t keep that information, nothing
bad can happen with it.

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

Right, right. And you may just want to keep a list of: Patient was
proofed by visualizing a driver\'s license and health plan card.

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

I guess my suggestion, I mean I think it\'s a very good point. My
suggestion would be to write this in a way that doesn\'t look like
we\'re telling people they have to keep it. Well, we can do it two ways.
We can make it neutral on that or we should say you shouldn\'t keep it.
Shouldn\'t keep it, my guess, is going to go too far.

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

Right.

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

But we don\'t want it to be conceived as a must keep it.

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

Let me challenge it as shouldn\'t keep it too far. What justification?
Under what circumstances may there be for keeping a copy of my driver\'s
license or my driver\'s license number in a medical record? What
possible ‑‑

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

In any record or medical record? We still have the recommendation that
it be kept separately if you keep it at all.

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

And not available electronically. They never transmit.

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

That\'s a different thing.

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

If I walk in and give them my driver\'s license and they confirm that
it\'s me. They can just hand it back to me, we\'re done. Check we
proofed the guy. They can write down how they proofed it. They can write
down the information and take a copy of it and put it somewhere separate
from the medical record. They could write it down and take a picture of
it and put it with the medical record. We\'re clearly saying don\'t do
that last thing. Are we saying anything other than that? Are we going to
tell people that they have to do something other than that?

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

Well given that we\'re talking about an EHR, an electronic health
record, then what they put on a piece of paper in a file is outside the
scope of what we\'re talking about here by definition.

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

Except that people ‑‑ things can get scanned in. Pieces of paper often
get scanned into the electronic health record.

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

Yeah, that\'s not the distinction I would make. We\'re saying here, I
think, the recommendation as it was originally written, we don\'t think
that should get scanned into the EHR.

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

I agree. That\'s why I raised the point. I agree completely. But Paul\'s
question ‑‑ did anyone object to that point? That if you keep it, it
shouldn\'t be there?

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

That\'s the way I would phrase it.

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

That\'s as far as I would go.

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

So, Paul\'s second question, which was: Should we say you shouldn\'t
keep it at all? My view is that\'s going to go too far.

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

I could come up with a scenario where that would be troubling in
practice.

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

I think it\'s really going to tie providers\' hands too much. Especially
we haven\'t even got to the range of documents that are acceptable.
People may need to keep records that in fact this is what they relied on
to proof this person.

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

I don\'t remember, maybe this was Peter who started it, I think it\'s
fair to say not to write this to tell people to keep it. I also want to
say you can\'t keep it. We want it to be essentially neutral on keeping
it but if you keep it, it shouldn\'t be part of the EHR.

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

Agreed.

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

Do you want to read it the way I\'ve written it?

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

It might read if the elements are retained ‑‑ let\'s see.

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

Documents for identity purposes.

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

To perform identity proofing, they should be securely stored and
maintained separately if the patient\'s EHR and other clinical data.

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

That strikes me as conceptually the right.

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

Maintained to perform identity proofing is not quite ‑‑ you access them
for identity proofing. What they\'re maintained for may be ‑‑

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

Establishing documents. The identity proofing wasn\'t in the right place
in that sentence.

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

I want to call out and make sure we stress the point, not just the
document itself, but the data, unique data.

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

I think we have to stress that unique element. My height and weight on a
driver\'s license is fair game.

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

True.

\[laughter\]

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

There was a poll in the *Washington Post* this week. They asked men and
women differently. And it was \"when you\'re asked your weight, do you
say it correctly? Do you give it approximately?\" and men and women with
little difference.

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

They said you lie.

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

Some people say they lied. But basically they took about 10 pounds off.

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

That\'s pretty much of a lie.

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

The implications of that are boggling.

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

My skinnier twin brother.

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

I wonder if the source documents are stored in the EHR ‑‑ what happens
to the source documents that are necessarily for identity proofing, what
if it\'s stored elsewhere in the EHR for other purposes?

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

Unique, right?

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

Give me an example of what you have in mind. The driver\'s license
information, so that the photograph or ‑‑

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

But are we restricting it only to the photograph?

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

No. The photograph or the license number. Is there anything else on the
driver\'s license?

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

We\'re restricting it only to a driver\'s license?

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

No, I\'m trying to understand your question by using an example.

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

I\'m not actually sure that there\'s an issue here. I thought the
sentence was contingent on for purposes of identity proofing. If you\'re
storing it for another purpose, it doesn\'t fall under that
recommendation.

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

That\'s where I was going. Can someone give me an example of why you
would put a driver\'s license number or picture, driver\'s license
picture in a medical record for some other purpose?

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

A lot of States, the driver\'s ‑‑

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

The patient continuously claims his weight is different.

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

I don\'t know. I\'m sure that somebody will come up with a case where
something like that is occurred or has occurred or needs to occur based
upon a certain set of circumstances. The problem is going to be if
somebody reads this one way, they can say, "Jeez, we can no longer do
something that we need to do," and that will cause a problem.

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

That\'s why I\'m trying to understand ‑‑

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

I can\'t speak for ‑‑

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

Likely an eligibility issue. Eligibility for service issue.

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

Or it could be ‑‑ what if we put like an assumption or something else in
here, a constraint that to try to address that saying this would not
preclude the inclusion of information obtained for other purposes within
the EHR.

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

I think it\'s defeating the purpose of what this recommendation is for.
I personally can\'t think of a reason why you\'d want to keep a
driver\'s license. An insurance card, yes. Because sometimes you use a
progress note to get paid for a service. But I think the purpose of this
recommendation is to say whether or not there ever could be a need to
use such a document, it is an inherently dangerous practice to store a
copy of a source document with an electronic health record.

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

Let me give you an example that I just sort of thought of and maybe
won\'t be valid. Let\'s just say that I\'ve had my identity stolen in
the past. And so I am now ‑‑ so what I\'ve asked is that my provider is
saying sure, your identity has been stolen in the past. Somebody has
used your identity to secure services. So from now on, we\'re going to
store a copy of your driver\'s license on file with your picture on it
because somebody else could have gotten a copy or a forgery of your
driver\'s license and is trying to use that now to secure services.

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

But that doctor.

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

That\'s fine as long as it\'s not kept with their EHR and their clinical
data. So that seems like a front office as opposed to a back office
application. Am I missing something?

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

Then I might have a bad example. I\'m sure in the totality of our
nation, that somebody somewhere needs to be able to ‑‑

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

Alison makes a good point, which says we\'re saying you can keep it.
Just somewhere else.

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

But if somebody has a practice of keeping it today ‑‑

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

We\'re telling them that\'s a bad idea.

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

Yeah, that\'s a dangerous practice.

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

I don\'t have any problem with ‑‑ maybe what we should do in this
discussion today is let\'s re‑formulate the recommendation based along
the lines that we have talked about. We\'ll get that back out to people.
We should see whether anyone can poke holes in it.

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

When there\'s more specificity on what the items may be used for.

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

That\'s a fair point. I was thinking about what other ‑‑ Jodi made a
comment which I quickly said wouldn\'t be the right answer. But maybe it
is the right answer. What if we say that a health insurance card is an
appropriate means of identity proofing. I don\'t know that we\'d get
there.

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

That might be one document.

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

Again, maybe that\'s Alison\'s point that you would keep it separately
from the EHR. Not necessarily the EHR.

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

It\'s going to be part of your EHR because it is part of the
registration summary information. Isn\'t it? Your insurance information.

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

Sure.

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

It\'s not unique information in terms of identity.

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

Right. Because what\'s on the card is going to be input into the
demographic record in the EHR/PHR.

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

This is the whole avoid the clipboard point.

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

Right. Well hopefully.

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

So the only example I\'ve heard so far is potentially if in fact it
turns out that we say that a health insurance card is one document that
you can use to make identity proof, we may need to make a comment that
they can keep your insurance card number.

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

And it\'s a really hard case to make that that\'s a document to make for
identity proofing.

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

This may not be consistent with the language. If anybody comes up with
some holes that they poke, or concerns, get back to us and we\'ll try to
address it appropriately before turning it around.

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

Now we are moving on to general recommendations?

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

This came up at the last meeting. There were concerns about the ability
to convert from a paper‑based record to an EHR and a concern that it
would be impractical or impossible for a provider to identity proof all
of their patients to convert it and that this was an issue of records
management on the part of the provider. And so we drafted a
recommendation basically saying that converting from paper‑based
practice to one with EHR should not require physicians to identity proof
their patients unless there was an inability for the patient to access
the EHR and then we would roll back to identity proofing with secure
messaging recommendations.

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

Let me interrupt for one second. I want to raise it both with this point
and the point we just discussed about maintaining the information
separately. And I\'m just sort of focusing on this now. But we have
these listed as EHR recommendations. Do we think that in a PHR setting
her somebody is doing identity proofing, that it\'s okay to keep the
driver\'s license with the PHR? And, conversely, I think that when we
had the CMS folks talking on the call last week about this conversion
point, they weren\'t talking about EHRs, they were talking about what
we\'d probably end up calling a PHR, which is their claims history.

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

So these might be general recommendations?

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

I don\'t know exactly what general means. But I\'m not sure they\'re
specific to EHR. They\'re EHR and PHR, rather ‑‑

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

And EHR being longitudinal lab results and interpretations, yes?

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

I don\'t know that there\'s anything unique about the EHR piece as
distinct from the PHR piece. Both of what we have is EHR
recommendations.

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

\[Inaudible\]

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

Medicare claims history.

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

This is my notebook that I keep.

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

Maybe paper‑based isn\'t the right part of that recommendation. It\'s
converting of existing data to something that will be considered a PHR.
I don\'t think ‑‑ Lorraine was talking about the last call, I don\'t
know that she\'s on today. But the concern as I understood it was that
all this history which exists and I assume it exists electronically. It
probably at some point existed on paper. But now it\'s electronic. Is
going to be converted to something that is made accessible to members or
patients of what we\'ll generically call PHR. They didn\'t want to bring
in every Medicare patient in order to do that.

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

I think what was unique here is the comment that if this is simply for a
provider in managing their patients, that that\'s why it was unique for
EHR. Because if you read further in the recommendation it says if in
fact they were going to give access to EHR to the patient, then that
would be different.

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

That does make the point that it wouldn\'t discourage providers from
going to an electronic medical record. Because if they knew they had
that overhead, they may never get around to going to an electronic
medical record because of all the identity proofing that would have to
be done.

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

That\'s a fair reason why we can\'t just put in the word PHR here. Do we
need a similar recommendation, however, for PHRs that are taking
existing data? And I\'m raising the question. I\'m not sure the answer
to this is yes. Do we need a similar recommendation for something like
the CMS situation or health plans who are going to create PHRs out of
their historic set of documents? I don\'t know.

And similarly on the EHR1 recommendation, which is source documentation,
is that one where we should just write in PHR, also? Or as David was
saying here, is there some reason that we are in fact limited to EHRs?
Again, I can\'t think of that off the top of my head.

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

This all goes back to the earlier discussion of what the definition of a
EHR and PHR and at what point is one the other?

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

Let\'s say it\'s a pure PHR. It\'s something that a health plan creates.
It has nothing to do with the provider at the point of creation.

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

But isn\'t the insertion of data, patient information from a third‑party
or from an electronic system of some sort, does that make it an EHR? At
what point is it an EHR? So I\'m just saying nobody wanted to field the
question about the definitions earlier, I think it\'s because this is
very complex.

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

And this is very ill-defined. And I think this is a question that is out
of scope for this Workgroup as well. Not that it\'s not a good question
to have answered, but I don\'t know that we can answer it. I mean
getting to the question, though for EHR Recommendation number 1, I think
it should be EHR and PHR because what you\'re getting at is whoever is
the author of such a record and who is ever the keeper of the record,
whether it\'s the patient, the health plan, doctor\'s office, hospital
system, keeping a source document along with the electronic record,
whether it\'s the EHR or PHR or whatever will be called next year is an
inherently risky practice.

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

This is Jill Dennis. I want to echo that because I\'m thinking that even
beyond that to the commercial entities that are starting to offer PHRs.
And they\'re in no way, shape, or form a covered entity under HIPAA.
There\'s even less sensitivity to the dangers of inappropriate uses of
that information. So I think it would be wise to broaden the scope of
EHR 1 to include PHRs, as well.

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

This is Don, I\'m just getting off of people mover in Dulles. But I\'ve
been listening in to the discussion but I weigh in and I agree with you
folks.

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

Without trying to strain things further, it would be different in secure
messaging relative to EHR 1?

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

No.

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

No.

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

It becomes a general recommendation. Okay.

\[change of captioners\]

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

We could test it to make sure that feels good.

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

Great.

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

So we have the EHR 2.

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

No.

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

EHR 1.

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

Not EHR 2. You pose both of those questions.

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

Must identity proof.

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

They\'re consolidating their data in order to create a PHR.

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

Something that\'s available to the patient, purported patient.

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

You want to make sure you\'re giving it to the patient.

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

If you\'re going to start aggregating your data for a patient for use
with a PHR, you better make sure you\'re aggregating appropriately and
eventually ‑‑ and let me throw this out for the CMS people on the phone.
Is that recommendation going to be okay because your issue was how you
identity proof rather than whether you identity proof?

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

I guess I don\'t exactly understand.

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

Alison\'s point as she said it strikes me as an obvious statement which
is you have to have some, if you\'re going to make it available to an
individual, you have to at some level know who that individual is. You
described for the mymedicare.gov an identity proofing process it wasn\'t
necessarily an identity proofing process that everyone agreed with was
the right process. It\'s an identity proofing process.

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

Right.

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

So would you will be ‑‑ the way out, the way phrase it would you be okay
with that recommendation?

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

I believe so.

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

Can you say it again? Sorry. It\'s 4:00.

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

I think it would be the converse of our EHR 2. So simply converting from
a paper‑based practice or consolidating information for a PHR should
require an entity to identity proof their patient.

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

And again, but ‑‑ but the assumption there is that the whole purpose of
the PHR is to make it available to patients. So you don\'t have any ‑‑ I
mean EHRs could be used.

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

It\'s consistent with this one because you do it when you\'re making it
accessible.

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

It\'s just the use of EHR exclusively.

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

We should write a version of this for EHR.

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

We will try to take that back.

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

While we\'re on this one. It seems to me to your point about identity
proofing providers, we don\'t want to maybe get into that in at the
moment but I guess an assumption I\'m making is that before any other
provider is going to have access to the EHR, they will be properly
identity proofed and this is just limited to, as this statement talks
about patients.

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

Got excited there.

\[laughter\]

There\'s symmetry by PHR access by providers, which is actually the
converse. And many are interested in, should also be potentially
addressed, eventually.

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

Okay. So I guess two things on the table is comments of adding a
recommendation, before another provider access PHR, just like here, that
they should be identity proofed we haven\'t talked about what that means
here yet and I\'m hearing a corollary the same is true for PHR, patient
identity proofed.

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

Well, let me stop there. I mean, for example, a lot of times I assume
what that\'s going to mean is I\'m the patient and I have my little PHR
with me and I walk to the doctor. I carry it with me to the doctor. Log
on or give them a specific code or whatever.

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

But whose responsibility is it to identity proof the provider at that
point. You\'re not going to make the patient do that, are you?

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

Well, they have biometric. You\'re my doctor.

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

But I think don\'t we have to tailor that recommendation to someone
other than the patient sharing it with a provider?

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

Well, I guess my question is because if it\'s really my record, which to
me is the fundamental aspect. If I want to give it to my wife I have the
right to do it or my worst enemy because my record is mine.

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

I agree with it. That\'s why I don\'t think we can write a general
statement before PHR is given to a provider the provider must be
identity proof, before someone else, before if health plan gives it to a
provider or before ‑‑

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

But maybe a better way to say this before PHR is accessed by an entity
other than the patient they have to be.

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

Again, access by patient. The patient gives them the right to access
through the authority of the patient.

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

I think you\'ve just got a clause you\'ve got to put in there talks
about the patient providing the access which would enable it.

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

Somebody who isn\'t a patient having access to a PHR either the patient
needs to authorize that access or the individual must be identity proved
or the patient\'s proxy, which is something we haven\'t really talked
about, but we want to make sure that caregiver is in there.

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

I think I agree with the point about the PHR being the control of the
patient, though. That the patient controls who has access to it. They
can give the authorization to others to view it, but it\'s the patient
who has control of it.

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

That\'s going to beg the question under what circumstances would someone
access a PHR without authorization.

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

Is that definitional. I don\'t know, for example, let\'s use ‑‑ let\'s
use MyMedicare.gov if we\'re going to call that PHR, could Medicare make
that available to a doctor?

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

No.

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

Not without the patient ‑‑

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

Wait.

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

I\'m sorry, that\'s because I assume that\'s because of how you define
that program rather than a legal issue for example under HIPAA that
could be a treatment disclosure, perfectly appropriate disclosure maybe
it just doesn\'t, if we\'re going to define PHRs in a way that doesn\'t
happen, which is fine, I don\'t know how they would be used.

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

That\'s very limiting, though.

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

You\'ve seen provider issues separately in other contexts maybe you just
want to bend this with those and deal with it subsequently.

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

I think we should leave, Paul\'s question is a good question and a good
thought. I\'m not sure we\'re necessarily going to point for a
recommendation on this.

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

But I thought I said it\'s an assumption. I think it should be in the
assumption because we don\'t want to assume the ‑‑

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

You want to assume ‑‑ I\'m sorry, in the EHR?

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

In the context of this recommendation, where we talk about providing
patient with the ability, my assumption then is that before another
provider or another person is provided access, they are properly
identity proved. That\'s my assumption.

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

Are you an economist by training?

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

That actually is ‑‑ yes, my undergrad degree.

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

Can I weigh in on a moment? Hello. Can I weigh in a moment? I think that
once however a patient has given information from a personal health
record and it\'s gone into the electronic medical or health record,
it\'s then part of that record patient can\'t keep pulling it in and out
and getting identity checks all the time. And I think the point is that
these personal health records are of very many types and it\'s not
shaken out yet. But clearly what we\'ll want to see over time is this
same, these migrating together so the patient and the provider can
actually share and see similar information to the extent that the
patient wants their information to be shared. But once it is shared, I
don\'t think that you can then pull it back out and say it\'s now still
part of a personal health record and the identity thing has to start all
over again.

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

You can\'t, and I don\'t think anyone is saying that you should.

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

I\'m sorry, maybe ‑‑

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

I hope not. If I\'m wrong, we have a real problem here.

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

But it actually is a good example of the issues surrounding the
definitional problem. I mean in my worldview once that patient has given
the information to the provider or hospital to put in the, in the
medical record, it\'s part of the record, done. It\'s not PHR
information any longer.

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

Thank you. I think that\'s the right way to go.

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

Isn\'t that making the assumption, though, that by giving you access to
my personal health record I\'m also giving you authorization to take
that information and put it in my electronic record?

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

No if we need to make that clear with an assumption or statement,
perhaps we should do that. I think very much that is not the case.

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

There\'s a read, write, you know differentiation that comes with the
level of authorization.

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

There could be that assumption if you\'ve given me that I can now put it
in your electronic record.

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

Why don\'t we put more details under there, they\'re very complex.

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

Liability issues.

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

I would think from what Peter was talking about earlier that means I
know something about you that\'s relevant to your medical history and
I\'m not allowed to put it in the record I keep on you.

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

People do it all the time.

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

Yes, but that\'s a terrible medical practice. And I think most
physicians would be wise to say under such circumstances that they
can\'t care for a patient who says I\'m going to tell you something
about me but don\'t put it in a record. Very dangerous practice.

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

Clearly the only place that\'s widely done is done in psychiatry. But
that\'s a special kind of category. In general I totally agree with the
statement that was made.

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

The whole raft of issues that are not clear that they\'re completely in
scope of the recommendations. I think as you craft the recommendations
you may need to go further down some of these roads.

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

We can say in the scope section of this one that there\'s still
questions about how a provider may.

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

Convert EHR into PHR.

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

That we\'ve not addressed that here.

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

I think that\'s fine. I think we\'ve spent a lot of time trying to
address a couple of small recommendations now we\'re throwing out a
whole bunch of new ones. That\'s good but we should make sure we ‑‑ I
don\'t think we need to add new recommendations. I started that. Let\'s
try to get the ones we\'ve talked about so far that are sort of
offshoots of what we\'ve already agreed on. Let\'s get those written
down. Let\'s get those disseminated so we make sure we\'re on the same
page.

This actually becomes an issue that we will address in an authorization
conversation soon to come.

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

One of the other things is that we\'ve got to be clear in whatever we
provide to the AHIC that this is, these are very, these are initial
recommendations based on the start of our discussions and that we\'ve
focused it but there\'s a whole universe we haven\'t addressed yet. I
don\'t know that we can ‑‑ if there are clear things we want to be extra
cautious and say we don\'t want to include that piece that\'s fine but
if we want to list all the things we haven\'t done on each of these then
we\'re going to have a heck of a time.

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

Move on to the next?

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

Let\'s start with GR 1. I will try to address this a little differently
than the other ones which is I don\'t like this recommendation
personally. The general policy recommendations of this group are not a
substitute for well-implemented onsite risk assessment, it\'s considered
to be best practice and information given. Risk assessment is obviously
a critical component of the security rule. We\'ve just spent a lot of
time, for example, discussing how custom PHRs or information in a
medical history, things like that. I guess I don\'t think it\'s
appropriate for us to come out with a recommendation essentially then
says if any doctor wants to evaluate it differently they should just do
their own thing on a risk assessment, which is how I read this
recommendation. I don\'t want individual ‑‑ I think that one of our
challenges is as a group we\'re doing somewhat of a risk assessment. We
had a discussion very quickly about is this category of information at
the same level of risk as another category of information. That wasn\'t
perhaps scientific, but I think it was something that we all came to the
same conclusion on pretty quickly. I don\'t think we want to leave it
open to anybody in the world, a doctor, a PHR vendor, or someone else,
to say I\'m not concerned about medication history. My risk assessment
is that is very low and I\'ll disregard everything. I think that would
be a bad approach and I don\'t think that should be a recommendation.

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

Could we leave this recommendation and put the converse in with it to
say that not only does this not, this recommendation doesn\'t take place
of the risk assessment, but a risk assessment doesn\'t take the place of
these recommendations either.

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

I\'m not sure if that\'s what I hear you saying.

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

I would delete it.

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

I would agree, because one of my concerns, when you put in language like
this, is that for people who are generally in favor of moving toward
EHRs, PHRs, and secure messaging, when they see something like here are
recommendations for good practice, however this does not substitute an
onsite risk assessment. That\'s often a deal killer particularly for
physicians in small practices who say it\'s not worth the trouble for
me.

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

And it gives other people the ability to say I can do whatever I want.

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

Right. Right.

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

Exactly. I agree with your ‑‑

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

I would delete GR 1 as a recommendation.

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

I agree.

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

I guess my question, I\'m somewhat loath to use HIPAA as a floor kind of
analogy but is this a floor? I\'m not sure we want to give the
impression if someone believes they should do more than what is
suggested then they can do more.

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

That\'s a fair question.

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

But if you add what was there, it raises the whole issue. If it\'s not
there, you don\'t know what\'s for sure.

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

No, let me play out that out a little bit. Do we want to say explicitly
that these recommendations are considered a reasonable floor of privacy
and security protection but in an individual situation a provider wants
to, for example, impose additional hurdles on identity proofing they\'re
free to do that? That\'s a fair point. I mean we can say that or not say
that. I would agree with that statement. I don\'t want anyone to go the
other direction.

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

Sounds fine to me.

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

Identity proofing.

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

Using that as an example.

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

I don\'t know if that\'s a recommendation or an assumption or what. But
that strikes me as a fair point to say.

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

It may have been necessary had we not sort of deemed PHR data for the
breakthrough as sensitive. So we\'ve sort of, we\'ve done that job.

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

You want to delete this or do we want to give the hybrid ‑‑

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

Gone.

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

Okay.

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

This is Jill Dennis. Before we leave that point let me just ask you how
a statement like that could be a little bit of a barrier. People going
above and beyond, you know in concept it sounds great. And it is great
in most situations. But in the case of, for example, healthcare proxy,
where this particular provider wanted to set up all kinds of hoops and
obstacles and additional requirements and things like that, it really
puts a burden and it sort of frustrates the whole purpose of, you know,
of having this information more available. So I agree with the concept,
but I\'m just worried how that could be interpreted to say well then
I\'m going to put in all these additional hoops and ‑‑

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

Well, Jill, the proposal on the floor is to just delete this
recommendation. Not replace it with what Paul was suggesting. I think we
should keep on our, what\'s our consultant phrase, our parking lot, is
that the phrase, that says let\'s keep that in mind whether we should
come back to that point or whether we should, you know, whether that is
something we want to clarify at some point. I think that\'s a fair thing
to just not lose sight of. Right now let\'s just get rid of this
recommendation.

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

That\'s distinguished from vetting something which means you\'re going
to deal with it you\'re going to deal with it.

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

Vending.

\[multiple speakers\]

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

GR 3.

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

GR 2.

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

I tried to number these better for you Paul.

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

Three is fairly meaty. This might be worth, I don\'t know if we have
time to talk about it. \[inaudible\]

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

Do we think we\'re at a point where ought to make an authentication?

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

I guess I\'m inclined to say we\'re not ready yet.

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

Well then we could talk about G 3 to see how we do, just to see what
kind of issues it raises, if people ‑‑ that\'s fine. Or unless, we\'re
still within the time.

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

But the other main thing I think we need to cover today is our next
steps, particularly we have, we have this call I guess on the 13th which
could be as simple as finetuning the recommendations. And maybe ‑‑ maybe
the discussion today has not, we\'ve actually made more progress than I
thought we might make today and we haven\'t had situations where we
said, oh, we really can\'t do something because we need this additional
piece of information. So maybe on the 13th we don\'t actually need any
additional information and we can really focus on the recommendations.

If that\'s the case then we can spend the rest of our time on GR 3 and
not worry about the next steps.

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

Alison just said something to me offline exactly what will happen is
we\'ll wind up I would imagine with a fairly lengthy conversation on the
13th to describe these non‑in‑person, these alternative methods of
identity proofing. That\'s going to be in the conversation.

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

I\'m sorry, which issue?

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

In person or alternative.

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

Discussing the alternatives.

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

And what the elements might be.

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

What it means to in person identify.

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

Hold onto that for a second. One question is do we want to do that right
now. So I\'m not sure ‑‑ I mean if we want to make a recommendation
about that, we clearly need to have it. If we want to make a
recommendation on that for the December 12 AHIC meeting we clearly need
to do that. But if the question is as to whether or not we want to take
that on right now with that December 12 or December 1, whatever the
deadline is going to be, or not.

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

I don\'t know what the next iteration of the document is going to be.
And suspecting that there would be some language regarding those topics,
I anticipate that they will want some discussion. That\'s my own point.

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

I do think it would be helpful if you talk to GR 3 because identity
proofing and the work the staff is going to do is not totally
divorceable from authentication.

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

My only point is there anything else we need to cover in addition to GR
3? If the answer to that is no we can spend the rest of today on GR 3.

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

And I think it goes back to Tony\'s point about the life cycle issue
although we\'re not getting at the whole life cycle, they\'re so
intertwined that if there\'s some commonality on user authentication it
would be great to be able to find. If not, not. But I think it\'s
probably worth talking about it and seeing where we are.

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

So let me ask the question of John and actually whoever wants to answer
it. I\'m assuming that getting recommendations with respect to
authentication for these breakthroughs are going to be order of
magnitude far more complex, far more nuanced than for the identity
proofing stuff. So it seems highly unlikely we\'ll be able to get this
done for much of anything done for December 12th. I mean one of the
things we need some advice from staff, not for today, but probably for
the 13th, is what are the expectations from the AHIC with respect to,
are we supposed to pretty on with this stuff or we have a new, you know,
knee‑jerk to move on to something else?

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

I think that\'s actually something that we need to put on the agenda for
November 13. We started talking about off line. But we need to, I think
we need to have a good robust discussion in this group about next steps
and how much (inaudible) in this. And we can do some thinking behind the
scenes, the staff levels, try to help provide information on where we
think we are on the issue.

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

There\'s been a lot of background work on authentication methodologies.
You could attack it at a similar level. I think there\'s ways of
addressing it that might actually result in quick recommendations.

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

If not December 12 but soon thereafter.

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

GR 3 it is.

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

I have a question. Can someone please explain to me what exactly is
meant by Network Health Services.

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

That would be Michael.

\[laughter\]

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

I thought you were going to ask about the patient assuming the risk.

\[laughter\]

Perhaps he was suggesting.

\[laughter\]

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

I think the concept here is network access as Internet access was
expressed before. And that maybe you would be more comfortable
describing Internet access. Internet access actually implies a slew of
things that I\'m not sure you\'re always saying, if you dial into your
hospital and access it, that\'s not Internet access. But it potentially
is networked access as well. So I mean there are terms here are
difficult. But ‑‑

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

Is it simply electronically accessing?

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

And does that describe the fact that if you\'re physically carrying
something with you that it has to be authenticated as well because it\'s
electronic, right? I think that\'s another differentiation.

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

But in order to make sense of whether we\'re going to recommend
two-factor electronic authentication, don\'t we have to know what we\'re
talking about?

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

Absolutely. And who is the you? Are we assuming again that\'s just the
patient? Or are these other entities viewing the content?

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

Bringing content. So is this broader than the other examples?

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

Yeah, I thought this was relevant to the patient access. But I don\'t ‑‑

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

Okay. So patient access.

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

To electronic health information and then you fill in electronically.
Transmitted electronic health information.

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

And you\'re on the verge of telephony which if you\'re not careful
you\'re also including in that, which is an electronic transmission. Or
fax.

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

So this is suggesting and we can try to frame it so appropriately, but
hearing patient access and I\'m hearing transmit electronically, not
clear if we really mean Internet or network versus ‑‑

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

I think the majority of what you\'re trying to get at here, if I\'m not
mistaken, or that they\'re trying to get at is Internet access
information.

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

Let\'s point it out. You\'ve got Internet access. There\'s two points.
What kind of information transmission are we talking about and two
what\'s the point we\'re making about authentication, and I\'ll let you
guys take it on the consumer side. But it strikes me as hard to say that
the patient assumes the risk. It just strikes me as they never have any
idea how do we make sure they have any idea what\'s going on there?

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

I think you should ‑‑ I mean so define what it is that\'s important
before you talk about what it is. So are you saying you have a shared,
there\'s a shared ideation about what it is, which is generally Internet
access but it could include some sort of private network access?

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

\[inaudible\]

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

So that\'s what the it is. And the second question logically potentially
is what kind of authentication would be appropriate in general. And the
classic issue here is that from a Supreme Court perspective two-factor
authentication would be in many respects desired. One factor, user name
password, something that you know as one factor. And whereas here you
would like to have something else. Biometric or something that you have
as well as getting to a different threshold of security. But classic
problem is that adoption of the second factors is very difficult
historically problematic. Whether it\'s individual\'s certificate.
Biometric implies additional technology, et cetera, et cetera. This is
the conundrum that this activity has been in for some time. And so the
suggestion here that there may be a way to educate a patient to assuming
risk because they facilitate adoption that they\'re willing to do their
Internet banking and they\'re willing to do this with a user name
password if they adequately could be educated to what those represented
is one way out.

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

So the conversation, just to have, if you replace the word besides with
provides informed consent to.

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

Informed consent meaning?

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

That\'s the language, too.

\[multiple speakers\]

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

As made aware of the relative risks and benefits of the choice.

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

Chooses and ‑‑

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

And send after be educated about the level of risk.

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

Thousands of patients have made this and Massachusetts has an opt-in and
only 3,000 people haven\'t opted-in to that kind of a system. Similar
out in Utah. We have an opt-out, and only three percent of the people
have opted out sharing immunization data. So there\'s a fair amount of
evidence that in fact with information people will take that choice and
take that marginal ‑‑

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

If I can make another suggestion that the opt-in/opt-out language may
not be good to use in this context, because people can construe it as ‑‑

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

I totally agree with that point. But I was making the point that people
in fact do this at the moment and actually in large numbers and over 95
percent.

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

But those two examples reflect the current paradigm where you have sort
of an existing relationship with a healthcare practitioner and sort of
the tethered environment and the extent to which that transfers beyond
that environment may not, just speaking to I think that was Don\'s
comment.

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

It would seem this clause would be supportive of the un-tethered
environment because it may not have the same leverage for those
established relationships and so I think in an un-tethered environment
the concept of the patient making the choice, having a choice would
actually be encouraging of that market.

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

Yes, I question whether or not it\'s in fact feasible to counsel someone
adequately up front so they can make that decision as this is worded now
and I\'m just not sure I\'m just raising it as a question because seems
there\'s a heck of a lot that people don\'t know about the vulnerability
of their health information.

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

Who would bear the cost of the increased authentication that a patient
might want?

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

The patient or somebody else?

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

That strikes me as a real problem because we\'ll set up a system where
it\'s easy to identity proof and hard to actually use it in some
situations. And we may end up forcing people to accept the risk because
that\'s the only way to get access to the system. I assume that\'s not a
good \--

\[multiple speakers\]

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

It may be the only practical choice for a lot of people.

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

Well, you\'re right it\'s not a choice but what\'s our alternative to
that also?

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

It\'s a barrier to using a biometric because the patient isn\'t going to
invest in the technology to be able to have a fingerprint scan or
whatever. You\'re basically saying either you need authentication and
there\'s a ‑‑ there may be a conclusion to some people participating
that way or this is what we\'ve got now and you can opt to choose it or
not choose it.

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

I think one-factor and two-factor have reasonably precise definitions
now, are those the only choices? But is there a better one-factor, is
there actually ‑‑

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

There\'s some more ‑‑

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

I don\'t like this choice when one of the choices isn\'t going to be
realistic for a large body.

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

If you think of a bank, some of the banks are requiring more than one
password. So you might have an account number or a user name and
password but to get to any transactions, you have another password.

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

There\'s some two new factor technologies that require you to have
something like a fob too.

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

Just a personal opinion at this point which is I don\'t think we have
the information to go very far on this one yet. I want the understand
what those are, if there\'s a realistic way to do something that\'s
called two-factor authentication I\'d love to hear about that. Right now
as I understand these two terms I don\'t particularly like the choice.
So I\'d like to know if there\'s other things that we can put on the
menu to choose from and I don\'t know today what those things are.

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

You don\'t necessarily know it\'s going to be there tomorrow and you
have to be careful about proposing things that might change. And this is
an area that\'s going to change rapidly.

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

I assume in a number of years there\'s going to be realistic two-factor
authentication that\'s not going to cost much.

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

Thanks. That\'s the comment I want to make. I think that we\'re hitting
on a couple of things we\'re about to talk about the (inaudible) and the
four magic levels which we probably don\'t want to do a 25-to-5 this
afternoon. And we\'re also, and for my money to the extent that we\'re
doing this we\'ll make decisions based on cost benefit. I have to tell
you that a question of the number of the assumptions that are properly
made with respect to the cost of implementing some of these measures and
I would argue the benefits that would accrue in terms of patient
wellness that that changes the cost benefit dramatically. A 20 dollar
card reader may not be the worst thing to buy for millions of people
that buying for millions of people drops to 2 if not 5.

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

Can I counsel one thing too, also the HIPAA security rule is very
careful about avoiding proposing specific technologies. As I said before
because of the fact that technologies change and threats change and
issues change that might provoke having to look at different types of
technologies. We probably need to be mindful of taking same approach we
have to be more specific in certain areas because we have to be very
careful about not getting too prescriptive.

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

May wind up that we need to make some recommendations around PHRs that
bring, somehow bring that into the fold of something that approaches a
security rule, if that\'s the best we can do. And we can\'t, I don\'t
think we can just be silent.

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

No, but we have to be very careful not to date this in a way that really
makes these recommendations irrelevant or bad in two or three years.

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

Let me throw it out for right now which is my view would be to remove
this recommendation for the time being as premature.

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

We have a parking lot.

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

With a village.

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

It does strike me as this is something that\'s realistic for us to
address and something we should address but we\'re just not there yet.
And maybe that\'s the next hearing or that\'s a panel at a next hearing.
But I think we need to do that. Maybe we can do it through research as
well but I\'d like to see what the range of two-factor options are.

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

This is the working policy group, and so we need to work from there.
Wonder if we should turn to the public comment, see if we have any.

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

There weren\'t any earlier but let\'s try it again.

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

I\'ll put the message back on the screen. We had some people call in
last time but didn\'t queue up for comment. If there\'s a member press
star 1. For those on your computers you have to dial in and follow the
instructions on the screen.

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

I\'d just like to say once more that I think that there\'s a lot to talk
about with authentication I\'m trying to map what the purpose is to fuel
adoption of these breakthroughs, then how can we move on anything else
when we haven\'t dealt with authentication. I can make that case. On the
other hand I think you can make the case with some persistence we can
make some recommendations and some pieces of that and continue to do
that. I guess I\'m asking for advice from the Coordinator and/or the
Secretary what would be helpful and how can you go about doing
recommendations without authentication.

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

I think we need to get there. I think what I\'m hearing from the group
is that folks still feel like they need more information in order to get
there but not an aversion to working.

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

Let me throw out what I think as next steps we have short‑term steps
turning our discussion into a set of revised documents that will clearly
be the first thing we discuss on November 13. I want to hold for a
second what else we\'re going to do on November 13.

We have that immediate short‑term recommendations. We have an
intermediate term of addressing authentication. We have a longer term,
that doesn\'t mean delaying, a longer-term approach which Paul and I
have talked about with the staff this week about trying to get a little
more focused game plan for this group, what we\'ll be doing over the
next year, however next long we\'re going to be in existence, trying to
map some of that out, addressing the broader items. We have a number of
questions by folks on the call and we do know we need to do that and
we\'ve been tied up trying to sort of reach this quick deadline with
December 12 AHIC meeting. But we recognize that we need to have a
broader agenda broader described agenda focus of what we\'ll do. We
recognize that.

Now let me go back to November 13 for a second. Is there anything we
want to do on November 13 in addition to evaluate the, evaluating a
revised recommendations document which, with the caveat that I want to
go back to something you said earlier, something Alison said earlier.
Most of the recommendations that I think we end up making today I think
are largely editing rather than a new thing that we\'re going to throw
out for what we anticipate to be a lot of discussion. We may have
discussion, but I think a lot of it is turning our discussion to turning
our consensus into words that match that. Alison, you raised another
issue that you thought we needed to address next week, what was that.

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

Well, we\'re flushing out this document. We said that there\'s going to
be in person, sort of gold standard or what we would encourage and there
will be these other mechanisms when that is potentially not an option.
And we haven\'t done much to describe what those other things are. And I
think we need to have that ‑‑ I mean I anticipate that that could be a
fairly lengthy conversation.

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

Absolutely. Do we want to plan to do that on the 13th and integrate that
into a set of recommendations that will need to be finished probably two
weeks after that or is that part of the next \--

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

I think we can try.

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

I think we need to get to these recommendations as quickly as possible,
because there\'s a lot of things that we need to do there in addition to
identity proofing. Not that this isn\'t very important, but there\'s a
lot of things that we need to do.

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

We had said that staff would go back and come up with options or some
ideas for what are the ways to do identity proofing and some other
options. So I do think we\'ll need a big chink of time to talk about
that.

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

I think prioritizing that would be a good thing to do as soon as
possible so there\'s time to ‑‑

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

Is that a, is that testimony? Is it research?

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

We have sent out some information about existing, I\'ve got some things
in here people don\'t have in their e‑mail, existing identity proofing
practices so we can look at things to come up with suggestions. We said
that to folks we\'ll make it available on the Website for those who are
listening in we don\'t currently have it on the Website. And so I think
we probably could do some research and come back based on existing
practices that we\'re aware of and pose some options and we\'ll see how
it goes. Let\'s play that out. I think we\'re talking about a revised
recommendation document, which as of now doesn\'t include
recommendations on the points Alison was raising. We\'re going to have
information presented on those points and we may on the 13th decide to
turn them into recommendations. But we may not, but the recommendations
document shouldn\'t be dependent on something being concluded on the
13th about those points. Is that fair or ‑‑

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

Well, we should try. But if we can\'t ‑‑ I don\'t want to come out of
the 13th and say oh my God we don\'t have anything because we haven\'t
been able to agree on this point. We need to have the recommendations
where we had consensus we should have that as ‑‑

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

I guess we should do that first.

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

I think we should try because I think it does sort of impact the
recommendations. So we can come up with recommendations it really does
give the meat behind the recommendations, I think it\'s kind of
important.

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

I think to the degree that we can put that in there it\'s going to make
the recommendations mean a lot more.

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

If we\'re unable to complete it we at least will have had a conversation
share where we are and process.

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

I like that point, too.

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

Because we feel like we\'re getting close, might be a way to message
that in a report to the AHIC that\'s less than (inaudible).

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

Right.

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

Okay. And then you know we can talk about whether or not we\'ll have
time, staff will talk with the co‑chair whether or not we have time also
on the 13th or if we want to start trying to get some thinking on where
we\'re going from here.

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

We have three hours?

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

I think we have three hours.

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

I will be very surprised if we can get through these recommendations and
that other topic and get to anything else.

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

We have the earlier document. We could sort of validate that and sort of
share it one more time, share it out again and ask for comment.

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

Sure.

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

Sort of the topics to consider.

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

We\'ll have a revised document, we\'ll have some feedback to share with
the group on ideas for in person and alternative in person identity
proving that we would ideally try to work toward recommendations on and
we\'ll also try to get out to folks at least some a list of the issues
based on what\'s been proposed through the other Workgroups to give
people something to chew up in terms of thinking about next steps if we
can get to talking about that unlikely, but great. If we do people is
will have had time to think about the issues and prioritize.

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

That sounds great.

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

What are our next steps on authentication, once we get through this
round next meeting how do we keep that ball rolling because we don\'t
have a lot of the information we need?

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

I think it\'s starting to gather research and maybe and testifiers.

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

I presume there is a lot, I presume that\'s something that\'s research.

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

\[inaudible\]

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

So that will be our next ‑‑

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

Contradictory.

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

Should we ask her to make ‑‑ was there anyone who did have public
comment?

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

Nobody called in.

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

Anything else we want to do today? Any other comments from anyone on the
phone? Okay, thank you very much everybody for participating today.
We\'ll talk to you again in a couple of weeks. Again, as always, if
people have thoughts after the meeting, please don\'t hesitate to send
them to Paul or to me or to any of the folks.

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

Thanks very much.