American Health Information Community

Confidentiality, Privacy, and Security Workgroup Meeting #5

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

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

Judy, we\'re live.

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

Great. Well, welcome everybody to the fifth 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, the FACA, which means they have been noted in
the *Federal Register*. All of the meetings are transcribed and sent
over the Internet. So when you do speak, please identify yourselves and
speak clearly and distinctly for those who are transcribing the meeting
for us.

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

Yeah.

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

Also at the end of the meeting there will be an opportunity for the
public to make comments. Let me just say in the room today with us we
have a number of the members present and then Chris, maybe you could
introduce who is on the telephone. We have Deven McGraw here from the
National Partnership of Women and Families. Alison Rein. Jodi Daniel is
here. The two co‑chairs, Kirk Nahra and Paul Feldman, and Paul Uhrig
here in the room with us. So, Chris, could you introduce who is on the
telephone.

> **[\>\>]{.underline}**
>
> Certainly. And I\'ll apologize in advance if I mispronounce anybody\'s
> name. First we have Dr. Peter Basch. And we have Cynthia Clemens. Is
> that correct? Yes. And Steve Davis. Jill Dennis. Flora Hamilton. John
> Houston, Sam Jenkins, and Tom Wilder. And if I have missed anybody or
> if I\'ve butchered your name you can feel free to speak up.

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

Please let me remind everybody, when you\'re not speaking, to please
mute your phone so we don\'t get any of that background noise. And the
last thing I have to say is we do include two meeting summaries from the
two past groups if you would care to take a look and let us know if
there are any changes, additions or subtractions you would wish to make
those meeting summaries. I\'ll turn it over now to the Co‑chairs.

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

This is Paul Feldman. Welcome. Judy, I want to ask you a question about
how these minutes are produced and who does them.

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

We have a transcribing service, and they also make a summary of the
meeting.

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

And then you guys review it ‑‑

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

Correct.

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

‑‑ before a copy does ‑‑ okay.

> So we are being asked to accept the meeting summary for September 29
> and for October 6th. Does anyone have any comments or changes? Have
> people had an opportunity to read them.

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

I had. They look fine. This is Peter Basch. Thank you.

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

Have others had a chance to read them. I know others have not and we may
want to ‑‑

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

I think we are ‑‑

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

If people have any comments or questions about the meeting summaries,
why don\'t you shoot an e‑mail to Steve, and he can coordinate the
comments if there is anything there. I know they went out, I guess, late
Thursday so they were kind of lengthy.

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

So before we dig into the recommendations, just wanted to make a comment
that, as you know, we will need to be moving along with the next item on
a workplan. And so the co‑chairs and staff have had a couple of
conversations to get this going. And we decided that what would be
useful is to get comments, again I guess e‑mail Steve, with what you
think might be useful to take up next or, a sequence of things if you
wanted to kind of come up with a list. And something to describe why it
would make sense to take certain items out.

> We have, we had some immediate need obviously to address
> identify-proofing authentication as best we could in anticipation of
> this December 12 meeting. And even though ‑‑ I am thinking you might
> have something you wanted to add to that.

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

Sure. Basically all of the other groups had ‑‑ their last AHIC meetings
some priority settings for their future work. What we would like to do
is do the same thing and actually present that to the AHIC, letting them
know what issues we want to take on and in what order and sort of
setting our agenda for the next year. I know they are ‑‑ and the
Workgroup has asked for that and has some ideas of what our progress is
going to be in this Workgroup. And I think it will help us to try to
manage things better so that ‑‑ where more of, when will be presenting
to the AHIC, when we need to have recommendations by, and when people be
coming up for the ‑‑ start thinking about those.

> We do need to stick to our specific charge at this point. So if you
> come up with recommendations please look at the specific charge and we
> are, we were formed in response to recommendations to the AHIC that,
> from three of the other Workgroups. So we would like to try to focus
> on issues that were raised by the other Workgroups as needs for their
> specific charges. So please look at the list from that recommendation.
> And let us know what you think. You know, one option is to continue
> working on some of these similar issues and then ‑‑ initiation, which
> we have at least started talking about. Authorization is sort of a
> logical step in that process as well. So we can kind of continue
> working on that track. If folks think there is something more pressing
> and there is good reason to turn the table and work on something else,
> we would like to hear that as well.
>
> And what we will try to do then is work with the co‑chairs, try to
> come up with a detailed plan on when they could take issues on, timing
> for making recommendations and the like and talk that back through
> with folks and hopefully present a plan to the AHIC and get their
> feedback and make sure they are comfortable with our going forward
> approach.

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

So I guess, I have a couple of comments. The first is ‑‑ questions I
guess maybe. The first is the mission coming up with a year\'s worth of
stuff, just kind of ‑‑ I mean, I know that that was kind of intentioned
for the other Workgroups. But in as much as we are at this point
somewhat reactive to what they are taking on, I would be a little
hesitant to book us for a whole year\'s worth.

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

And that\'s fine, too. I think if there is some of those kind of
comments, feel free to share those as well.

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

Okay.

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

What we may do is come up with a six-month plan and then say, "This is
our plan. Here are the other issues we are planning to take on although
they are subject to change, some other priorities with the other
Workgroups." I mean, I think there is some flexibility here. What I\'m
trying to avoid is the reactive mode where we are on the agenda for a
few months on the AHIC and we are told that we are going to be put on
the agenda and we need recommendations. I would rather be proactive and
say this is how we would like to proceed and get approval for that
rather than being reactive ‑‑

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

Okay.

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

‑‑ and having that done to us. So I think it is an opportunity for us to
set our own agenda and get AHIC approval on it. So I think the more we
could do that the better. Doesn\'t have to be a year. It could be
shorter, it could be longer.

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

This is John Houston. Can I ask one question?

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

Sure.

**[\>\>\
]{.underline}**The Workgroup obviously has both privacy and
confidentiality as well as security in its title. And I know we have
done identity proofing and that, I know there\'s been some discussion
about authentication as being items of interest which both seemed to be
security-centric. Is there a priority on security related activities or
should we ‑‑ I guess I maybe leave it at that question.

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

Not necessarily. We are trying to bite off something we could chew and
something that\'s sort of at the first stage of the process. You know,
if folks feel there is a need to move to some privacy issues but you
know, there\'s ‑‑ saying we can\'t do that.

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

Well, the other piece, John, we talked about last week in our co‑chair
meeting was the idea of having this group focus on policy issues and
leave some of the technical specifications to others. And so I think
that may quickly turn us to some of the privacy issues. I mean, there
are, you know, the security issues that we have talked about so far,
using identity proofing as an example. We have been trying to come up
with some policy-level recommendations. I think we have done that so
far, but we don\'t want to get too down in the weeds on specific
technical specifications. So I think very quickly we are going to have
the privacy issues. And I guess to follow up on something that Paul
mentioned. It seems to me, we are looking at sort of three questions
that we would like people to think about and, again, communicate through
e‑mail your suggestions. One is what should we do next. Second is, you
know, a broader workplan. But third, even if you don\'t have an idea of
how they all fit together, I would like to hear topics you would like to
see us addressing. So there is a ‑‑ what are some of the issues that
each of you see that you would like to see us be addressing, even if you
don\'t have that in, oh, you know, there\'s the following seven and they
need to be in the following order. So we want to try to gather that
information, again, collected from individual responses. Then we\'ll be
able to pull together as we work here to try and build up that six-month
or whatever length of time workplan.

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

You know, also ‑‑ this is Jodi Daniel, John. One of the issues was that,
as we heard in one of our meetings, HITSP has sort of put off coming up
with standards regarding security issues because they were expecting
some policy guidelines from us. So that\'s also one of the things that,
one of the reasons we had picked the issues we picked to start with, was
to try to give them some policy guidelines, some of these issues, so
they can look at standards in this area.

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

I think of what we have done to date though is being ‑‑ as much
standards-driven as policy. I mean, I think the identity proofing is ‑‑
we are getting pretty close to standards there.

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

Again, I think that\'s a fair point. I think that\'s a fair point. And
again, the first set of topics was driven in a reactive mode. And, you
know, I think it is a little bit ‑‑ I don\'t know all of the history of
‑‑ I mean, I know that we were formed as a result of recommendations
with other Workgroups. But I think part of what we have struggled
with ‑‑ particularly is some of the issues that we can look at do touch
sort of everything that the other Workgroups are doing, whether they
have identified them as issues or not. So we are going to have to factor
that in, I think, as well. So we definitely know we need to move to some
of the privacy issues, and I think we will be doing that pretty quickly.
They were also ‑‑ in looking at a first issue that we could deal
quickly, most of the privacy policy issues did not seem to be
particularly easy.

> So I just ‑‑ we did not think that those were things that were going
> to be able to addressed, in a tight time frame in order to get
> recommendations for next month.

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

This is Alison Rein. Yes. If they were easy, they probably would have
been done by now. But I think that, it\'s not only the security
standards that has held up the HITSP folks. There is broader privacy
issues. So I think what would be helpful to me, and I think that
Dr. Halamka has already, or will be shortly, sort of enumerating some of
the hurdles that the technical committees have brought forward. So I
think it would be really good for this group to see what that list
includes as a first step in figuring out our future agenda. Because
certainly, there is a tight timeline surrounding those contracts as well
with HITSP and CCHIT.

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

Do you know what the timing is for that Alison?

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

Well, I presume that part of it was communicated to, in a written
format, to the Secretary and the AHIC ‑‑

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

Right.

**[\>\>\
]{.underline}**‑‑ in advance, or shortly after the last meeting. There
may be some additional, I think, documentation coming forward certainly
within the next month.

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

Thanks. Just as reference to remind everybody, if you do want to kind of
respond through the lens of the breakthroughs for the other Workgroups
and ours, all that stuff is in the initial packet that you received in
advance of the September 29 hearing, I guess, or even before that.

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

And this is Jill Dennis. When does Steve need those comments by?

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

The workplan?

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

Yes.

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

I mean, the sooner, the better. We are ‑‑ we right now are in a, you
know, a short‑term crunch to get this sort of recommendations that\'s
going to be the focus of our call today finished.

> So, you know, I don\'t think ‑‑ I think that\'s going to be the work
> this week for the most part. I don\'t know if people could shoot for
> the end of the week or early next week and we can start ‑‑ it doesn\'t
> have to be a hard and fast deadline, but the more information we have
> sooner, the easier it is to put some time and effort into trying to
> organize that and, again, not letting too much time go by before we
> have an organized plan.

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

Yes, I guess we are ‑‑ I mean, we are interested in what you think we
should be taking up and why. So it doesn\'t have to be anything fancy or
long. Just kind of lay it out in a quick e‑mail would be wonderful.

> Okey‑dokey. On to identity proofing recommendations. So let\'s see,
> how are we going to do this? Can we just go straight on through or ‑‑
> did you have recommendations about the ‑‑ I thought I heard you say
> something.

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

I think ‑‑ I think the challenging ‑‑ number 2 because it is the, it is
the one that we have not talked about in detail. It is the one that we,
the staff tried to work through.

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

Recommendation number 2.

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

Recommendation number 2.

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

Okay. And then there is also one recommendation at the end that we never
talked to last time but we wanted to ‑‑ I don\'t know if you want to
start with the other two and try to get through them quickly and get to
number 2 or ‑‑

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

That was going to be my suggestion. Why don\'t we literally start at the
top and go through. But let\'s punt on that Recommendation number 2 for
the time being and try to work through the rest of them. That make
sense?

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

Sure.

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

Let\'s do that. Okay.

> We are certainly happy to have comments on the introduction
> paragraphs. If people have wordsmithing, they can e‑mail those to us.
> If there are broader comments or concerns about the substance of any
> of that, is there anything ‑‑ any reactions people had to the ‑‑ I
> know we did get some written comments from a couple of folks. But
> anything people want to add in terms of the first couple of
> paragraphs?

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

This is Alison Rein. I had a question, we had it in some discussion at
the last meeting as to where would be an appropriate place to mention
the need for institutions doing risk assessment. And I didn\'t know ‑‑ I
know we have removed it as a recommendation but I thought that maybe at
the end of the second paragraph might be a good opportunity to revisit
this issue.

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

Yes, this is Tom Wilder. I would agree. I sent around some comments
Friday, and I apologize for the lateness of those. But one of my
suggestions was to discuss this risk assessment and also the concept
that, you know, your identity proofing needs to be scalable based on,
you know, your organization\'s risk assessment and consumer preferences.

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

So Tom, your sentence in your edit says, and you have it at the top of
that paragraph. Let me read it for everybody: \"Identity-proofing
processes must be scalable and based on consumer preferences and
organizational risk assessments.\" But it seems to me that what you just
said, that you would ‑‑ I would want to remove the word \"and\" and turn
it into "Identity-proofing processes must be scalable," comma, "based on
consumer preferences and organizational risk assessments."

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

Yes. No, that would be fine, or some variation thereof.

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

This is Kirk. This is ‑‑ the issue that I was concerned about last time
we discussed this was the idea that by ‑‑ if our recommendations give
people the ability to basically say I\'m going to choose a different
path based on my own circumstances, I was concerned that that would
effectively undercut recommendations that were designed in the, at least
the model of HIPAA and some of the other rules, of setting a floor, that
we were ‑‑ I was concerned that the recommendation, as the earlier one
was written, could have been read as not even guaranteeing a floor
because people could decide, based on their own situation, to go
underneath that floor.

> And I want to make sure that I understand the intent of your comments.
> I mean, again, when I hear things like scalable, my worry ‑‑ and I
> don\'t know if this is what you mean or not ‑‑ my worry is somebody
> could say, well, we are so huge that we cannot go through reasonable
> security steps and we are going to take a lesser approach.
>
> So I guess my view is we need to have ‑‑ we need to have a consensus
> on what our minimum is and certainly recognize that there may be
> situations where you want to do better than that. But again, I\'m
> leery of writing something that permits less than the minimum.

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

I agree. Could I just add on to that in one way? Part of the reason why
I think that\'s important, too, is even though you say there is some
variation based upon size of different entities that will participate,
if you look at the role of the NHIN you need a floor because everybody
is going to then participate. And so if you have, if you allow too much
variation, I think what you end up doing is having ‑‑ you don\'t have a
system that then, widely deployable or at least integrated.

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

Yes, this is Tom Wilder. If I could respond, first of all, I would point
out to everybody that both scalability and risk assessments are built
into the HIPAA privacy and the HIPAA security rules. There is this
expectation that, number one, you kind of ‑‑ you assess your own
organization. You access the needs of your patients or your other
customers, and then you build that into whatever security or privacy
protections that you have. And the second concept again is scalability,
that you have to kind\
of ‑‑ as we actually pointed out in the third paragraph, we say
recommendations may be suitable for a large operating environment such
as a hospital, but on the other hand it may not be, you know, it may not
be ‑‑ that recommendation may not be applicable to a small physician
practice.

> I\'m not trying to say you have got loopholes. I think what we have
> done is set out kind of a menu of options for people in our
> recommendations. And what we want to say to folks is, here is
> different approaches to achieve the same goal of security. We are not
> going to tell you which one of these to pick. You need to evaluate
> these through the lens of your organizational needs and the needs of
> your customers and kind of scalability about the size of your
> operations.

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

This is Peter Basch. I think I raised the objection, and I apologize for
the hoarse voice. I hope you can understand me. I raised the objection
at the last call. The concern at the last call about inserting what
might appear to be an obligation to do a risk assessment, and I\'m
thinking more of a kind of backwards scalability, recognizing that
probably 80 percent of ambulatory care is provided not by organizations,
and use the term "organizational risk assessment," but by physicians in
small practices. My concern was adding what appeared to be an obligation
to do a risk assessment might actually have a chilling effect on a
practice that we are trying to encourage all comers to feel comfortable
doing.

> So wanted to make sure that however we wordsmith this, and maybe using
> the term \"and/or\" would get around that, that we don\'t want to in
> effect disenfranchise unintentionally physicians in small practice who
> might look at this be too frightened to engage in secure messaging
> with their patients.

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

This is Jodi Daniel. I\'m going to jump in here with my two cents what I
think I\'m hearing. A couple of things. The goal here, I believe, is to
try to advance the discussion a bit and come up, as Kirk was suggesting,
some kind of a baseline that people are working from and that ‑‑ unless
I\'m hearing an objection to that baseline, there is some option built
into some of these recommendations, and maybe that allows some
scalability or flexibility. But the, you know, it seems to me that what
we have done as a group in coming up with these recommendations is done
some kind of, you know, baseline risk assessment of what, you know, we
feel comfortable with across the healthcare industry. Not that somebody
can\'t do more, not that somebody can\'t add to or supplement this, but
that we were trying to do some kind of baseline and that perhaps we
could say something about flexibility for those who act, you know, to
provide more security protections beyond what is here and talk about
this, these recommendations in the floor or baseline.

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

This is Alison Rein. I guess I don\'t perceive the options in number 2
as all being equivalent. And therefore, I have a heard time calling them
all a floor, which is why I wanted the notion of, you know, having this
risk assessment to evaluate where you land as an organization. So I
don\'t necessarily know whether we need to sort of spend a lot of time
wordsmithing what the notion or the added language might be now. Maybe
if ‑‑ I don\'t know if we want to sort of, you know, shoot some language
around over the course of the next couple of days or if we want to come
up with a resolution. But I don\'t think anybody is suggesting that we
don\'t want to have a floor. I just think the way these recommendations
are presented, they don\'t say it is a floor. They are not equivalent.
And we don\'t have sort of an add-on here that says you need to go
through some sort of evaluation process to figure out where you are on
this continuum.

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

Well let me throw out for the group a question that was specific in your
comment, Allison. I agree with the point you were describing, but I\'m
not sure we have a consensus on that, and this may be a difference
between the HIPAA privacy rule which very clearly spells out a floor and
the HIPAA security rule which arguably doesn\'t spell out a floor
because of some of those scalability issues. So I guess the question is,
are we trying to come up with a recommendation set that is in fact a
floor? And that if it is a floor, there is not really flexibility to go
below the floor. Or are we setting a baseline that people can go above
or below ‑‑ or below, depending on their own particular situation?

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

Kirk ‑‑

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

My view would be we should be setting a floor where people can clearly
go higher than that floor; but that, as I\'ve said earlier, I guess I\'m
uncomfortable with the idea that, you know, particularly in the, even
more so than in the normal HIPAA environment, in the EHR/PHR
environment, which is where we are focusing our attention, where we do
only have interconnections and the whole idea is to have
interconnections, I\'m uncomfortable with the idea that we might say,
oh, well, you know, doctors can just decide that they don\'t have to
worry about any of this stuff because they are a small office.

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

And that\'s not what I was suggesting by the way. What I was suggesting,
that by putting in language that suggests that an organizational risk
assessment is necessary to establish compliance with these
recommendations, you are essentially either, you know, creating full
employment for consultants or you are telling physicians in small
practices this is not something that they can partake in. Remember,
there is not a rule that says physicians have to increase communications
with patients or partake in secure messaging. We are trying to create an
environment where it is encouraged, it is adoptable, and it is used much
more frequently than it is today. That was the intent of my comment ‑‑

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

Peter, I just ‑‑ I get that comment. That makes perfect sense to me.

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

Okay.

**[\>\>\
]{.underline}**It seems to me to be ‑‑ I guess, let me just be clear.
And maybe, I mean, Tom, I don\'t know what your view on this is, and I
think you are ‑‑ I don\'t know if there are others, but you have been
the most articulate about this to this point, which is ‑‑ I mean what is
your view on that floor point? Are you viewing that scalability issue as
giving people the ability to go below that floor in their particular
situation?

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

No, and I can only restate what I said previously which is, what we are
trying to say is ‑‑ options for folks. You need to evaluate those
options based on scalability and based on risk assessment ‑‑

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

Okay.

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

So let me see if I have got a couple of ‑‑

**[\>\>\
]{.underline}**Let me finish here.

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

I\'m sorry.

**[\>\>\
]{.underline}**‑‑ which of these paths that you are going to go down. I
mean, I\'m okay taking it out. That sentence, quite frankly as I said,
that\'s a requirement of the HIPAA rules anyway. So if people are
uncomfortable laying out what\'s in the HIPAA rules, that\'s fine.

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

Well, this is Jill Dennis. Not all of the audiences we are addressing
here are, or will be, covered entities. If you think about a standalone
PHR for example, commercially available PHRs. So it\'s true HIPAA would
cover all of the covered entities, but this is a broader audience.

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

So let me see if I can try to summarize some points and maybe try to
wordsmith. I want to make sure there is consensus on the broad
principals. What I\'m hearing is that we are setting a floor, and that
‑‑ so are comfortable not allowing somebody to go below.

> The second point is that where there is flexibility in our
> recommendations, that need to look at their own practices, whether we
> call it risk assessment or not, I am hearing mixed messages on that.
>
> But if there is flexibility in our recommendations, supposed to look
> at, determine based on their own practices and consumer preferences,
> which are the options to pick.

**[\>\>\
]{.underline}**Well, just to follow up on Peter\'s point, it may be that
we should have a sort of standard recommendation so that, I mean, rather
than saying to a doctor\'s office, here are four choices. You have to
have some rational process for picking among the four that might require
you to have a risk assessment. Instead we might say ‑‑ and I think to
some extent we have talked about some of the face‑to‑face as ‑‑ just use
that as an example. That face‑to‑face may be the preferred mechanism.
And if you are going to do face‑to‑face, you are fine. If you want to
pick one or the other methods or the supplement, you are going to need
to make sure that fits your practice. Is that, Peter, consistent with
are where you ‑‑ you don\'t want people to have to feel that they have
to go out and do something specific to their particular office, involves
hiring a security consultant.

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

Oh, absolutely. Because I think what we want to do is encourage all
physicians, even in solo practice, this is something they can do. And
that there is a ‑‑ I\'m comfortable calling it a floor, or standard
implementation that they could safely follow. And I think larger
practices and hospitals and other organizations, no matter what we tell
them, will have their own risk assessments anyway and come up with some,
you know, customization of an approach. But thank you.

**[\>\>\
]{.underline}**Okay. I mean ‑‑ I\'m sorry, go ahead.

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

Was there another comment on the phone?

**[\>\> Jill Dennis:]{.underline}**\
This is Jill Dennis again. I do think there is some real advantages to
having it be a standard floor as opposed to, you know, a multiplicity of
options. From a lot of standpoints, but from one in particular would be
the consumer standpoint. And you envision the consumer who is dealing
with a wide variety of healthcare providers and having to go through
different exercises to be authenticated with different folks. I mean,
there is ‑‑ seems to be, just from a convenience standpoint, from the
consumer an advantage to having there be one basic floor that they can
rely on when interacting with a variety of providers.

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

Maybe ‑‑ that, you know, we are going to talk about five or six
different recommendations today. And as I\'m just eyeballing them. There
is really only one that has variations. I mean, we have got ‑‑ we have
got a statement ‑‑ I mean, in the general statement, just add to that,
we have got a general statement saying all healthcare exchange for
secure messaging or access to a EHR/PHR is sensitive. What I hear is no
one is saying that a particular provider could say, you know what? I\'m
a podiatrist and I\'m going to decide my information is not. So we are
not really giving a range there. We have a recommendation about
documents used to perform identity proofing to be kept separately.
Again, we are not really letting people say, well, my practice, it is
not important to keep them separate so that\'s okay. So it is really
that Recommendation number 2 of what we are talking about today where
there are ‑‑

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

Options.

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

‑‑ you know, variations on the theme. And we can debate, I mean maybe
this is Alison\'s point, that it is not clear which of those options is
the floor and which is higher than the floor. But again, that\'s really
the only one where that\'s a relevant issue today.

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

So maybe what we should do is come back ‑‑ I think we have got a couple
principals down we could work with and maybe we should come back to this
as we are talking about these options and see if in fact there is one
clear one that ‑‑ saying that should be the standard ‑‑ options. And if
you do a risk assessment we could do talk about that in that context. So
maybe we need to have a context for having this discussion.

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

And pull it out.

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

And pull out \[inaudible\]

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

Correct.

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

Why don\'t we talk about it in the context of recommendation 2 and we
will think about how we can best work it in at that point.

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

Yes, please.

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

This is Gary Debacco (ph), consultant to ONC. One thing if you go to the
floor approach, which I agree with, I think if you define that, it
implies you have sort of done a risk assessment by setting a floor. And
what might be helpful is, in the introductory stuff, we say that that
the information is sensitive. We might want to say the general risks
that we are trying to mitigate through these recommendations are
identity theft or whatever, so that people get an idea of what those
risks are. Because I think you all have sort of done a risk assessment
to get to this floor recommendation. And then if there are options that
might put a different spin on it, that\'s one of the additional risk
assessment, language might go either way. Just a thought.

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

I look back ‑‑

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

Any comments on that?

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

Sounds good to me.

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

Great.

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

So ‑‑

> **[\>\>]{.underline}**
>
> That was a discussion of the introductory language, I should say.
> Moving right along now, were there other people that had different
> thoughts on any of the introductory language?

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

Beyond this wordsmithing that we can play with offline.

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

All right. Let\'s move into the general statements. I assume General
Statement 1 should not be controversial since it is sort of a copy of
what we were given. Anyone disagree with that?

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

No.

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

All right. Number 2, all health data exchange for secure messaging are
accessed through an EHR/PHR is sensitive.

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

Can we remove one word from that? I think the word \"health\" before
\"data\" maybe needs to be removed. And the reason being is, you could
argue that there is also other types of information that might be passed
that is not health data, that might be equally sensitive or at least
cause consumers to be concerned about the use of public Internet and
whatever to communicate, if it is ‑‑ but if it is just health data.

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

That\'s probably a fair point. I mean again, I think in the HIPAA
context all data would be considered health data; but particularly since
we are not limited to that context, that\'s probably a fair ‑‑

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

So it would include financial or demographic data.

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

I mean if it is being exchanged ‑‑

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

Right.

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

‑‑ through those mechanisms.

> Anyone object to that?

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

I\'m still actually thinking about that, if we are actually raising the
bar too high with that. I\'m trying to make sure I agree with the
interpretation of all data exchange for secure messaging or with secure
‑‑ what was the exact wordsmithing of this? Just removing health?

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

Just removing health.

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

What if we say all personal data or all, just identifiable data or
something?

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

That\'s fine. I think ‑‑ here is the concern, I guess. I mean, obviously
what we are ‑‑ you know, let\'s use ‑‑ your EHR or your PHR might have
your Social Security number in it. Might. I recognize why there are
reasons it wouldn\'t, and there might have other identifying information
about where you live, bank account, that kind of stuff.

> In the context of the HIPAA regulation, I would certainly argue that
> if that is ‑‑ if a doctor has that information about you, it is
> considered PHI even though it really doesn\'t say anything about your
> health, it is still considered PHI. So I wouldn\'t want there to be
> any misinterpretation of this recommendation to say the only thing we
> are concerned about is, you know, your blood test. We are not
> concerned about this other kind of information that might be in your
> EHI or PHI.

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

Is there any advantage to using protected health information rather than
health data?

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

Well, I think ‑‑ one concern there would be that that\'s a term that\'s
meaningful only within the confines of HIPAA.

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

That\'s true.

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

So ‑‑

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

But it is a term that\'s widely understood by the audience.

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

Ah ‑‑

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

No.

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

‑‑ I\'m not sure that\'s right, only because people that don\'t ‑‑
people that don\'t have to follow ‑‑ well, two things. One is people
don\'t have to follow HIPAA rules might not view your Social Security
number as protected health information. I was amazed ‑‑ I mean this goes
back a couple of years ago, but there were a lot of discussions on
listservs and other things when the HIPAA rules went into effect about
whether patient\'s name and contact information was PHI. And I, my view
was always that it was. And I don\'t know, I guess there was some
FAQs ‑‑

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

It was.

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

‑‑ but it was not crystal clear and there were people that knew what
they were doing that was not convinced ‑‑ again because it doesn\'t say
anything about your health.

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

Now, the one recommendation I had, because I heard somebody say that all
data might be too broad. I mean a doctor could dispense just generic
information about a particular condition to a patient or a Website or
something like that that is not necessarily related to them. So they
could say give information about diabetes that I could read up on, and
it may or may not be related ‑‑ they may not have diabetes. So perhaps
it is like personal data or ‑‑

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

But that information wouldn\'t be accessed through an EHR or PHR though.

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

Or you are not going to say we have secure messaging but we are going to
do something less for that one particular message.

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

Right.

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

It\'s sort of a, you know, it\'s a systemic ‑‑

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

Then they could do it via e‑mail ‑‑ presumably.

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

Yes.

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

But I\'m not sure there is any problem with saying all personally
identifiable data.

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

Let me just test this because I\'m starting ‑‑ I thought I understood
it. Now I\'m understanding less. What happens to this, what if the
objection to removing the word \"health\" and have it read simply \"all
data\" exchanged for rest of the sentence is sensitive, full stop. Is
there an objection?

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

Well, I mean, there is a potential objection. It almost sounds too
broad. That\'s why I was hesitating on that.

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

Let me make the case that it should be all data, because we ‑‑ there is
absolutely no way that we will be able to develop a system that is
robust enough to be able to differentiate. And I think the consumer has
every reason to expect that when they communicate with their physician
or communicate with a PHR, that it will be done in a way that is secure.
And so I think using the concept of sensitivity with regards to that
secure communication is reasonable.

> Okay. Well, absent any other objection, we will strike the word
> \"health.\"

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

Well, look, if we are ‑‑ that\'s fine, yeah. Let me just make one other
suggestion though because I\'m having trouble I guess also with the
syntax of the sentence now. All data exchange for secure messaging
should be all data exchanged via secure messaging.

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

I think that \"for\" is not the right word.

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

Okay. Got it.

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

Actually, I hate to wordsmith this also, but shouldn\'t we say rather
than for secure messaging, it should be all data exchanged through
messaging or accessed through EHR/PHR should be secure, or is sensitive
and should be ‑‑ we need to add the concept of securing it then. Because
‑‑

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

Yes, this is Tom Wilder. I would also suggest add the results should be
protected or should be maintained securely.

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

Exactly. Take out the word \"secure\" also and add it to the end as
something you would do to the message for the EHR/PHR.

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

That makes more sense.

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

The word \"secure messaging\" is the term that the Chronic Care
Workgroup was using.

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

That\'s a term of art.

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

So I mean, we need to keep it fair but that doesn\'t ‑‑

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

It is, but the implication is that communications, out of an EHR or PHR
are what we are protecting, and secure messaging is one of the vehicles.

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

Right.

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

Actually like that spin.

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

Well, I guess I am not ‑‑ I thought we were talking about two different,
obviously related, but two things. One was secure messaging. The second
is access through an EHR or PHR.

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

Yes. But my concern is this, is that by using ‑‑ by framing the
statement this way, in theory you could say that data, that health data
or data that is exchanged not using secure messaging is not sensitive.
Even though it is the same data that secure messaging is a vehicle. So
why don\'t we ‑‑ or we could reword this to say secure messaging or
other secure forms of access to EHRs and PHRs should be used when
exchanging data.

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

Right, because we don\'t want to imply that the use of secure messaging
is what makes something sensitive.

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

Exactly. Thank you. It is more articulate than what I said.

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

But you need a qualifying statement in advance of this one or
descriptive. How about all data ‑‑

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

Shall be considered sensitive and ‑‑

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

‑‑ shall be considered sensitive for purposes of secure messaging or EPR
or PHR ‑‑

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

Why don\'t we say all data should be considered sensitive in exchange
using secure messaging or other secure mechanisms ‑‑ I don\'t know. I\'m
thinking ‑‑

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

How about we say, all data should be considered sensitive contemplated
to be used in any of the three breakthroughs described herein. I mean,
that\'s the ‑‑ but it is only that we are only talking about these
breakthroughs and we are not trying to say that outside the
breakthroughs is not sensitive. Right?

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

Right.

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

Okay. Can we ‑‑ you got it?

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

I am getting ‑‑ okay. Maybe we should ‑‑ I\'m going to try (inaudible)
‑‑

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

The idea is that it is all sensitive, what we are talking about ‑‑

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

But ‑‑

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

‑‑ but want to make sure that we are telling them we are talking about
this and we are not trying to ‑‑ we are not making a statement about
what we are not talking about.

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

Right.

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

Right. Is there a known/unknown? Sorry.

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

I\'m sorry?

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

It\'s a known/unknown.

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

Okay. We have got it.

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

All right. Number 3. Any comments on the third general statement?

> I assume that silence on that is a positive and ‑‑ again, if people
> have something and they want to shoot us an e‑mail later, that\'s
> certainly fine but ‑‑

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

Looks good.

> **[\>\>]{.underline}**
>
> All right. So that is the end of the general statement. Let\'s ‑‑

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

I\'m sorry. This is Tom Wilder. I apologize. I got cut off. I had one
suggestion as a general statement was that we actually explain in here,
or maybe even in the introduction what identity proofing is. We use the
term and never really kind of tell people what we mean by "identity
proofing." And I had sent around some language, and I don\'t think it is
exactly the right definition but just as a suggestion is you might want
to take a look at that and see if we want to define the term.

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

We actually had given a definition of identity proofing when we had the
first hearing. We put it ‑‑ registered so what I would recommend is
maybe we could pull language from that. Best for a definition that we
had proposed publicly when we started this discussion.

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

And I assume ‑‑ I mean everyone is okay with adding that in? Tom, that
is a good suggestion. Any objections to adding that in? Okay. Thank you.

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

We will do that.

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

Any other comments on any of the general statements?

All right. Let\'s move on to the recommendations. Recommendation
number 1. Documents or the unique information therein used to perform
identity proofing on a healthcare consumer, if kept, should be stored in
a secure manner separate from the healthcare consumer\'s clinical data.

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

This is John Houston. I have just one comment about Recommendation
number 1, and it actually deals with also Recommendation FD 1, which I
think they are interrelated insofar as, I think whole concept of having
a distributed identity architecture needs to be contained all within one
recommendation. I think ‑‑ having that, that distributed identity in the
architecture really does also relate to this recommendation also. So I
think they need some way we need to try to fuse those two.

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

I\'ll give recommendation for doing that.

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

Excuse me?

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

Give a recommendation for doing that, or you want to make sure that
concept is captured?

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

I wanted to discuss the concept. I don\'t necessarily have a
recommendation wording-wise. When I went back and looked through FD 1
though, I said these two have to be dealt with together.

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

John, but I think the point may be for Recommendation number 1, that the
mission of keeping these documents secure and separate would be
something that should happen in any environment whether there is a
federated or distributed identity going, model going on or not. This
contemplates a sole practitioner or whomever being able to do their
identity proofing. So we might want to put it, something about this back
into FD 1. So I think number 1 stands on its own.

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

I would agree with that. I think this came out of the testimony given by
Pam Dixon at our first hearing where she was talking about, you know,
sort of health identity test and fraud issues and talking about the
importance of segregating clinical and other personal data. And she, you
know, made mention of a couple of examples of, you know, provider
offices or institutions that kept a photocopy of the patient\'s
driver\'s license, you know, in the exact same place they kept their
clinical records, and that not being a practice we would want to
encourage.

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

Any other comments on Recommendation number 1?

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

This is Steve Davis. I think we discussed on the previous call about, or
meeting, about the fact that there might be information that is used for
identity proofing that might also be used as a matter of course in the
clinical record, like date of birth or something like that. And I\'m
wondering if there needs to be some language to make it clear that we
don\'t want to force people to keep those items outside the health
record.

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

So I guess, I guess my response to that is you are right. Some of the
data points, date of birth is a great example. It is part of clinical
records. However, the document to establish the date of birth is not.

> Well, I think ‑‑ I\'m talking online. The point though is what we mean
> by the unique information therein.

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

Right.

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

Right. I thought that was why we put unique information, was this very
issue.

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

Let\'s play out what that means. So the date of birth that\'s on your
driver\'s license number is not unique to that driver\'s license. The
driver\'s license number would be.

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

Right.

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

Now what about, I mean Social Security number. Again, that\'s going to
be ‑‑ I don\'t know. We are not sure whether that\'s considered unique
information or not. Most people don\'t have their Social Security card
when they come in. So I mean, Steve I think the goal of this sentence
was to address exactly your point. The question is whether we have done
it right.

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

I guess the question is, is the term "unique information" clear, make
that point.

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

I mean, you mean to take any information ‑‑ I mean, again, the idea and
this is not the right word, but the idea would be information that
exists because of those documents.

> So the information therein unique to that document? I mean, is that ‑‑

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

Well, that\'s not the right wording but I mean ‑‑ well, let\'s play that
out a little bit. And let me step back.

> What is it that we are worried about? We are worried about taking a
> photocopy of the driver\'s license and putting, and copying ‑‑ having
> that in the clinical record.

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

And having a trail.

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

But it is a copy of that document. So it is not the document itself,
because they don\'t take your driver\'s license. It is a picture of ‑‑
is there anything on that unique, on that driver\'s license itself that
we are actually concerned about being in the record? That would be, that
would have to be ‑‑ well, that would be license number. Right? Is there
anything other than that? Your height, your weight, and your hair color,
and your eyes, and your eye color, and whether you have, whether you
need glasses.

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

I don\'t know, but if your address usually comes with your clinical ‑‑

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

Yes.

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

I mean we can\'t say to people you cannot put an address in the clinical
record.

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

On a driver\'s license does that ‑‑ what is unique for a, that\'s on a
driver\'s license that does, that is not part of the clinical record?
The driver\'s license number, the date that it expires. There may be a
control number of some sort on it. There may be an issuing office, all
kinds of things that another entity may use for purposes of helping to
establish identity, like the three, the magic three digit number on the
back of your credit card.

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

So I think we do need a better description.

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

Yes. I think we need to do a much better job of kind of parsing this
out. Because as I hear people talk, I mean, you think about the kinds of
things that may be in an EHR or a PHR that really can be used to
identify somebody. In a sense, what we are really saying is you have got
to maintain two totally different systems with two different types of
access points to segregate out that data. And to me that gets to be very
problematic and very unrealistic. And I agree with Pam. I understand the
concept of what we want to do, which is to kind of have an extra
sensitivity or extra level of protection to some kinds of data that may
be used by a hacker to get into somebody\'s system. But I am not being
very articulate hear. I\'m not quite sure the way to state it so we are
not creating more problems than we are solving.

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

This is Deven. I think maybe we might also ‑‑ and I hate to punt
anything on this list because we are trying to get recommendations for
December. But part of it goes to the question what we would recommend
for identity proofing. Because if it is possible for someone to
identity-proof with information they already have in the clinical
record, then we are not ready to sort of finally parse out what we are
concerned about that\'s sort of extra, that someone might look to in
order to identify, identity-proof someone. And I am thinking about a
secure message example from an earlier meeting where we talked about
how, where there was a long‑standing relationship between the patient
and the doctor. The identity proofing wouldn\'t require an enormous
amount of additional document. It is just, I know this person. I\'ve
been seeing this person for, you know, 15 years. We are going to
establish a secure message account for them, and I\'m going to start
regularly e‑mailing them about their diabetes treatment. So we have not
really gotten because we know that\'s a really hard issue about the
documentation.

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

Well, I think the way this is written now is, it is clearly limited to
information that\'s on the documents used to identity-proof. So I don\'t
think it would go as far as ‑‑ I mean it is, I think it is ‑‑

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

‑‑ user document in the clinical record to identity-proof.

> \[laughter\]

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

I would think that ‑‑ I would think that\'s okay. That would be the case
for long standing relationship if a new patient walks into the doctor\'s
office. The doctor might go through a more rigorous identity and so this
recommendation would apply to someone. Can I see your driver\'s license?
Can I see a birth certificate or whatever? And by the way I should not
cram all that stuff in your patient data record. You know, the DL number
and all that stuff that\'s unique to those documents. If I\'m going to
store them, and I think that\'s also key in a recommendation, if I\'m
going to hold on to them I\'m not going to put it in the patient health
records.

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

Could we just add some examples and say, you know, for example, a
patient\'s address is not, you know, would be permissible to include in
a patient record because the doctor to be able to communicate by mail.
But a driver\'s license number would be unique to that person and should
be excluded. And just sort of give some examples like that.

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

Could you say documents or information contained in those documents
that\'s not typically resident in a patient health record?

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

Well this is ‑‑

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

‑‑ circular but ‑‑

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

‑‑ or take out the word typically or information that\'s not contained
in a patient health record.

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

This is Paul. Doesn\'t it get to the judgment of the provider as to what
he or she wants to put in the record and if it is information he or she
would typically put in the clinical record they should be allowed to put
it in the record.

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

This is Jill. I\'m thinking out loud, but maybe one approach would be to
say documents used solely for the purpose of identity proofing should
be, if kept, should be stored in a secure manner separate from the
healthcare consumer\'s clinical data. That\'s kind of what we are
getting at, is the extraneous things that don\'t normally get used or in
a medical record to begin with but we use them just for the purpose of
figuring out who is who. It seems to me that\'s kind of the intent here.

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

I agree. I think that is the intent. I\'m a little uncomfortable with
talking about typical because people may be doing it today, everyday
just ‑‑ I mean, we are presuming that this recommendation is to some
extent designed. I mean for the reason Pam was testifying about that is
that people were routinely making copies of driver\'s license and
putting them in their records so ‑‑

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

It is a problem now.

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

So the current practice would be problematic so we wouldn\'t want to
cross-reference that typical issue. But again, it seems to me what we
need to focus on is ‑‑ I mean, you could read this as unique information
about the person. We don\'t mean that. We mean unique information from
those documents. Documents unique to the identity-proofing documents.

> I\'m not sure we have really come up with a good example other than a
> driver\'s license number right now. I suppose a passport number would
> be a, you know, similar number for that.

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

And Social Security number, if they are not using it for purposes of
payment.

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

But again that\'s ‑‑ but I\'m not sure what the ‑‑ I\'m not sure what
document you\'re going to give ‑‑

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

Security card.

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

But I mean, it is not on most other documents.

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

Maybe we need to, based on that point maybe we need to refer not to that
information therein but information for other documents, information
therein or other information used to identity-proof that is not used
solely for the purpose ‑‑ that is used solely for the purpose of
identity proofing should be kept separate.

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

I like the solely. I don\'t understand Jill\'s suggestion why that
doesn\'t get at what we are talking about it. If you need to go
somewhere other than information you already have in the clinical record
in order to identity-proof someone, that\'s information that you sought
solely for that purpose that shouldn\'t go in the clinical record.

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

People ‑‑

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

‑‑ suggestion.

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

People\'s reaction to that? Any objection to that approach?

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

I agree that that solves our recommendation for this particular issue,
but I have a feeling we are going to skate back into this issue in the
future because we are going to start talking about how people store the,
in their records.

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

I agree.

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

And the extent to which the way they store it now is sufficiently
disaggregated that we feel comfortable. So I\'m fine for that right now.
I\'m sort of flagging it as something we are going to likely be
revisiting. But it certainly goes beyond the scope of identity proofing
per se.

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

All right. So we will wordsmith this recommendation with that idea in
mind. And I guess circulate that for people to make sure we have got
that right.

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

Right.

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

I think we are on the same page as to what the goal of the changes would
be.

> Okay. Let\'s skip over number 2, go to number 3. Converting from a
> paper‑based practice to one that uses EHRs should not require a
> healthcare provider to identity-proof their patients. However when
> presenting data to patients from an EHR, such as via flash drive,
> Internet, or remote access, healthcare providers should follow the
> identity proofing recommendation FEMA noted in Recommendation number
> 2. So obviously the substance of that last sentence we need to come
> back to. But the concept is if a doctor\'s office is simply converting
> their own records they don\'t need to go through identity proofing
> because that\'s their own operational activity. However, when data
> starts being given out to patients, they need to do identity proofing.
>
> So that\'s the concept. If people have questions, comments, concerns
> about that recommendation, with that in mind?

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

No. My only comment is one hopes providers are currently assuring that
they are actually talking to their patient before they give them a copy
of their paper record as well.

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

All right. Going once\...

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

You didn\'t establish a price.

> **[\>\>]{.underline}**
>
> Sold! Same as you are getting paid for this. Same as ‑‑
>
> \[laughter\]

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

Obviously got a better deal.

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

I get my own ‑‑ all right. So no comments on number 3. Let\'s move on to
number 4. All who provide personal health information to patients via a
PHR should follow the identity proofing recommendations FEMA noted in
the Recommendation number 2. So again the idea is, it is outflow. It is
who is getting that information. And once you are sending information
out, you need to identity-proof.

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

It is part of substance of two, want to get to it, the use of third
parties. I mean, that conversation, better left to ‑‑

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

As a means of identity proofing?

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

Yes.

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

Yes, these ‑‑

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

‑‑ provide but the implication is you can rely on the third party, and
we can talk about that when we get to the ‑‑

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

Correct.

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

Yes.

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

Okay.

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

There was one recommendation that came in that all whose should be
changed to entities that, the wordsmithing thing.

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

Yes, that\'s ‑‑

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

All right. Any comments on the substance?

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

This is John Houston. Do we want to say limited to via PHR? Or do we
want to be more broad because our last discussion about, you know, from
the general statements where we talked about secure messaging and access
through an EHR or PHR. It seems to me limiting to simply say that this
is, that there could be identity proofing for access via a PHR only.

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

Well, 3 and 4 sort of go together. Three is designed, I think, to deal
with the PHR side of it.

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

What about secure messaging?

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

Well, you wouldn\'t convert ‑‑ well, number 3 talks about converting.
You wouldn\'t be converting secure messaging presumably.

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

Are you suggesting that 4 ‑‑

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

No, I\'m just thinking, there is multiple ways to communicate with a
patient, provide information. I\'m assuming ‑‑

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

Would your idea be that we add the idea of secure message to number 4?

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

Yes, if we just want to make sure we identity proof any type of
communication that occur between ‑‑ any communication that occurs
between a patient and physician, that we have done appropriate identity
proofing so that we, there is some level of trust that, or comfort that
the patient is who they purport to be. Whether it is secure message or
whether it is providing information to a PHR that then the patient then
accesses, it is still delivering information to the patient. Correct?

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

Yes, I guess my sense is we do, we probably do need to put in secure
messaging just to be consistent with the earlier parts of the document.
We are talking about three methods of communication, secure messaging,
EPR, PHRs. We need ‑‑ we don\'t have to but we should say something
about all of them. And if your point is, if we don\'t say anything about
secure messaging that implies that you don\'t need to do identity
proofing for secure messaging, that\'s clearly not what our intent is.

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

That\'s what I was trying to point out. Yes.

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

That\'s fine. Why don\'t we add secure messaging to number 4.

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

That would be great.

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

Okay.

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

Any other comments or questions about number 4? All right.

> Moving on to number 5. Certification Commission for Healthcare
> Information Technology should ensure that criteria for the
> certification of health care systems support the identity-proofing
> practices suggested in these recommendations as well as underlying
> compliance with existing regulatory and statutory requirements.
>
> Questions or comments on that one? Sounds a little bit like motherhood
> and apple pie so ‑‑

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

Do we really need to have the part as well as underlying compliance? I
mean, isn\'t that just a foregone conclusion?

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

Yes, but no harm in saying it.

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

Okay.

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

I would argue it might be stronger without it. It is just, it is very
clear because this is ‑‑

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

Okay. That\'s fine.

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

I don\'t know if others have thoughts about that.

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

Well, we have two votes for deleting that. Any objections to that?

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

I would recommend deleting it also.

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

Any objections to deleting that?

> All right.

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

Recommendation.

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

End of recommendations. Okay. Yes.

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

Number 2.

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

Would it be ‑‑ support the identity ‑‑ (inaudible) would be better say
include identity ‑‑ (inaudible) practices, the criteria actually include
(inaudible) seems a little more strong.

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

We will think about that. I\'m not sure ‑‑ I mean, support is also a
good ‑‑

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

Good supportive word.

**[\>\>\
]{.underline}**Well, it is a more active word.

> All right. Any other comments on number 5? All right. Sold!

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

Do you want to do FD 1?

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

Let\'s do FD 1 for a few minutes, and then we will take a quick break
and turn to the meat of the program today. FD 1, which is Further
Discussion 1.

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

It was called FD.

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

I\'m guessing.

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

See, even ‑‑

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

You asked me to be a little more creative.

> \[laughter\]
>
> No we ‑‑

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

Order.

\[multiple speakers\]

> We wanted ‑‑ 1, 2, number 3 --
>
> \[laughter\]
>
> Given the healthcare community is comprised of many affiliated
> organizations and each may depend on identity proofing performed
> elsewhere, the establishment of a consistent identity trust model is
> necessary. The CPS Workgroup recommends that further work be performed
> on distributed identity architectures and trust establishment
> procedures.
>
> Questions, comments. You know, again, this is a little bit of a, we
> need to work on this further recommendation, or someone needs to work
> on it further, I suppose.

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

Yes, I think the concept was ‑‑ talk about federated models and we were
trying to capture that. But it seemed like there was not enough there
yet. That was how we tried to capture it.

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

This is a little bit of a placeholder frankly. Do people have concerns
with ‑‑ well, let me ask this question before we turn to that. And
maybe ‑‑ this is a question for you and Steve.

> Is there a value in turning this into Recommendation number 6? I mean,
> is that a meaningful thing to say? Is that useful, or is it more than
> we just have this be as a placeholder for when we are working on our
> workplan?

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

I think it should be a separate recommendation. This is, this gets down
into detailed work that needs to be done. I don\'t think this committee
should be doing it.

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

I guess then it would be, for anybody who has some more information
about, like, anything more about what would be recommended to have
happen, either the party to do it or the tasks involved.

> It occurs to me that the ‑‑ distributed identity management model. If
> we are going to use one in this domain, then should it be a certified
> entity that does it? Should there be standards? Yes, yes.
>
> So I don\'t know if there is somebody, if an organization or entity is
> teed up to do this or ‑‑

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

Well, I guess the way I read this recommendation right now is it is very
much an interim step. It is just saying, we know this is important and
it's got to be done. And I don\'t think we are there yet on what ‑‑ I
mean, and it may be ‑‑ this links back into number 2 as well. We may
talk about some of this in connection particularly with the third
parties.

> But it seems to me we should evaluate whether we want to keep this FD
> 1 on its own, recognizing it is an at best an intermediate step. It
> strikes me as a perfectly non-controversial intermediary step. I\'m
> not sure how much it advances the ball, but if people have anything to
> say, I don\'t have any objection to that.

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

Would it be an appropriate point to suggest either this group or others
tasked with working on this learn more about the government\'s
e‑authentication program?

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

Again I\'m not sure ‑‑ I think that\'s a great substantive idea. I\'m
not sure it goes into the recommendation.

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

Right. Right.

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

I don\'t want to turn this recommendation into our workplan.

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

Is there a particular group that ‑‑ would be best suited doing this. Is
there a who here, or do we not know that yet?

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

Well I\'m not ‑‑ it seems to me ‑‑ I mean, I don\'t ‑‑ I mean I\'ve some
of the materials. We have heard about what this means. We heard some
testimony about federated structures and things like that. I don\'t
really get that yet entirely. I don\'t have enough comfort level. I\'m
not even sure what we would be recommending ‑‑ it seems to me there is
some discussion that this group could have. I don\'t think this group is
going to decide, here are the three technology points that you need to
have in place in order to meet the idea of a federated standard, but I
do think it is worth this group looking at the idea of what would that
mean? What would it mean to have some kind of systemic approach where
Hospital A can rely on what Hospital B did. I think the implications of
that is very much in our bailiwick. How it is done may end up being
someone else\'s responsibility.

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

The policy implications of the trust model, I think, would certainly be
within our ‑‑

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

I agree. That\'s ‑‑ that\'s what I was saying. Understand what that
means and ‑‑ we are saying here it is necessary. I think that\'s
probably right ‑‑

> \[audio interruption\]
>
> ‑‑ I guess it is not entirely clear to me what people were saying. It
> may go to what Tom was saying earlier about scalability. Not within an
> office but systemic scalability. So again do we want to keep this idea
> at this point? I\'m sort of neutral. I don\'t think it says a whole
> lot, but I don\'t object to ‑‑

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

From the consumer protection point of view, what we are concerned about
is the weak link in a distributed transitive trust, however named. What
we don\'t want to have happen is for an individual to be able to obtain
a false credential by visiting, yield, credential giving doctor office
or whatever, and that be the weak link in a community.

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

It is essentially what has happened with choice point for the last
couple of years that they have been trying to address, if anyone saw
that article in the *New York Times* on Sunday. I mean that is, you
know, that\'s been the problem for that. Every part of it. So I think
that we wanted ‑‑

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

I think it is worth addressing. I just ‑‑ I felt flipped. I initially
thought it is good to put this as placeholder and let people know we are
going to consider it, but we have so many issues that are left to
consider, why name this one above a laundry list of other things that we
want to get done and we don\'t have anything substantive really to say
about this yet ‑‑

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

Right.

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

‑‑ off for now.

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

I guess I\'m, I am inclined to agree with that, that ‑‑

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

We have a lot of ‑‑ you know, if we are going to put a list of issues
that we have acknowledged are out there and we need to take up, it
better be longer than this.

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

Yes.

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

It is just one.

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

So this is part of, this is part of our workplan that we will, I assume,
be submitting separately.

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

We may be revisiting this after we take our break with respect to
Recommendation 2 ‑‑

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

Sure.

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

‑‑ specifically.

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

Are there any objections for the time being moving forward with this FD
1 not as part of our recommendations document?

> Okay. It is now ‑‑

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

2:20.

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

‑‑ 2:20. Why don\'t we take 10 minutes and reconvene at 2:30 to refocus
on R2.

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

D2.

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

FD1 ‑‑

\[break\]

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

Okay, we are here. Is everybody here? If you\'re not here, say
something.

> We are now going to turn to Recommendation number 2. This is obviously
> a sort of new recommendation that we on our last call had indicated we
> were going to spend most of our time today discussing. So just read
> off the basic provisions. Providers and other entities that offer
> healthcare consumers access to data and services through secure
> messaging, PHRs, or EHRs should perform or rely upon consumer and/or
> authorized proxy identity proofing that meets or exceeds one of the
> requirements stated below.
>
> Is it worth having a discussion about that recommendation up to that
> point?

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

This is John Houston. Can I ask one simple question here? I don\'t know
the answer to this, but is there anything other than secure messaging,
PHRs, or EHRs, that might be used to communicate with a patient? I was
thinking about this over the break, but are we being limiting by calling
it only those three if there are others?

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

I mean, I think ‑‑ this is Jodi Daniel. The only reason we are calling
out those three is because those are the charges of the three Workgroups
that have asked us to look at the issue with respect to their
activities. So we were trying to focus our inception on the other
Workgroup areas, and these are their charges. But I mean, that was our
thinking here.

> And we are trying to be able to do something that would help advance
> those, those breakthrough areas without necessarily trying to take on
> the entire world of identity proofing, electronic health information.
> So it is fairly broad. It was not intended to mean that other things
> are not included, but that\'s sort of the rationale for why we have
> that General Statement number 1, that we are looking at these in order
> to advance the specific charges.

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

This is Steve Davis. Would it be too broadening to say that offer
healthcare consumers electronic access to data and services,
particularly through secure messaging, PHRs, and EHRs?

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

Or such as through?

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

Yes.

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

You are making two additions. One is the such as and the other is the
electronic. And obviously our focus is on the electronic. I presume we
don\'t want to be viewed as saying you should not do this if you are
giving them paper access. But EHRs and PHRs and secure messaging I think
are, by definition, electronic, I suppose.

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

Maybe in the general statement section we just want to have a statement
of the obvious, which is that we are talking about electronic
transmission throughout the document?

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

Do we need ‑‑

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

And in which case you would just be able to remove the words \"from\",
\"through\" to EHRs. The ‑‑ access to data and services ‑‑ other
entities that offer healthcare consumers access to data and services
should perform or rely upon.

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

Aren\'t we back at this discussion that we had about whether we were
trying to craft rules for all e‑mails that went from providers to
patients that were not part of this, some sort of secure messaging
program and ‑‑ my understanding on a previous conversation was that we
didn\'t want to ‑‑ we were trying not to take on that universe because
it would be disruptive of ‑‑

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

We didn\'t want to impose new obligations on people to have just basic
e‑mail.

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

Right.

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

If they are doing it for now, for whatever reason, we didn\'t want to
get ‑‑

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

Right. I mean, what is secure messaging? Is it something beyond just
e‑mail, which is my understanding that we are talking about something
that\'s fairly specific and that we are trying to address these
recommendations to those specifics in order to advance the
breakthroughs. That\'s all. I mean, we can re‑visit that conversation,
but that\'s what I saw it.

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

No, I think that was clearly what our initial instructions were. And I
think where people where people think we are now. Let\'s play it out.
How does that translate to what this number 2 says?

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

It just got really broad.

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

Yes.

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

You were saying that by ‑‑

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

That sort of ‑‑ yes.

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

‑‑ if we take out the ‑‑ PHRs and EHRs, it then got into other
conversation about other e‑mail and electronic communication beyond
that.

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

Except that this is general statement that ‑‑ these recommendations are
talking about the three breakthroughs.

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

Right.

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

It\'s also ‑‑

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

That\'s what I was trying to ‑‑

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

Okay. Okay. Okay.

> I understood Alison\'s comment to be speaking to electronic
> transmissions which is ‑‑

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

Broader.

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

‑‑ a little broader than the way you put it.

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

It sounds like some useful clarifying language. So this is really about
these three breakthroughs. When it is about one ‑‑ when it is about one
or so, real specifically you will hear about it, other ‑‑ I mean ‑‑

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

The one comment I would make though about keeping it in the
recommendation is if these are pulled out of context ‑‑

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

‑‑ which they will.

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

‑‑ then they will be read as broader than you are intending them to be
read. So that\'s my only suggestion there.

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

Okay.

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

Then we need to craft it so we are clear what ‑‑

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

So right now it is just talking about secure messaging, PHRs, and EHRs.
I\'m hearing Deven say we are trying to do that because there were other
types of electronic ‑‑ services that we were not trying to include.

> I think there was a last point ‑‑ on this one.

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

That was the reaction to John\'s suggestion.

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

John\'s suggestion of broadening it.

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

I would be interested ‑‑ John?

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

I\'m sorry, what did you say?

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

I was reacting to your change and actually saying that I thought we had
deliberately decided that we were going to be limiting it, but I ‑‑ I
thought that maybe you were putting the whole issue back on the table.

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

Well, I just want to make ‑‑ I\'m reading this during the break again.
I\'m ‑‑ I was just wanting to make sure that I understood exactly what
the scope of this was and ‑‑ I mean, I can understand why it\'s been
limited, and I\'m fine with that. I just, I was trying to get some
clarification in my own mind.

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

Okay.

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

One of the reasons ‑‑ this is Jerry ‑‑ one of the reasons it was limited
so we could get to a common definition that the data ‑‑ are being
exchanged sensitive and we can focus on sort of one level of data
sensitivity and build recommendations around that or get very broad,
could be different types of data and different types of sensitivity
levels and therefore ‑‑

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

I think that may be so. I think it was more, per se, I think it was
simply we are trying to focus our work on these three breakthroughs.

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

Right.

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

So ‑‑

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

Okay.

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

You are right.

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

I think we are back at the same place as where the recommendation is.
Are there additional comments on the recommendation?

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

And again just ‑‑ recognizing that we have to get into the core of it ‑‑

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

Yes. I think we put everything we can in the general statement and leave
the specific re‑statement, secure messaging, EHR, and PHR, out of these
different, this recommendation.

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

What about the comment that people may take them out of context then,
even though it ends up getting repetitive? How does that ‑‑

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

I mean, I understand that.

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

My sense is it is not like it is a five-line paragraph or something.
It\'s a short phrase. I would leave it in to avoid any problems with the
context.

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

But see, but then you could look at your other recommendations and make
them more expansive also. At least look at number 1. And again, I don\'t
want to reopen number 1 up but it is not expressly stated in number 1
either.

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

Well, but it is ‑‑ the reason I don\'t think it is a problem with number
1 is that in many circumstances they are not going to do identity
proofing and, frankly, that is a recommendation. If someone was doing
identity proofing to send regular e‑mails, it would still be an equally
appropriate recommendation.

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

But we are not trying to expand out into the generalized recommendations
so I thought, so you got to be careful that you don\'t selectively
decide what recommendations are more general then. You can, we can put
qualifying language across the board to make it clear that, the scope of
it, I suppose.

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

Well again, I guess the other point which I think is important is
that ‑‑ I mean, let\'s talk about the out of context here. I mean, if
someone just read number 1 and didn\'t think about it as what, being
limited to anything in particular, I don\'t see any problems with that.
If you had number 2, and we took that out or people read it out of
context, they would say, wait a minute. Anytime anyone provides any
access to services they got to do this identity proofing standard, that
would be viewed as an impediment some existing practices and would
create some problems in and of it.

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

But see going back to number 1 though, you might have somebody who is
already doing identity proofing but storing information together in a
single database. Storing all that information in a single database. And
they look at this and say oh, my God, now I got to separate it.

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

Although we do, we do I think as a group, think that\'s a bad idea but
‑‑

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

But I\'m saying, but you are making one general recommendation. You are
saying that\'s okay. And then you are making another recommendation. You
decide, well, we want to make it more specific only to what we\'re, only
to the specific charge of the other Workgroups.

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

What if ‑‑ what I think I\'m hearing you say, John, and just to pose it
back to the group is, in Recommendation number 1, adding in a reference
to secure messaging, EHRs, and PHRs.

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

No, I\'m not ‑‑ saying the opposite, which is we\'ll just keep it in
general statement. Make it clear that the recommendations set forth
herein are specific to, you know, secure messaging, EHRs, and PHRs. Just
I\'m ‑‑ I mean, do what ‑‑ we shouldn\'t get caught up in this point. I
apologize for bringing this line of question up.

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

It is a fair point. I\'m more concerned about the out of context point
so I would not suggest only putting it in the general statement. If you
want to make them consistent individually and feel strongly we should
add the secure messaging PHR/EHR language to number 1, I\'m okay with
that.

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

Okay.

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

I don\'t think ‑‑ the idea of pulling it out of all the recommendations
because I\'m confident those will be misused that way.

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

Okay. And that\'s fine.

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

Okay. So we are going to add something into number 1. Okay.

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

‑‑ play devil\'s advocate. Look ‑‑ add that language in number 1 and
someone can say, if I\'m not doing those three, it is okay to define the
identify ‑‑ (inaudible).

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

Well, but again, that\'s the point I was making, but we are not ‑‑ and I
think we all agree that\'s a bad idea. But we are also not ‑‑ John\'s
point is a fair one, is we are not making a general statement that if
you have a, you have got nothing but paper records and you make a
photocopy, you have got to change that system. We are not making that
recommendation. Even though I suspect everyone on the call would agree
with that recommendation.

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

What if in the general statement, number 1, where we talk about the
specific charges we make clear that the group is not making any
statement with respect to other, with respect to identity proofing for
other than ‑‑ (inaudible) ‑‑ so that people don\'t think that we are
saying, okay, but if you are doing something else, you don\'t have to
follow these.

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

Well, no. I think we just have to ensure we are crystal clear that the
purpose of these recommendations is to address the specific, to aid in
the other Workgroups addressing their specific charge, which I believe
is what we are really talking about. Correct?

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

Right.

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

I think so.

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

Okay.

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

Then we will see you guys doing this when you restate what\'s going to
happen ‑‑ (inaudible)

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

Okay. So my understanding is that we are going to leave the secure
messaging, EHR, and PHR in number 2. We will add some language to number
1 to limit the breakthrough. And we will look back at the general
statements to make sure it is clear that the purpose and the discussions
that we had were only with respect to the specific charges. And so maybe
we can just tighten that up a little bit in the general statements, make
that a little bit more clear. Does that work?

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

Yes.

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

Thank you.

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

So now we have these four versions of identity proofing. And I think one
comment that\'s already come up and I certainly second that, is the
notion that as presented, there is know hierarchy here. They are simply
presented for alternatives. And I don\'t believe that was the group\'s
sense necessarily.

> I think we started from a place where in‑person identity proofing is
> the golden standard. And even though, in certain circumstances it is
> not feasible and therefore we got to, to talking about these other
> methods. So I\'m wondering whether we need to add something back that
> sort of describes how we got this, that there is a reason for these
> four methods. And they are perhaps listed and we should look at in
> what order they are listed in.

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

M\'hmm.

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

They are in declining order of, or ‑‑

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

Well, is the point that they are declining or that ‑‑ I mean, I sort of
thought of it as identity proofing should be in‑person, meeting this
standard of what we mean by in‑person, unless there is a viable
appropriate alternative, here are some other potential viable
alternatives.

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

Okay.

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

This is Jill. I thought of it that way too; but the thing that bothered
me in R1 was the word \"considered\" because it struck me as just too
weak. Where we say where a face‑to‑face relationship exists, in person
should be considered. I thought in the last call we got beyond
considering it and saying that that is what should be done, you know,
where it is, where there is that kind of relationship and, where it
doesn\'t exist, there are some alternatives. But maybe I misunderstood
where we arrived at our last call.

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

Well, I do think that your point ‑‑ you make a couple of points, but one
of them that should be considered is maybe what we say essentially
should be considered as the best approach or something like that. Again,
my view was, you should use face‑to‑face when you can. That\'s the best
way to do it.

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

Well, change the considered to utilized or used.

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

Yes.

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

And could we actually, the first part of that sentence, where a
face‑to‑face, in‑person relationship between the patient and clinician
exists. I mean, is that a necessary thing to say? Couldn\'t we just say
in‑person identity proofing ‑‑

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

I agree ‑‑ yes.

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

‑‑ would be used.

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

And then describe what in‑person means.

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

Because I almost think that R2 in ‑‑ form of in‑person. Because you are
talking about an existing relationship between a provider and a patient.

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

And R4 very likely could be in‑person.

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

Could arguably in‑person as well. It is just the third party in‑person.

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

Right.

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

Right.

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

R3 is really the one that is not in‑person.

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

In which case it is sort of out of order.

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

Fair enough.

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

Well, one of the other points ‑‑

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

In order.

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

‑‑ one of the other points, just to throw this out ‑‑ and I\'m not sure
what was intend in the drafting, I guess ‑‑ is when you look at the
beginning of number 2, we talk about providers and other entities that
offer healthcare consumers access to data and services. And I think that
some of those other entities are definitely not healthcare providers.

> So we talk about face‑to‑face, in‑person relationship between a
> patient and a clinician. I think ‑‑ I mean, I think there seemed to be
> a consensus that most of the time, whether it was for, you know, some
> of the concerns that Peter has articulated about sort of malpractice
> kinds of issues and AMA standards, some of the issues that Alison, I
> know you articulated, about making sure people understood. In the
> healthcare provider context most of the time this is going to start
> with an in‑person meeting with somebody. The patient has got to show
> up there to get medical advice.
>
> That\'s not true for lots of other kinds of people, particularly in
> the PHR context. So these were written, I think, primarily with
> providers in mind and we have got to think about those other
> components.

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

Why I wanted to strike that first part of the sentence.

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

Well, but I mean ‑‑ but let me touch on that a little bit. I know when
we were talking about secure messaging, for example, I think your view
at the time was you should, this should be in‑person.

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

M\'hmm.

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

Period. That would only be true in the patient‑clinician context. That
wouldn\'t be true in some of the EHR context. So that may be ‑‑
basically saying in the provider context, we really think you should do
face‑to‑face, in‑person. Period. That wouldn\'t be ‑‑ so you do need
that clause there, it seems to me.

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

I just think you need to reformat how these options are laid out ‑‑

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

M\'hmm.

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

‑‑ and start with sort of broad categories of when you are talking about
a provider, because I think ‑‑ I like the direction you are going in
because we have a whole different sort of vision for what we would
require where you have a provider, and either there\'s a relationship
present, in which case X, Y, and Z could be acceptable and could be
considered to be \"in‑person\" verses no relationship exists as of yet,
therefore, we might have a completely different set of recommendations.
Then down to the level of no, no ‑‑ you know, this is not a provider
where there would be an expected relationship such as, like a PHR
vendor.

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

Also we started out with that discussion though considering each one of
these separately. So we were trying to section off secure messaging,
which is why we got that place in the conversation. And then we were
going to talk about EHRs and then we were going to talk about PHRs. And
we all realized at some point in these meetings that was not necessarily
the most fruitful way to go about this. So if we are going to try and
squish them all together I don\'t like that first part of the sentence
being there because we are squishing them all together. If we are moving
toward an approach that doesn\'t suggest anywhere it is more context
specific, then I\'m fine with introducing more language. But in that
case this current set doesn\'t nearly reflect all the permutations we
would need to include in order to represent. I mean, does that ‑‑ so
that\'s a big picture question for the group of whether we want to try
and address this sort of consolidated set versus some more expansive
set.

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

Well we got here for, after a lot of conversation. So I think that
unless somebody has a strong case to re‑visit, I think we should
consider what we have here, which is intended to speak to all three use
cases. In which case, Alison, I agree with you, that the phrase is not
necessary, confusing or both.

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

But it would still be ‑‑ face‑to‑face, in‑person relationship exists and
just tracking between the ‑‑ submission or are you suggesting that in
all cases in‑person identity proofing should be used because then we
have the PHR issue that was ‑‑ (inaudible) where an entity would not
necessarily have an opportunity to do this in the first sentence.

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

I guess ‑‑ this is Paul. My own recommendation will be it is, should not
be requiring face‑to‑face in all cases. But where there is an in‑person
relationship it should be the difference between whether it is patient,
clinician or otherwise. And would be the same ‑‑ necessary (inaudible)
necessarily ‑‑ relationship.

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

But I think we have to clear what we mean by face‑to‑face relationship.
Is it a face‑to‑face relationship ‑‑ (inaudible) the PHR.

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

I agree.

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

Right.

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

Let\'s use an example. What do we think should happen at that point?

**[\>\>\
]{.underline}**What, if we ‑‑

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

Yes.

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

This doesn\'t matter until information is being pushed into it. We have
that covered. Right? Maybe that ‑‑

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

You know ‑‑ (inaudible) by PHRs. It is like a blank slate.

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

Yes.

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

It is a software program at that point essentially.

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

‑‑ providing a ‑‑ (inaudible).

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

Your prescription information ‑‑

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

Okay. But you cannot get to it until ‑‑ do we have something else that
already gets there? I know ‑‑

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

Well it\'s got to meet those criteria.

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

It is ‑‑

\[multiple speakers\]

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

The identity proof when you say, you know, I want my PHR.

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

Right.

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

That\'s true.

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

I think just for clarification, I would be interested to see if people
had interpreted that stepwise down. I think there is some kind of
hierarchy. This is Steve from ONC. So R1 basically gets ‑‑ and we can
wordsmith it how we want, but ‑‑ for most cases there is an in‑person
part. And as you go down the line through R2 and 3, you get further from
being in‑person. And that was the intent of the recommendation. So R1
is, there is an in‑person relationship. That we need to stress and
probably wordsmith. R2 is some affectation of the in‑person
relationship. R3 is the use of a third party. No in‑person relationship.
And R4 is using a third party to do any one of those three. So if we
need to articulate it better in maybe 1 or 2, that\'s where the
hierarchy or the kind of spectrum that we were trying to create. Does
that help?

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

It\'s helpful. Although I\'m getting stuck on the word \"relationship\".

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

And ‑‑

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

In‑person versus ‑‑ I guess I do get to get back to the clinician
relationship.

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

Maybe it is just where ‑‑ (inaudible)

\[multiple speakers\]

**[\>\>\
]{.underline}**‑‑ in‑person ‑‑

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

Right.

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

‑‑ as opposed to relationship.

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

Right.

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

The reason why a relationship is helpful because, I mean, then you sort
of have established that there is some validity in the person being who
they say they are as opposed to me showing up. I mean, presumably with
the right PHR example, in order to get access to my prescription meds to
be tied into this PHR issue.

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

Well, I almost wonder why the relationship goes the wrong way, which is,
I mean, at some point if I\'ve been going to the doctor for 20 years I
have a relationship face to face, and my guess is the doctor is not
going to ask for any of these things.

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

Right.

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

Okay. They are going to go to R2. So the one, the examples of the
application process and things like that are for situations where there
is really not been a long standing. It would be perfect for the right
PHR, you show up and you want to buy that.

> Well, again, I mean, let me go back to something Steve was saying a
> minute ago. Are we really looking at these all as variations on
> face‑to‑face? I mean, these are all going to be in‑person identity
> proofing?

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

The intent is not ‑‑ no. So the first level, and that\'s what people are
stressing, is we prefer in‑person, especially where there is going to be
some type of contact between the patient and the consumer and whatever
product or service they are getting or healthcare that they are getting.
Then the next part is that R2 scenario you kind of went through.

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

Although R2, there will have been a face‑to‑face ‑‑ right. ‑‑
in‑person ‑‑

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

It doesn\'t have to happen again per se. And R3 is, there\'s never been
a face‑to‑face. There\'s never been any contact before. And we are
trusting some other type of methodology to identity-proof the person.

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

For example, Friday, I go to variety.com, and I\'ve been selling
prescriptions there for a long time ‑‑

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

Right.

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

‑‑ and it says, click here to sign up for, you know, build your PHR. And
it will say enter some information about you. And perhaps they will say,
answer the next five questions. Street that you grew up on, what\'s your
mascot of your football team, the high school you went to ‑‑

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

What are the last three prescriptions that you take ‑‑

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

‑‑ those sorts of things. I have a pretty high confidence of jury ‑‑
(inaudible) ‑‑ I\'ve got an account set up, I\'ve got a PHR
pre‑populated and I\'m ready to go ‑‑

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

Right.

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

‑‑ and I could see Variety doing exactly just that.

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

How does Variety going to know what your mascot is?

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

Variety has got a contract out with Aggregator or Choice Point,
whatever ‑‑ bad example, but they will --

> \[laughter\]

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

You know, Choice Point is struggling ‑‑

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

But actually now they are better than the other one.

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

But they will ‑‑

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

They will figure it out. They\'ll ‑‑

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

‑‑ third party service provider that has those ‑‑

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

There was actually an article. I cannot remember, I circulated it to
some people ‑‑ but in \"USA Today\" last week that went through some of
those examples. And they had a couple of anecdotes about people ‑‑ I
cannot remember if it was banking ‑‑ I think it was, but it was in the
banking context. But it was people asking about, you know, first pets
and street they grew up on and situations where people had provided that
information to the bank. It was, they were able ‑‑ the bank was able to
find that information. And I had a debate going with a couple of my
privacy officer clients who thought that was a great approach because it
didn\'t require Social Security numbers. And I just think people are
going to be sort of, I mean, the phrase I used was weirded out, which is
not very technical. But how do you know all this stuff?

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

You\'ve ever gotten a credit report from annualcreditreport.com you will
go through that scenario and they will ask you a bunch of questions, and
then ‑‑ they think it is you and you can get it electronically,
otherwise you have to opt out paper and, you know ‑‑

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

Okay. So back to ‑‑ 1 to 4?

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

Just a quick question on the hierarchical comment. I would be careful on
trying to build a hierarchy around this, based on the way the
recommendation is currently worded because, if you read that opening
paragraph, it says, you know, identity proofing that meets or exceeds
one of the requirements noted below. So you know, if I read this, I
would say I could do any one of these and it is okay, that they are all
comparable. And I\'ll choose what best fits my environment, if I could
do an in‑person. Or if I\'m Variety and I want to do something that
leverages knowledge base stuff or, even though ‑‑ reader or whatever.
But if you want to go hierarchical, you have to change the wording a
little bit up front because right now it would lead me to believe that
they are sort of comparable.

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

Hierarchical could have two meanings. It could be better or it could be,
sort of a chronological more than ‑‑ I mean do we want people to use
face‑to‑face when they can? That\'s a question. I don\'t ‑‑

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

Well, and it depends. I mean, who is doing the face‑to‑face?

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

I have to ‑‑ I\'m going back to the example. I have to tell you that I
am not left incredibly confident by the notion that my prescription drug
history could be made available on the basis of an in‑person encounter
that lasts 45 seconds with a clerk at a chain drugstore who may or may
not have been the person that she or he says she or he is. I think it is
‑‑ and is it the same thing for me to obtain a credential in a
provider\'s office with the person who has been checking me in for the
last five years versus somebody who is from the temp agency who showed
up that day who\'s very purpose may have been to be there to provide
credentials to some people who arranged to have appointments, you know,
on that day. Who the hell knows?

> I think that it is ‑‑ the idea is that we are trying to increase the
> certainty that we are doing this right, and it is a ‑‑ I don\'t know
> what the answer is, but it is more complicated than in‑person between
> provider and patient is, per se the ‑‑ this is the clinician. If it\'s
> the clinician, it\'s one thing. If it\'s the front desk person, it is
> entirely another. If it is the front person you know is a different
> one than somebody you don\'t know. I don\'t know.

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

You don\'t even think R1 is a good idea?

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

I didn\'t say that.

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

Or is a standard that provides sufficient certainty.

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

Fair point. That\'s a different ‑‑

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

I mean, the question of certainty I think is one of the questions that
we are trying to get at between all four of these. And that gets to the
comment about comparable and I think Alison\'s concern that they are
not, or I think that\'s what you are expressing earlier. So the question
is, can we come up with a menu of options, you know, that are
comparable, closely comparable; or is it not the fact that, you know,
Paul\'s concerns about the clerk or someone at the desk being able to
identity-proof, you know, being the same as the doctor or someone at R2
or this knowledge base approach on R3. Are they comparable, is a good
question, and are we willing to make that policy decision that they are.

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

Just to add a sort of wrinkle from the other perspective, Paul and I
have been speaking in a number of others, but largely from a patient
perspective. But I attended a meeting last week where it was made clear
where a lot of large healthcare institutions were hell bent on not
sharing patient information with patients because they were not
confident that they had a means to do this. So, you know, on the one
hand you can say, well, we want to enable this new e‑frontier to move
forward so we should have, you know, a relaxed or not too high burden
for people to cross. On the flip side, we are never going to get free
exchange of information unless we make it sufficiently high that
institutions are willing to share their information.

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

Right.

**[\>\>\
]{.underline}**So, you know, I just want to inject that because I, I
mean, if we are talking about sort of harmonizing these four critical
points.

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

These institutions, they were concerned about what? About their ability
to do identity proofing or their sharing information based on what
someone else has done?

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

Both. But they were not going to be sharing their information
electronically with patients, period.

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

But that\'s because of their own concerns about ‑‑

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

Them not being able to identify and authenticate people into their
system.

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

I would assume ‑‑ to followup on your question, Paul, I would assume if
they have that view, they would, and they think we cannot do a good job,
they are not going to trust someone else to do a good job either. So
they are not going to share it with ‑‑ they may be reluctant to share it
with anyone.

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

Institution ‑‑ yes. I mean, that\'s ‑‑

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

They are actually sharing it with other institutions. Identity proofing
the individual is much more challenging than identity proofing an
institution.

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

True. Because you have it going on today, institution sharing ‑‑

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

Right. They are sharing data, just not ‑‑

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

They are turning out the analogy. I mean, if the patient shows up at the
other institution and wants access to data, your first institution
wouldn\'t share it with this one to give to the patient so ‑‑ they may
do it for treatment purposes because it doesn\'t matter who the patient
is. All they care about is who is the other provider.

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

Right. They do it because an institution is requesting the information,
not the individual.

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

Even though the reason they may be expressing that purpose is because
somebody has shown up at the hospital pretending to be that person.

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

Although ‑‑

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

‑‑ saying they are that person.

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

Exactly.

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

Well, I mean, let\'s go to Paul\'s point. I mean, are ‑‑ at what level
‑‑ are we going to say that face‑to‑face, in‑person, where you bring
these documents is not good enough if you show them to the clerk?

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

Can we parking lot the issue of these documents, please?

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

Yes. We have not talked about documents.

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

As ‑‑

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

Yes.\
\
\[multiple speakers\]

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

You could look at making an approach that hitches up with the Federal
Government, and that was ‑‑

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

I don\'t have ‑‑

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

‑‑ for a level of data that you want to protect, there is a minimum
level of identity proofing, authentication that needs to occur. And then
if you do anything above and beyond that, it is acceptable as well. So
at their highest levels they talk about very strong, in‑person proofing
and using Scripto and smart cards and all that stuff. But there are
government applications out there that are sort of meeting the assurance
that they talk about and strong passwords work and use of agency
relationships to verify identity work and stuff. You know, you can do
that.

> If you want to do in‑person because you feel more comfortable, go
> ahead and do that. Though I think addressing ‑‑ I think we are saying
> in‑person is not there. I guess the question is, what\'s the floor
> that they are acceptable for this health data that we are talking
> about.

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

But for example, this recommendation talks about patient, where
relationship ‑‑ and I know we are going to take this out but
conceptually talks about patient and clinician. And then it talks about
healthcare provider and entity, and it doesn\'t go to the idea of ‑‑ if
it is Marcus Welby and he doesn\'t even have a nurse, then it is the
doctor. But we know generally that the person checking you in is not the
clinician. It is somebody else. And it could be not only the office
manager who has been there 20 years. It could be the temp, and it is
going to be the temp or the new permanent person who was not there an
hour and a half ago. That\'s the reality. So what does that mean for
where we go with this? If you have the right documents, recognizing we
have got to figure out what those are, that\'s good enough, no matter
who you are showing them to?

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

I don\'t know how to put this into a recommendation, if there is an
issue of reasonableness. I mean it is not ‑‑ it doesn\'t appear
necessarily reasonable to me that, in a practice a provider would grant
the ability to identity-proof to somebody who just walked in that day
who the provider doesn\'t know.

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

So perhaps we can add to this in‑person identity proofing some sense of,
that it should be implemented in a reasonable way in order to, you know,
to assure either, you know, either the security of the information is
provided or ‑‑ which I think is your point.

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

Well, is your concern ‑‑ is your concern that the doctor grants to a
temporary clerk the ability to check my identity or that the clerk
wouldn\'t be able to verify the authenticity of the documents ‑‑

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

If I walk about ‑‑

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

You are worried about identity theft.

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

Yes. Okay. But let\'s play that out. So that means that I walk in with
your driver\'s license. Okay?

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

Okay.

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

And I walk in and I say to the person at the desk, I am Paul Feldman and
here is my driver\'s license. And are we going to set standards for how
smart the person on the other end of that has to be to be able to look
at me and say ‑‑

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

Yes.

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

‑‑ Paul Feldman is a lot more handsome than you are. This can\'t be you.

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

It is more a question of connection. You know, that this person really
connected with this entity. And I don\'t know ‑‑ that\'s the issue. And
especially where it's contemplated that the notion of establishing
identity at one place is going to be transitive and go someplace else. I
mean, the building blocks have to be solid.

> And it really is a question of reasonableness and not necessarily
> specific distance, specific fact which is ‑‑ like the document thing.
> It\'s like, I don\'t know about these specific documents. I know that
> we need strong identity proofing with known, we know who is doing it.

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

Well, I think perhaps we can add in something to address your concern
either in the general, we could talk about it from the ‑‑
recommendations, either in the general or with, only with respect to
in‑person if that\'s what we are really concerned about. Stating that
in‑person identity proofing should be used, and the entity should take
reasonable care to avoid identity theft or to assure that information is
‑‑

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

I mean, say you should be reasonable to avoid identity theft ‑‑

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

Well, I wouldn\'t ‑‑

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

‑‑ going with that is, are we going to tell doctors\' offices or are we
going to tell a busy hospital in some busy place that the person
checking the ID has to have, you have to be reasonable to make sure the
person checking the ID knows what they are doing.

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

You would hope the doctor or the entity ‑‑

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

Okay.

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

‑‑ because the result of going through all this stuff, it is set up in
online account of some sort, right, so the doctor can communicate with
the patient or, you know, PHR provider can provide access to the PHR.
And I cannot imagine ‑‑ you know, the doctor could be providing
treatment information through secure messaging. And I\'m the doctor. I
want to make sure I\'m talking with my patient and not ‑‑ you know.

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

But again, and I think that\'s one of the paradigm shifts which is, if I
walk in and say I\'m Paul Feldman and they take my blood pressure and
they take my cholesterol and they realize I have got a problem, they
want to communicate it with me. As long as they communicate it to me, it
doesn\'t matter if I\'m Paul Feldman or not. It matters I\'m the person
they saw. And it\'s the point that when this gets placed up through the
system, that that current practice of dealing with the person that you
treated becomes a problem. Because then my information, when I\'m not
Paul Feldman, is put into his records.

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

Right.

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

So that\'s the distinction here, and I am not sure how we deal with
that. I mean, that\'s a fair question.

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

I mean, again, I ‑‑

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

We could try to ‑‑ I mean, I don\'t think any doctor\'s office, no
matter how low on the scalability threshold they are, would say I know
that I\'ve got people checking these records who don\'t know what they
are doing, and I have not trained them and I have not told them what to
do. So putting in a reasonableness standard is, you know, I\'m not sure
that that does anything. So do we have to be specific. I don\'t know.

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

Go ahead.

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

I was going to say, if you want any of the physicians on the line to
weigh in?

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

I think Peter might have dropped off.

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

Did he?

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

I think what I\'m struggling with ‑‑ this is Deven ‑‑ a little bit is, I
guess I have less concern about people not being able to appropriately
check government-issued Federal ID. Where I keep running into trouble
is, what do we do ‑‑ with people who are not likely to have a
government-issued photo ID, and most specifically the large number of
undocumented persons who seek healthcare in this country.

> Are we going to ‑‑ you know, we have not laid out any standards, but I
> think it would be so easy for us to say you have to be in‑person and
> you have to show people photo, some sort of government-issue photo
> identification, which is a fairly reasonable backstop on the system.
> Then you have these ‑‑ but then of course, if we make that the
> standard, then we are essentially saying that folks who are
> undocumented are going to be completely left out of this whole system.

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

Well, but let\'s also play out what we mean by this whole system. It
doesn\'t mean they are not going to get treatment. It means they are not
going to get linked up to a ‑‑

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

They are not going to get what the benefits are potentially to creating
a national health information network. And in one place, and I have an
emergency, and another place that my records can get shipped over. And
I\'m struggling with this, and I\'m wondering whether there is a
conversation that we need to have with folks that work with undocumented
populations to get them to help us weigh the risks and benefits. Because
they will be equally as concerned about the identity theft issues as
they are about sort of leaving entire populations out. But we also come
to some sort of ‑‑

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

Somebody could use our three for ‑‑ somebody who is undocumented.

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

If these really are options, you don\'t necessarily need to go through
one. So let\'s assume one means you have to have a Federal,
federally-issued photo ID. We could say, for our three, that where
something, where you have a face‑to‑face relationship but, or whatever,
the face‑to‑face encounter, but the person does not have
government-issue ID, you have go to three. There\'s a way to deal with
that.

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

Although our three presumably is extended to information brokers and
things like that so ‑‑ so we will have that data ‑‑ yes, you can use our
2 in some of those context ‑‑

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

Right. Right.

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

‑‑ clinics that treat people on a regular basis. What I struggle with in
that context is, let\'s say there is a clinician here in D.C. who treats
a local undocumented person, but that person then shows up tomorrow in
Philadelphia. You know, how does that happen? What does the person in
Philadelphia do when there is this pre‑existing record? Because they
don\'t have, they don\'t have the pre‑existing relationship. So ‑‑

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

Right. I mean, I raised it also because I thought we were getting to the
place where we were ‑‑ not that R2, 3, and 4 were coming off the table,
but we were sort of getting to it. It seemed like we were gravitating to
a point of sort of in‑person with identification so that, you know, the
scenario that Kirk laid out where he comes in and presents as Paul and
he gets treated and his information ends up in Paul\'s medical records.
Electronic health records.

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

Any other comments from folks on the phone?

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

This is Steve Davis. It sounds to me like we are really talking about
two different, coming at this from two points of view. I mean, Paul\'s
issue about how do I know the person that I bring the information to
has, me being the consumer, is not misusing the data. It seems like we
set for the trusted third party option, we are setting maybe a higher
standard requiring that it\'s some sort of authorized or certified
organization to do that identity proofing. I\'m wondering whether we
wouldn\'t want to specify as our highest standard requiring that the
person doing the proofing have some certification or at least some
training. I mean, we require basic HIPAA privacy training for everyone
that is connected with health data. I\'m wondering if we don\'t want
some sort of standard like that for people taking our information.

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

I mean, we have got a balance that\'s sort of appropriate security
piece, with the idea of motivating and encouraging people to be using
these records.

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

And consumer protection.

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

Yeah. Well, I mean, again, it ‑‑ it\'s really that linkage part that
becomes the problem. And I mean, if I walk in ‑‑ I\'m starting to play
this out. If I walk into the office and I say I\'m Paul Feldman and the
person in the office doesn\'t know me and doesn\'t do a good job to
check me, I suppose the person at the front door could get, could link
me up to Paul\'s record even if the doctor then ‑‑ doctor is just going
to say, okay, this is Paul. And then so that would be how we could
connect it up to your data. Front desk person has done a bad job of
checking me in, and then the doctor just relies on that. That would be
the problem?

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

Well, the doctor, in a pure world, any other provider who follows these
credentials belong to Paul Feldman ‑‑ besides you.

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

I don\'t think we are going to avoid any hospital identity theft
impersonation of somebody. I think ‑‑ standards trying to work toward
will absolutely never get there. Because somebody will always be able to
fool somebody. We will be able to fake an ID or something like that. I
mean, there are always going to be ways that somebody can falsify a
document or present as somebody else. So ‑‑ and my sense from what folks
are saying is that we are trying to set at least a baseline for how this
is done, not necessarily setting the, you know, this is the ultimate
approach because that might not work in all settings.

> So given that we\'re not going to avoid all possibilities with
> somebody coming in and ‑‑ we are talking about the exceptions, the
> rare exceptions as opposed to the rules. I\'m wondering if we can look
> at this sort of from the ‑‑ work in the majority of, in the vast
> majority of cases. And can we, can we suggest that in order to avoid
> an identity theft or impersonation, that entities might want to have a
> higher standard to protect against those things.

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

Higher standard than what?

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

Than whatever we put down here to avoid identity theft or to avoid the
clerk doing this. The temporary clerk doing this ‑‑

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

Well, it is ‑‑ the clerk\'s feeling. The data issue, the clerk is not
doing a good checking job, which are different points.

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

Go ahead.

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

This is Steve. I was just going to ask, I think all the conversations
have been really valuable. It is a question, I think we have, as I look
at the time here, are these options ‑‑ and we try to reflect this in the
recommendations that we have made ‑‑ these are the ways that we heard
the Workgroup revolve around and articulate. So R1 kind of encompasses
the way of in‑person, whatever that may be. R2 is some type of
affectation. And R3 is that other that is basically, you know, common,
become as non-in‑person, however form that we are creating. And I guess
the question is, is there agreement on the ways in which we represented
these. And then we need to go further and say, how descriptive do we
really want to be with ‑‑ do we need to put in the type of document in
R1, do we need to do that? Or can we say, we have agreement that these
are the ways, we think these are closely comparable options that will
relatively get you to the same place in identity proofing, depending on
whatever option you take, and that we think is good enough for people to
choose from.

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

And perhaps we could, without coming up with specifics of these are the
documents, we can say, you know, entities that should consider issues
of, or different organizations looking at this consider issues about
undocumented folks or, you know, something like that that we can state
as principals that we are talking about without necessarily saying, you
know, it has to be a Federal ID or it shouldn\'t be a Federal ID or you
must have another way that ‑‑

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

I think from the discussion we have gotten to, the Workgroup would want
to say these are the ways that we have that we have agreed that we want,
that we think people should do identity proofing. And whether, you
know ‑‑ on the other end, on the back end how they do it is, still that
kind of un-prescribed issue.

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

They are basically taking a bunch of the words out and talking about,
there is, basically these four methods. I think ‑‑

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

And then we could, or not, depending ‑‑

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

An example.

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

‑‑ give factors or examples or issues to consider in doing those formats
as in the house. Here are the factors or things you should consider when
you are figuring out how to meet one of these four without getting,
without saying, X, Y, and Z.

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

Okay. One thing, before we lose this, as far as like 1, 2, 3, or 4 kind
of thing, the example of someone presenting in a provider\'s office who
is undocumented and the provider\'s typical method is to use these
government IDs, and that\'s not going to work for this individual. But
option three or four is available in the community, though not in that
provider\'s office. Do we want to recommend that providers make
alternative means available for individuals to have an alternative
method if the primary one they are using in their practice or hospital
is not accessible to the individual? I mean, that may be a way around
that particular issue. Or someone doesn\'t have, you know, they don\'t
have their documents today or they just got, you know, their wallet
stolen. I don\'t know. That happens.

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

That\'s a good point.

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

I know with ‑‑ this is Jerry. I know with some of the commercial
companies that do identity proofing for a living that there are signs on
the wall and stuff like that. They will have their standard process. You
go through it, check, check, check. You get a credential. They also
have, sort of the (inaudible) ‑‑ processes. You know, just because you
didn\'t address all of this we are not going to kick you off. We are
going to handle you offline. So in your example, a physician would go
ahead and treat. But prior to putting in information and creating an
EHR, the physician could go through some other sort of practices and
say, look, if you come to my office and show me a utility bill or
residence or whatever, then we will ‑‑ let\'s do that before we get it
into an EHR and stuff like that.

> So it might be prescribing, or recommending that entities, you know,
> they find an alternate set of processes that handle exception cases,
> and that\'s ‑‑ (inaudible).
>
> I think the key is to do that before it ends up going into the, into
> the NA environment eventually.

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

Just talk to the D.C. DMV.

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

So let me see if I can ‑‑ what? What I think I\'m hearing is those not
comfortable giving specific, I think in R1 we should cross out the
second sentence. Is there ‑‑ is there consensus on that?

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

Well, let me ask the question. I mean, is there concern giving any
examples, concern giving these examples and not others?

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

I don\'t want to link to an I9. That\'s a citizenship requirement on it.
So that\'s really ‑‑

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

It was not intended ‑‑

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

I well, I mean ‑‑ of course not. I know that.

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

And identity proofing requirements. They are identity proofing and
citizenship requirements that are only talked about the identity
proofing.

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

We just wanted to highlight within that there is a wealth of documents
that are used to do identity ‑‑

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

And I guess my concern ‑‑

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

That\'s right. But it is for work purposes in the U.S., which ‑‑

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

Which has a lot of value associated with it ‑‑ I do believe that\'s all.

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

Well you know, I understand you don\'t like that particular one. But I
mean, what ‑‑ if we say that these are examples, I mean, I guess I\'m a
little uncomfortable with not giving any examples because I\'m not ‑‑

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

I'm fine with examples, can we just not link them with I9?

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

You mean not list that as an example? Is that what you mean by ‑‑

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

Identity proofing requirements.

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

That\'s just, that\'s one of the of ‑‑

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

It is just one.

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

It is one of the examples ‑‑

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

Right.

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

‑‑ photo ID.

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

Okay.

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

You know, so ‑‑

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

So you have two or three but not one. Is that ‑‑

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

Yes. Yes. And speaking of the taking out of context, I think you are
buying a whole lot of ‑‑ we, you know, people will jump all over that.
It has a lot of, you know, concern among immigrant community, largely
related to work issues so ‑‑

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

That\'s fine.

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

Yes, this is Tom Wilder. I would agree. I think it is good to give
examples when you have got some there. I think this one document is
totally inappropriate. As someone mentioned for employment purposes, and
I think requiring people to give ‑‑ to have a patient come in and say we
are going to set up this great PHR for you but first you have got to
bring your passport ‑‑

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

Right. But there is insensitivities that you have been hearing ‑‑

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

That\'s fine.

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

And let me test this to see if this is true. It ‑‑ (inaudible) ‑‑ for
these three examples here, each of them requires more than one document.
Each of them requires one document to have a picture. I think that was,
that\'s what\'s in common.

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

Okay. Let me back ‑‑

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

I\'m not suggesting we even say that. But the notion is, it is more than
one document and there is a biometric involved.

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

Let me back up a little bit. I guess I had not really focused on that
distinction. I wonder how useful it is going to be for the average
doctor to look at that and say, well, I don\'t have any idea what the
DMV uses to set up a driver\'s license. Tell me I need a driver\'s
license. I mean, I wonder whether the process examples are not helpful.

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

And so ‑‑

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

I guess, I guess my sense is that the process examples are less helpful
than saying you need a passport or you need a driver\'s license or you
need something comparable.

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

So ‑‑

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

You are saying, you are suggesting instead of giving ‑‑

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

Particular documents.

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

‑‑ some of the ‑‑

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

Not even referring to another document. Referring to someone else\'s
process.

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

Right. So you are suggesting taking some of the documents that are on
those lists and using those as examples.

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

Yes. But that process doesn\'t go to Paul\'s point, which is these
processes all rely on multiple things. You can say that.

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

They rely on ‑‑

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

Right. But document, one of them has a picture ‑‑

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

Right. But if we are going to say, if we are going to say you can, you
need to have identity documents such as a driver\'s license, are we
saying you need to have more than one of those or a driver\'s license is
not sufficient? I mean, my assumption ‑‑ again I realize a driver\'s
license doesn\'t cover everybody, but that for the most part having a
driver\'s license is sufficient.

> If you have that, it is a perfectly reasonable way to identity-proof
> people.

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

Okay. So I think there are two questions on the table. One, do we want
to require more than one document as the baseline and have one of them
have a picture, or do we want to not be that prescriptive?

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

Or say we require one document as long as you have a picture.

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

Or one document as long as ‑‑

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

I don\'t know what I would use. No one carries a driver\'s license and a
passport around all the time. Very few people do that.

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

Because you would have both in one place and what happens if you get
that taken?

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

But you might have a driver\'s license, and they could also verify if
you of your ‑‑

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

Utility bill.

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

‑‑ card, or you have some other thing that has your name on it.

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

For what it is worth, when I\'ve seen a lot of, is one Federal-issued
photo ID or a state-issued, or a photo ID like a driver\'s license, plus
some other form of identification. An insurance card, credit card,
library card. I don\'t know but something basically, two things that
have your name on it and one has a picture on it.

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

The only thing I would caution people, the more roadblocks you put in
the way of people ‑‑ (inaudible) the more people are going to say why
bother.

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

‑‑ my picture on it, I\'m not sure what the ‑‑ or credit card adds to
that. And the reason my insurance card is not to identify me, it is to
identify where they can submit the bill.

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

This is the question I was asking about, in terms of how prescriptive
you want to be. I know you said it is important for us, as a Workgroup,
to make a determination on what type of documents should be used. Or do
we want to point people in the right direction and say do, this is the
methodology we think is best for your scenario. Please be responsible
and reasonable and choose ‑‑

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

Well, I don\'t think ‑‑ I guess it would seem to me that pointing them
‑‑ I don\'t think we want to be so prescriptive, we see these are the
only possible documents that can be useful.

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

We cannot do that.

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

I do think we want to give, if we are going to point them, I think we
should point them to something useful. I don\'t view pointing them to a
process that someone else uses as being useful.

> So we are going to say such as a passport, driver\'s license, other
> government ID with a picture. What do we want to use, or use ‑‑ or
> just make clear that those are examples and not ‑‑ you need something
> like that. Is that going to be okay with ‑‑

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

I think so. I think the point about the undocumented persons, they are
going to have to (inaudible) ‑‑

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

They are not going to have a document.

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

‑‑ the other things. To have a government-issued photo identification.

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

A passport from another country I suppose would ‑‑

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

Or we can say government-issued. It doesn\'t have to say U.S.
government-issued.

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

Oh, yes. The common ‑‑ for identity ‑‑ accepted passport.

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

Right.

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

So am I hearing at least an example being a federally- or
governmentally-issued photo identification ‑‑

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

Yes.

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

‑‑ would satisfy? That would be an example.

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

I think so.

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

I think we want to make clear the library card is not going to do it.

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

And this is Jill, I would also suggest that the photo issued ID probably
is sufficient, where you are standing there looking at that person and
can verify that the picture matches. But it doesn\'t do you any good in
a ‑‑

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

That\'s why I\'m talking about face‑to‑face anyways.

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

So if it is related to just R1, then I would agree with that. But if it
is related to where you don\'t have to face‑to‑face, that\'s probably
not enough.

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

So I guess what I\'m hearing that the recommendation is for R1, that we
would recommend the government-issued photo ID, provided in‑person.

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

Valid.

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

A current, valid, government-issued photo ID.

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

I never quite understood that part. I mean if my driver\'s license
expires tomorrow, does that mean I\'m not me?

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

Right. But if you have one that\'s 15 years old and you look nothing
like you did in that picture ‑‑

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

I\'ve seen people throw out of security lines at airports because their
license expired the week before.

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

This is ‑‑ (inaudible) denied any healthcare ‑‑

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

Country of origin to renew.

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

I\'m sorry, go ahead whoever is on the phone.

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

This is John Houston. Nobody is being denied healthcare based upon this
type of situation. We are just talking about granting them access to, or
communicating with them electronically. So I think we can hold to a
higher standard simply because of the fact that we are not getting in
the way of providing critical care to this patient, if that\'s ‑‑

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

That\'s makes sense.

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

I think the current, valid, government-issued ID, and then they would
give some examples of a driver\'s license, a passport, U.S. or foreign
passport and something else, whatever.

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

Right.

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

Now the other thing we have got references here to patient, clinician,
healthcare provider. I think we want to make those more broadly
applicable.

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

Yes.

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

Okay. I thought we were agreed to just try to use the dependent phrase
and begin with in‑person.

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

Right. But you still have at the end of that sentence healthcare
provider entity.

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

So basically what you are saying is, if someone doesn\'t have an ID,
which is ‑‑ government-issued photo ID, which a lot of people don\'t, a
lot of people don\'t have driver\'s license, they are totally written
out of the system?

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

No.

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

They are written out of R1. That\'s why we have R2.

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

Okay. I think we need to make that clear. Because again, I think, having
appropriate ‑‑ having good identity proofing is good. I think photo ID
is very helpful, but I want to caution everybody, the more roadblocks we
put in the way, you are going to have this whole underclass of people
that don\'t get access to these kind of tools just because we think they
need a certain level of identity proofing that they may not have access
to.

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

But do you think ‑‑ we are pretty clear in here that this is performed
by any one of the following. And they are or, and or and or.

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

And we talked about possibly adding some language saying an alternative
means should be made available if the primary means of identity proofing
is not accessible to an individual.

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

Yes.

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

So that makes it pretty clear that if somebody doesn\'t have a photo ID,
that the entity should have another method for identity proofing other
than the in‑person one, in that case.

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

Yes.

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

Should we talk about 3 and 4 make sure people are comfortable with
those?

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

I had a question ‑‑

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

That could be possible, is for the last discussion.

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

I have a question about 2. I\'m a little bit uncomfortable with \"or
some other means\"; e.g., fax signature. Is there anything we can
discuss here beyond fax signature that would qualify?

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

Even a fax signature doesn\'t do any good if you are not comparing it to
signatures known to come from the patient. You know what I mean?

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

Right.

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

It is just ‑‑

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

‑‑ meaningless unless you are doing some comparison.

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

I was concerned about that line item.

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

But the precursor of that statement is that we are the provider, or
entity, is willing to task to the patient identity on the basis of a
known, established, and durable relationship. So presumably they are
comparing it to something they know, either a known signature or known
voice or known something.

> Maybe we should make that more clear.

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

Well, you could add in the recommendation after relationship, and then
do the e.g. as, through in‑person. Leave the other means ‑‑ (inaudible)

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

I think that\'s good.

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

Okay.

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

3\.

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

Delete the ‑‑

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

I don\'t know if you want to delete it. You could delete the other
means.

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

So we are saying examples are in‑person, confidential ‑‑ (inaudible) ‑‑
recognition, (inaudible) ‑‑ including anybody else.

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

All right. Any other comments on R2 as revised that way?

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

Could you just give me an example of how that would happen? Is it like,
if a client goes to a provider, and that provider calls another provider
and says, I have this person in my office and he or she says ‑‑

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

No, it is more that I\'ve been going to you for 20 years and I\'m
calling to make an inquiry about something. You can identity-proof me
based on that phone call because you met me earlier and recognize my
voice. Or I show up in‑person and I don\'t have my driver\'s license,
but you have been treating me for a number of years and you know that\'s
who I am.

> The third ‑‑ the calling somebody else is going to be addressed later
> on.

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

It just sounds, the willing to attest sounds like the provider or entity
is, would ‑‑ there would be attesting to someone else that this person
is ‑‑ wouldn\'t it just be the provider or entity confirms the
patient\'s identity on the basis of ‑‑

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

That\'s fine.

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

The only reason we had willing to attest is, I mean, clearly they are
not getting some external proof of identity so it has to ‑‑ the provider
is taking on some, a little bit more risk here than actually a
documentation to back it up. So it is the provider is willing to do it
an as opposed to ‑‑

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

But it is the provider dealing with the patient, not some other
provider. That\'s the point.

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

Yes.

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

So we have got to figure out a way to bring that in. That\'s a fair
point.

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

Okay.

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

Known, established, and durable relationship.

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

But again, it is not ‑‑ it\'s my relationship with the provider I\'m
seeing. Not someone else\'s relationship. Not some other provider\'s
relationship with me.

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

I don\'t ‑‑

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

I can add (inaudible) ‑‑

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

I don\'t really care about that.

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

I got it. I had some language to make that clear.

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

This is Paul ‑‑ (inaudible). No problem there.

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

Okay.

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

All right. R3. Now, I ‑‑ one question, let me spell it out. I know
generally what R3 is getting at, but it is not clear to me how clear
that this is or how useful this is going to be for people who don\'t
have the benefit of our earlier discussions. I mean, what ‑‑ this has
some standard Norwalkee (ph) language, does it not, non, no touch ‑‑

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

I\'ve always heard it called knowledge base ‑‑

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

I think there\'s standard language that\'s actually pretty shared and
understandable ‑‑

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

I think you are right.

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

For example, this footnote that\'s written here, it says, this action
would prevent others who may have access to the same baseline identity
data from accessing that individual\'s health information. That\'s
because there is some information that only the individual alone would
know? I mean, I\'m not sure how that ‑‑ if we are talking about the
ChoicePoints of the world, we are going to get this from publicly
accessible data. There is nothing on that list that my brother or my
mother is not going to know. I mean, it would be a complete accident if
it happens to be some fact there. They are going to know the street
where I was born, they are going to know my first pet ‑‑

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

Are you talking about number 2?

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

Talking about the footnote in number 2 in R3.

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

Footnote goes to the number 2 part of R3.

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

What Kirk is saying is that, if I know my first pet\'s name, so will my
brother.

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

What information ‑‑

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

That gets the scenario that they may or may not know the last three
prescriptions that you were on.

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

How does someone read R3 and know what we are talking about?

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

I struggle to come up with very many examples that are going to fit part
2 of R3 and be information that A, the person asking the question is
going to know the answer to, and B, all these other people in addition
to me will also know the answer to.

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

So perhaps instead of the individual ‑‑ maybe that\'s not accurate
that ‑‑ is not readily available through, you know, standard
documentation such as the last three prescriptions the individual took,
the last date of service with the provider, something like that.

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

Well, are we going to write ‑‑ I mean, are we going to write those ‑‑
right. But it seems to me we are talking about two different things. Are
we talking about the ChoicePoint example and none of your, none of those
examples are going to fit ChoicePoint. The whole idea is ChoicePoint is
getting this information from publicly available data or some other
available data. Or is it something only the patient and doctor would
know?

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

The combination I think is what you are suggesting is some of the data
points they\'re requesting would be things you could find via
ChoicePoint. And then there is something about the specific relationship
between the individual and the organization that only that individual
would know.

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

So R3 is sort of a subset of R2. You have to already have an existing
relationship.

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

Which wouldn\'t work in PHR context.

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

It doesn\'t have to be the same person. It might be the ‑‑

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

No, not necessarily.

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

Well ‑‑ give me an example of something that fits this. Any example.

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

I think the last three ‑‑

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

That\'s right. I mean, yes, there does need to be ‑‑

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

Well, it is almost like a duration issue between the two. I mean, we
described number 2 as being a known, established, and durable
relationship, which can basically be done through in‑person or over the
telephone.

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

The three prescriptions is probably ‑‑ if I\'ve been to the pharmacy
three or four times, they are going to say I have a known, established,
and durable relationship. They are not going to say it has to be 20
years.

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

No, I know. I wouldn\'t want to put a time on it. But R2 is talking
about, I recognize you and I know you kind of identity. R3 is you have
been here before so there is a shared data point.

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

I ‑‑

\[multiple speakers\]

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

‑‑ what R3 is getting at is solely information about the relationship
between that individual and the entity that\'s doing the identity
proofing. I\'m okay if that\'s what we are saying. That writes out the
ChoicePoint example.

> But they should be combined. I think ‑‑

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

Or either/or.

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

Well, again, the baseline identity data is not stuff ‑‑ ChoicePoint
could get back, but lots of people can get back.

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

Remember, it\'s the health care entity that\'s going to have to contract
out to a TransUnion or Lexis/Nexis or somebody that offers the service
that allows you to ask these questions. And then these service providers
get other data aggregators to ‑‑

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

It sounds like there\'s two options here.

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

Okay.

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

R3, number 1, that\'s clear. The question is, what do we mean by 2? And
is it something known between the entity, the healthcare entity and the
individual that they have in common, like three prescriptions or last
date of service, or ‑‑ which bank institutions do all the time? Tell me
what your last check amount was that you wrote. Or are we talking about
your high school mascot and ‑‑ or could it be either of those?

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

Because if it is high school ‑‑ well, if it is ‑‑ I just want to be
clear, if it is high school mascot, then footnote 2 is wrong. Because
that will not prevent family members from figuring it out. Do they know,
everyone of my family members knows my high school mascot. Everyone if I
went to high school knows and knows other things about me. So we have
got to be clear what we are saying.

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

Right.

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

And I don\'t think ‑‑

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

Any decent ‑‑ any relationship, is there any decent information that
really only you know? I mean, every day you have ‑‑

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

I mean, guarantee, yes. But guarantee, there\'s clearly going to be
nothing in that category. My wife is just as likely to know what my last
three prescriptions are as anything else. But I think we have to go,
what are we trying to establish? If we\'re trying to establish that this
is the same person that\'s been to that pharmacy before, you can do that
through the last three prescriptions. If you are trying to confirm this
is someone who has other data points with that person, that may be fine
also. Doesn\'t help at all with family members. We have got to be clear.

I mean this is the one that I believe ‑‑ I understand conceptually what
we are getting at. I don\'t think we are there yet necessarily.

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

Maybe we should take the footnote out.

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

I\'m sorry?

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

We need to take the footnote out.

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

But does that matter though? I mean ‑‑ again, if you look at for example
HIPAA issues, an enormous number of true privacy problems ‑‑ not breach
issues, but not security breach kind of stuff, but true privacy problems
have been spouses and family members. Now maybe we don\'t ‑‑ that\'s the
exception and we are not going to deal with that.

> I think the point of footnote 2 is a useful point. I\'m not sure there
> is any way to do that. But we got to just figure out whether we are ‑‑
> adjust that or not.

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

I guess when I read this the first time, I was not, I didn\'t read it
carefully enough so that I had thought that it was all three layers that
we had discussed. So in addition to the ChoicePoint data, then there
would be another layer of questions that would ‑‑

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

Probably mascot, three prescriptions, and my name and address.

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

Exactly.

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

Okay. So what else is on the table as the recommendation ‑‑ (inaudible)
problem with that since this is not in‑person. There is no photo ID.
There is not necessarily a long-standing, durable relationship. If we
have ‑‑

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

Although, although we are assuming some relationship.

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

Some relationship.

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

M\'hmm.

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

Baseline data. So something, some shared data point like last three
prescriptions, last date of service, whatever it is. And something that
available through an aggregator, like mascot or place of birth or high
school or something like that.

> And that you need three data points. Are folks comfortable with that?
> Is that too onerous? Is that what we need?

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

That strikes me as probably pretty high likelihood of figuring out it is
the right person. Hard to do. And not that useful for that many people.
I mean, it is going to be ‑‑ go back to Peter\'s point about the risk
assessment. That\'s going to require a doctor\'s office to hire a data
aggregator to do some of this stuff. It is going to be require ‑‑ it is
only going to be useful in preexisting relationships. So it is not clear
to me what situation that\'s going to be useful for. It is going to be
situations where there is a relationship. It is not known, established.
It\'s a relationship but it is not sufficient to be known, established,
and durable.

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

But maybe the doctor scenario you gave, they were just not using R3.
They would use one or the other.

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

But what does R3 ‑‑ where is R3 going to be useful?

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

I guess I didn\'t read it as the assumption that it was a preexisting
relationship.

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

But that\'s what I\'m saying. Testing Jodi\'s three categories, one of
them is you have got to know something about that relationship, which
means there has to be a relationship.

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

But you are talking about the relationship between, like, maybe the
pharmacy or something, as opposed to the relationship with the PHR
company? Maybe there is ‑‑

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

A relationship with somebody that\'s ‑‑

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

Right. Exactly. May not be ‑‑

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

The person who is asking the question has to have the information about
that relationship.

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

No. You know, the other option, just to pose the second option on the
table, is you could have two data points, one be the baseline data and
the second one be either a shared data point or something that is
available through a data aggregator. High school or mascot. That\'s
something that would be easier to meet. See, that doesn\'t require an
established relationship. If you are coming in for a new PHR or ‑‑ and
it wouldn\'t require a doctor, a solo doctor\'s office to establish
relationship with a data aggregator if in fact they want to make a PHR
available to an undocumented individual.

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

I\'m wondering if there are any solo practice, or how many solo practice
providers there are, offering their own home‑grown PHR versus those vast
majority of these that are coming out which are generally done as
collaborations or broader institutions or they\'re independent PHR
companies and, in either of those latter cases, I feel like they should
be taking that extra step.

> But I don\'t ‑‑ I really wish Peter was still on the line because
> maybe he can speak from a perspective I\'m not aware that there is
> that many who are trying to offer this on their own.

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

Let me interject for a second. We have 10 minutes. We need to have time
for public comment. Are we going to finish R3? Are we going to get to
R4? Do we have ‑‑ I mean, we can ‑‑

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

We are not.

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

Well, we are not going ‑‑

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

We are not going to get through this in five minutes, clearly.

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

Could we get through R4 in five minutes?

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

We don\'t know.

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

No, because that leads to LD ‑‑

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

Okay.

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

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

No. R4 doesn\'t ‑‑

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

R4 lists all that stuff down at the bottom.

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

Okay. So ‑‑ (inaudible).

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

We\'re going to have to give ‑‑

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

Trust the third party should be defined.

> Well, why don\'t we do this. Let\'s ‑‑ shall we queue up public
> comments and then we can come back and figure out ‑‑

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

I don\'t know.

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

No, we have ‑‑

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

Yes, but we have to ask.

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

We have to ‑‑

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

Chris?

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

Yes.

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

Anybody in the public?

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

Yes. Absolutely. For the folks who are dialed in, if you would like to
ask a question, just press star 1 on your keypad. For those following
along on the Web, there is a slide that we just put up giving you
instructions on the number to dial in with. And again, once you are in,
press star 1 to get into the question queue. And I\'ll let you guys know
if guys want to keep chatting and plan forward, we will let you know as
soon as any questions pop up.

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

Thank you.

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

You can continue I guess.

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

Why what do we want to do, folks? We have got obvious questions about 3
and, I presume, questions about 4.

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

All right. So there are two options on the table for 3. And I\'m not
sure where folks stand on them or if we can come to resolution. And it
is just with respect to 2. Do we require three data points or two data
points? And if there is two, it is sort of an either/or.

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

And that\'s actually at a minimum two data points or three data points
because, conceivably, you could have multiple questions in regard to
each of those categories.

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

Right.

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

I guess I feel a little uncomfortable. I sort of know what my position
is, but I would like to hear some of the other folks and I\'m not
hearing a lot of folks on the phone so I\'m thinking maybe some people
had to drop off. So I ‑‑

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

We don\'t have, we don\'t have the connection ‑‑

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

Not to interrupt you guys.

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

Yes.

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

But we do have one question queued up from Elizabeth Holland. Jen, if
you want to open up her line.

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

Go ahead.

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

Hi.

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

Hello. Go ahead with your comment.

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

I was put in the wrong place so I\'ve been trying to say something for a
while, but that\'s okay. I just have a question about, are we looking to
see only from the provider perspective or are we looking ‑‑ because my
point of view is that most of the PHRs are going to be offered by the
health plan and they are not going to have the luxury of the in‑person
relationship. So to me R3 is addressing that. What we would need to have
a secure PHR set up by the health plan.

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

M\'hmm.

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

And Elizabeth, what\'s your sense of what would be required to do that?

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

Well, the health plan would have some amount of information on the
person if they are a subscriber to that health plan. But I don\'t know
if the question is what information they would have that only that
person would know. I don\'t know if there is any of that.

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

There is nothing.

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

There is nothing.

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

DUVs (ph) go to the account holder and that\'s ‑‑ so family members
know.

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

But I would bet that the vast majority of PHRs are offered through
health plans and not the providers.

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

I think that\'s ‑‑ I think that\'s a big assumption. That might be how
‑‑ that\'s not, certainly not what we are intending to build.

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

But ‑‑

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

‑‑ but build by somebody, perhaps other than the provider.

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

Right.

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

But I think you also have an issue of when you say who it is offered by.
I know some commercial PHRs. They are offering it, but they expect the
providers to do the authentication.

**[\>\>]{.underline}**

Right.

**[\>\>]{.underline}**

So, you know, I wouldn\'t link who was offered by to who is doing the
authentication. Then you have employers also.

**[\>\>]{.underline}**

Right.

**[\>\> Tom Wilder:]{.underline}**

Yes, this is Tom Wilder. I can actually speak to the health plan
perspective. The plan that I know offering PHRs, typically you will get
onto their Website. You will identify who you are with name and address,
and they will ask you for your health insurance ID number. And that\'s
what gets you plugged into the PHR.

**[\>\>]{.underline}**

But that\'s all you need?

**[\>\>]{.underline}**

Yes. Typically that\'s all you need.

**[\>\>]{.underline}**

But in those circumstances, I mean, assuming those don\'t have access
then to other providers.

**[\>\>]{.underline}**

Well, okay. Let\'s play that out a little bit, Tom. So I\'ve signed up
for that. What do I get?

**[\>\>]{.underline}**

You, you will get your personal health record, which is going to be who
your, typically who your doctors are, claim information. It might have
the results of your, some of your labs.

**[\>\>]{.underline}**

It would be information that the health plan has.

**[\>\>]{.underline}**

Yes. It is stuff that they billed off of Plains Data.

**[\>\>]{.underline}**

But not other ‑‑ it is not bringing in other data beyond what the ‑‑ it
is not going out to providers and loading it in.

**[\>\>]{.underline}**

No, they are not pulling in clinical data from a provider. The only
exception is they, in some cases they may have some lab results.

**[\>\>]{.underline}**

Or medication.

**[\>\>]{.underline}**

Right.

**[\>\>]{.underline}**

But only tied to the claim.

**[\>\>]{.underline}**

Right.

**[\>\>]{.underline}**

Right.

**[\>\>]{.underline}**

Only from the claim.

**[\>\>]{.underline}**

Right.

**[\>\>]{.underline}**

But that could lead to more information than any one provider would
have.

**[\>\>]{.underline}**

Right. That\'s true.

**[\>\>]{.underline}**

Okay. Well, we are pretty close to 4:00. I think that what we should do
is maybe Paul and I will regroup with the staff on what we want to do
about 3 and 4. Move that along. I think we are not at a consensus point
yet today. Figure out how to try and do that in time. I mean, it may be
that we, we have a shorter recommendation, but we got to figure that ‑‑
we got to figure that part out.

**[\>\>]{.underline}**

Can I just ask the question, in case we do try to come up with some kind
of truncated recommendation. If you think that a third party, forget
about all the language in the footnote, is something folks are willing
to report? Let\'s assume we took out the footnote. Just having a trusted
third party, something we need to define ‑‑

**[\>\>]{.underline}**

I think what\'s ‑‑ I think what probably is true for most people is that
support for development of distributed identity management system that
is, you know, somehow sort of, I don\'t know if certified storage, but
‑‑ I don\'t know what exists right now that would be available to use.
But if I\'m ‑‑

**[\>\>]{.underline}**

I\'m sorry. If I\'m understanding this correctly, we are going to have
to deal with the issue of trusted third party or some third party.
Because I would not support number 4. I mean, number 4 is unworkable
because I don\'t believe that every entity that would provide
information to a PHR would do their own identity proofing. They are
going to rely on someone else ‑‑

**[\>\>]{.underline}**

Right.

**[\>\>]{.underline}**

‑‑ you know. So we have to talk about the ‑‑ I think, the ability ‑‑

**[\>\>]{.underline}**

But it is also ‑‑ to some extent the trusted third party is circular.
Because if we cannot agree on ‑‑ we have to agree on the standards for
first party identity proofing before we can say we are going to trust
the third party, too, don\'t we?

> I mean, if we cannot agree what the doctor is going to do to
> authenticate, we cannot pass that on to the third party. We have got
> to ‑‑ the third party piece has got to come only after we have agreed
> on what the first party can do.

**[\>\>]{.underline}**

Or really what is needed for identity proofing.

**[\>\>]{.underline}**

Yeah.

**[\>\>]{.underline}**

I mean, for example, some of the things in the ‑‑ I know you talked
about now ‑‑ those didn\'t come up in other contexts so are those things
‑‑ you know ‑‑

**[\>\>]{.underline}**

‑‑ suggesting, just the concept of, that you could do this directly or
through a trusted third party that meets the conditions defined above
without understanding that we obviously would be ‑‑ discretion about
what that trusted third party is. I\'m trying to figure out if we are
advancing recommendations on some of these things, we want to be able to
say that there would be an option to do trusted third party to be
further fleshed out.

**[\>\>]{.underline}**

We are going to need, I mean ‑‑ I think we are going to need some third
party option. I don\'t think we are there yet, and what that is.

**[\>\>]{.underline}**

That\'s right.

**[\>\>]{.underline}**

But I\'m a little bit ‑‑ because this is a third party that did
everything above so ‑‑

**[\>\>]{.underline}**

Yes.

**[\>\>]{.underline}**

‑‑ I always thought everything we did was, one of the conditions defined
above.

**[\>\>]{.underline}**

One of the conditions.

**[\>\>]{.underline}**

Right. So I was not limiting our discussion to just providers because we
said the third party can do it.

**[\>\>]{.underline}**

We never assumed there was a difference between a first party and a
third party.

**[\>\>]{.underline}**

But R4 says the third party can do it.

**[\>\>]{.underline}**

We still got to agree on what the 1, 2, and 3 are.

**[\>\>]{.underline}**

And just about ‑‑ by the way, I was not making the same assumption you
were with Recommendation 4. I presume that a PHR was going to have, a
company was going to have some kind of business relationship with an XG
that does that.

> I\'m not sure that that is exactly what is contemplated here for R4,
> that this was the notion of developing an identity, develop a
> credential so that the individual can take it and use it explicitly to
> take it and use it somewhere else versus having this be part of the
> business practice of the PHR provider. Of course the PHR provider is
> not going to do it itself. It\'s going to use a company that
> specializes in doing that.

**[\>\>]{.underline}**

They are not ‑‑

**[\>\>]{.underline}**

In my head they are not exactly the same.

**[\>\>]{.underline}**

That makes sense.

**[\>\>]{.underline}**

I didn\'t ‑‑

**[\>\>]{.underline}**

Okay. I read this as all who provide personal authentication should
follow the identity.

**[\>\>]{.underline}**

And I don\'t believe it is reasonable to assume every provider who would
be putting information into a PHR would do their own individual identity
proofing. They will rely on a third party.

**[\>\>]{.underline}**

They will.

**[\>\>]{.underline}**

That\'s right.

**[\>\>]{.underline}**

Whoever that third party is. It\'s to my issue, there has to be
accountability by that third party because a lot of people are going to
rely on that process to reveal information.

**[\>\>]{.underline}**

I\'m comfortable in saying we are going to have to have a third party,
but the devil is in the details of what requirements they have to go
through, what sort of ‑‑ what rules they have to play by, et cetera. So
‑‑

**[\>\>]{.underline}**

Okay. We will try to work out what we are going to do on 3 and 4 and
send around some suggestions on that. We will wordsmith the rest of the
points as we have discussed in the meeting today.

> And we will keep you posted on our next step. Thank you very much,
> everybody, for your participation.

**[\>\>]{.underline}**

I guess that goes on the workplan.

**[\>\>]{.underline}**

Yes, if you have your thoughts on what should be next, what should be on
the workplan and any particular order, any of those topics, please let
us know. Thank you very much, everybody.

**[\>\>]{.underline}**

Thanks.