American Health Information Community
Confidentiality, Privacy & Security Workgroup #6
January 8, 2007
Disclaimer
The views expressed in written conference materials or publications and by speakers and moderators at HHS-sponsored conferences do not necessarily reflect the official policies of the HHS; nor does mention of trade names, commercial practices, or organizations imply endorsement by the U.S. Government.
>> MATT McCOY:
Go ahead, Judy.
>> JUDY SPARROW:
Okay, good afternoon everybody and welcome to the Confidentiality, Privacy, and Security Workgroup meeting, this is our first Workgroup meeting in 2007. And just let me remind you that these meetings are conducted publicly, they have been announced in the Federal Register, and there will be an opportunity at the end of the meeting for the public to make comments. This is being broadcast over the Web, so if you do make comments please state your name clearly and distinctly, for the purposes of the reporter.
If you're not talking it helps if you mute your telephone so there's not a lot of background noise. And we have a long meeting today, so I think without any further ado, I'll ask Matt to do the roll of the people on the phone, and then we'll go around the table here at the ONC offices.
>> MATT McCOY:
Certainly. We have Susan McAndrew from the Office of Civil Rights, Lorraine Doo is here for Tony Trenkle from CMS, Tom Wilder from America’s Health Insurance Plans, Jill Callahan Dennis from AHIMA, Steve Davis from the Oklahoma Department of Mental Health and Substance Abuse, John Houston from the University of Pittsburgh Medical Center. Is there anybody else on the phone?
>>: DEBRA PARIS:
Yes, there is.
>> MATT McCOY:
Please state your name.
>>: DEBRA PARIS:
Debra Paris, and I'm representing Family and Medical Counseling Service, Inc., on behalf of Doctor Flora Terrell Hamilton.
>> MATT McCOY:
Thank you, did I miss anybody else?
>> JUDY SPARROW:
Okay, and in the room we have David--
>> DAVID McDANIEL:
McDaniel, Department of Veterans Affairs, Veterans Health Administration.
>> PAUL FELDMAN:
Paul Feldman, Health Privacy Project.
>>KIRK NAHRA:
Kirk Nahra, Wiley Rein and Fielding.
>> JODI DANIEL:
Jodi Daniel, ONC.
>> ALISON REIN:
Alison Rein, National Consumers League.
>> PAUL UHRIG:
Paul Uhrig, SureScripts.
>> DEVEN McGRAW:
Deven McGraw, National Partnership for Women and Families.
>> JUDY SPARROW:
That's it.
>> KIRK NAHRA:
Good afternoon, everybody, welcome to a new year. Have a lot on the agenda for today, and we'll be spending some time today setting our program for the rest of this year. We're actually going to start, I think, with a off-agenda item, just to keep things interesting. And Jodi, do you want to introduce our guest?
>> JODI DANIEL:
Sure. We have been joined by Greg Downing, who is heading up the Personalized Healthcare Workgroup that just started this past week. He is with HHS and he's provided really support for that Workgroup. I spoke at the Personalized Healthcare Workgroup just to give them an overview of what the CPS Workgroup was doing, and I thought it would be a good opportunity for Greg to do the same about the Personalized Healthcare Workgroup, so the CPS Workgroup knows what their charge is. Greg?
>> GREGORY DOWNING:
Great. Thank you, Jodi, and the chairs. I'm here representing the Secretary's personalized healthcare initiative, which is one of his top priorities. And one subset of the personalized healthcare initiative’s activities is a Workgroup in AHIC that was established back at the December meeting, and that's chaired by John Glaser from Harvard Partners and Doug Henley, who is an AHIC member. And we've had our first meeting, and we have a 22 member working group.
I'd just like to touch, I know you have a very busy agenda today, but there are some close handoffs I think that will be going on over the course of the next year or so with this Workgroup and with ours, we anticipate, in working with the ONC staff. And I again want to acknowledge that the-- we're relatively new kids on the block with regard to AHIC, and have been working very closely with the ONC staff and Dr.Kolodner on optimizing the opportunities to make impacts from various working groups, and helping advance some of the capabilities that this initiative has overall for medicine and healthcare overall.
The key cornerstones, I won't go in any detail about Personalized Healthcare, but it's really focused on the interface of health IT and genomic information. And at the turn of this century the capabilities for genetic medicine really came alive with the completion of the human genome project. And there are many, many facets of healthcare that will be impacted by genetic tests in the future, and these are things like understanding the differences in how drugs work in people, and safety aspects, adverse events related to poor metabolism or rapid metabolism of various drugs.
It's very early on, but these capabilities, I think, are rapidly having an impact in oncology, cardiovascular health, and the testing capabilities for suitability of using various pharmaceuticals in the diagnostics industry are being impacted by this on a relatively large scale. And the Secretary saw the opportunity that the work in the health IT space could have a really important impact on the deployment of these technologies and capabilities through the integration of these test results with electronic health records
So we've established in this working group broad and specific goals that are really focused around the deployment of genomic test data and integration of them into the electronic health records or personalized health records. And to some extent this is already ongoing, but there have been many vendors and others that are concerned about this because of some aspects of genetic information that in the post-HIPAA environment raised particular concerns. And I think they are juxtaposed in somewhat to many of the issues that this Workgroup is dealing with.
Overall, there are many policy aspects related to genetic privacy, and nondiscrimination aspects that other working groups that the Secretary has are dealing with, but with specific aspects to the use of genetic test information in electronic health records there are a couple unique concerns that we anticipate working on with this group. And I should point out that Deven McGraw is also on the AHIC working group for Personalized Healthcare, so there are some aspects of this that will be shared back and forth with this working group.
The particular small piece of the pie, if you will, related to security and privacy and confidentiality aspects of the genetic health component to the electronic health record is as follows. There are capabilities, even if in a de-identified world, in which laboratory information is shared, that there are specific aspects of the genetic code that if enough information is captured in electronic health record that it may be feasible in the future to identify individuals even under de-identified circumstances.
And so there are aspects of this that we are at the very earliest stages of exploring, but even post-HIPAA and following all of the rules regarding privacy, but there may be aspects in which the integration of different data sets and different capabilities may provide ways to link and identify individuals, even if that information has been stripped of identifiable information. And this is just because of the commonatorial aspects of saying if you've got enough information about your genetic code that we can identify through specific mutations or sequences of genetic information that are relative to individuals, that that information can linked with other data sources to ultimately come back and identify people.
And this isn't to overhype things at this point in time, but it is a nuance that in the post-HIPAA environment with genetic information we now know that the capabilities exist there and there are mathematical models that can portray the potential risks for these kinds of issues.
So I won't belabor these aspects any further, but I think one of the elements that the Secretary has asked us to do, and working with the AHIC groups, is to identify, characterize, the issues, and then look at potential ways in which these working groups can deal with these upcoming emerging issues as they relate to genetic test results.
There's a fair amount of literature that's starting to evolve on this, and we can make it available to this committee if they're of interest, and there will be reporting back, I think, periodically to you on the deliberations that this Workgroup has been dealing with.
So bottom line is that we think that genetic information is not anything that we want to provide exclusive considerations for relative to electronic health records, but there are concerns about how that information may be aggregated in some ways that can affect the identifiability of individuals, since laboratory data are used in a variety of fashions.
And I'll just stop there, and if there are any questions about how these Workgroups may work together, or the specific aspects of the confidentiality concerns related to these test data, I'd be happy to try to take them on at this point.
>> KIRK NAHRA:
Questions from anyone on the phone? Any questions?
>>:
No.
>> KIRK NAHRA:
Questions from anyone around the table?
>>:
I just have a couple kind of process or format questions. In the Workgroup membership, do you have anyone with bioethics experience or--
>> GREGORY DOWNING:
Yeah, that's a very good question. Kathy Hudson is from the Johns Hopkins project and a number of others, Mark Rothstein, and Amy McGuire is a medical ethicist from Texas and has been working in this area. So we have consumer representatives as well.
>>:
Great.
>> GREGORY DOWNING:
They're just now beginning their deliberations and we would be more than happy to share with the chairs, when there are segments of meetings coming up we'll give you advance notice about how to bring that forward, and we would certainly appreciate the expertise that's coming forward here at these meetings. And the technological solutions and the policy solutions are going to be tough enough to crack, but I think important ones for both of us. We welcome the opportunity, and I think our partnership with ONC and AHIC has really been very beneficial to what the Secretary is trying to achieve in this space.
>>:
Thank you.
>> GREGORY DOWNING:
Kristen Brenner is from our staff, will be staying with you during the rest of the meeting.
>>:
Thank you.
>> KIRK NAHRA:
All right, thanks. Any other comments from anyone on the Workgroup about working together with that new Workgroup? I guess we're not the baby anymore. But is there any other reaction, any other thoughts as we move forward on that?
Okay, why don't we move to our first agenda item. Actually, Paul, do you have any opening remarks?
>> PAUL FELDMAN:
Other than to wish everybody a happy new year, and I think we're going to have a nice, productive, and busy year. So--
>> KIRK NAHRA:
All right, why don't we move to our first topic for the day, which is to discuss and hopefully finalize our recommendation letter related to identity-proofing. I'm hoping that everyone has at least seen the final draft of that, is there anyone who does not have that most recent draft?
Why don't we walk through it, and we'll try not to break it into too many pieces, but I do want to get just people a chance to have comments again, we've obviously been through a number of rounds on this. But with that said, if people have questions or comments, please don't hesitate.
Why don't we start with the background and discussion. I'm assuming everything above that, just copied, is fine.
Steve, do you want to walk through it with us?
>> STEVEN DAVIS:
Yeah, I can, it’s just a matter, you guys can step us through down, and once we get into the specific changes, you know, I can help you guys guide the members through that.
>> KIRK NAHRA:
Okay. Well, any questions or comments on what's now a very brief background and discussion section?
>> DEVEN McGRAW:
Kirk, I had a question. The sentence at the end of the first paragraph, where it says in addition the recommendations do not intend to make care conditional on the use of or attempted use of services for electronic access to health information, I wasn't-- what are we saying?
>> KIRK NAHRA:
Well, here's what we were trying to get at. We were--
>>:
What's that paragraph, again? I didn't catch --
>> DEVEN McGRAW:
Oh. Sorry, it's the first paragraph of background and discussion, the very last sentence.
>>:
Thank you, I'm sorry.
>> KIRK NAHRA:
The point, if I can try to characterize -- we've actually had a lot of discussion on this sentence. The idea was we were laying out methods for identity-proofing for people to have access to EHRs, PHRs, instant messaging, et cetera. And we did not want the inability of a patient to, for example, meet some of those identity-proofing standards to be viewed as okay, since you can't meet that, you can't get care from the doctor.
So the idea was we were trying to say-- we're not talking about that issue, we're not saying anything about ability to get care. But it was a tough-- you know, sort of a tough thing, basically raising an issue that we weren't sure anyone was going to think about anyway, we're sort of raising an issue and knocking it down in the same sentence. So that was the goal of the sentence. Is that a fair characterization, Steve?
>> STEVEN DAVIS:
Yeah, we received a couple comments and notes based-- that revolved around that issue, and we tried to find the best place to put this type of sentence.
>> DEVEN McGRAW:
I don't quibble all with the point and I think it's worth making, just in case someone would jump to that conclusion. I would just make it exactly as clear as you said it, and maybe it needs the sentence to go somewhere else, which is, you know, failure to meet these identity-proofing requirements should in no way become an obstacle to getting care or a condition for getting care. And maybe because it speaks to the different identity-proofing pieces, it needs to go either after that piece, or-- you know, somewhere where the context becomes more clear. So.
>> KIRK NAHRA:
Well, I mean, that is frankly a more direct way of saying that, maybe that's--
>> STEVEN DAVIS:
Yeah. I mean, just as a suggestion, I've got us down-- originally we placed this as the second note in recommendation 1, for the first one that's italicized, we had I guess a semicolon or secondary note to add that concept. We could probably add a second sentence there to the note that says, “Failure to” --
>> KIRK NAHRA:
There are two issues, it seems to me. One is placement, two is what it says. Let's start with what it says. I mean, I don't-- we went back and forth on this sentence and I don't think any of us loved it. Despite the back and forth.
>> DEVEN McGRAW:
I think the problem in the drafting is probably about trying to make it fit into a background section before you've even discussed what the different components of identity-proofing are. So that forces you into being-- you know, trying to sort of work your way into it. So placement may actually fix-- help you fix wording. I mean, it could just be a note.
>> JODI DANIEL:
As far as what I think I just heard, text, let me propose a change in text and see if this makes sense, and see if this is clearer. Failure to meet identity-proofing requirements for electronic access to health information should not interfere with obtaining healthcare services.
Is that--
>> PAUL FELDMAN:
And I think a more direct way of saying it would maybe fit better back where you originally had it, which is as a second note.
>> JODI DANIEL:
Okay.
>> PAUL FELDMAN:
Because then it takes it out of the background and puts it where it's a note to the recommendations.
>> KIRK NAHRA:
So do we want to start there after the italicized part? For people on the phone, I don't know if all of you are following along on the Web, this is a document that's now posted on--
>> STEVEN DAVIS:
It's on the Website.
>> KIRK NAHRA:
On the Website.
>> JODI DANIEL:
But it's the top of page 3, so anybody who is not on the Website.
>> KIRK NAHRA:
Do you want to read your language again, Jodi?
>> JODI DANIEL:
Yes. Again, failure to meet identity-proofing requirements for electronic access to health information should not interfere with obtaining healthcare services.
>> KIRK NAHRA:
Now, let's just-- there are three points we could be making, here. We could say it shouldn't interfere, we're neutral, or it should interfere. Obviously, I assume nobody thinks it should interfere.
Your sentence is more affirmative. I don't know whether any of the physicians-- is that an issue at all for physicians?
>>:
Can we state that one more time for those of us who are listening on the phone again?
>> JODI DANIEL:
Sure, I’ll repeat it slowly.
>>:
Might take a couple times so--
>> KIRK NAHRA:
We'll do this one slowly so that Steve can get it typed up on the Web, also.
>> JODI DANIEL:
Okay. Failure to meet identity-proofing requirements for electronic access to health information should not interfere with obtaining healthcare services.
And that was based on just the discussion we just had on the language.
>> THOMAS WILDER:
This is Tom Wilder with America’s Health Insurance Plans, and I would very strongly support that statement. I think we need to be very clear that we shouldn't let these-- while these kinds of process things of verifying identity are very important, we shouldn't let it interfere with the delivery of healthcare, which after all is what this is all about.
>> KIRK NAHRA:
Well, I guess -- let me just followup on that, Tom. Is-- I guess I'm still trying to work through in my own mind whether we want to be neutral or as affirmative as this.
I mean, if a doctor-- if a doctor, for whatever reason, thinks he or she shouldn't be treating somebody because they can't get the right information about them, I assume we don't want to interfere-- I mean, my assumption is we don't want to have these standards affect the provider's judgment one way or the other on whether they're going to treat this person. Is that a fair statement?
>> THOMAS WILDER:
I guess where I'm trying to come from is if a provider, in their best judgment, believes they need to access an electronic record and they can't for whatever reason get-- you know, authenticate the specific person, I'm happy letting the doctor go ahead and access that. Because I think they're in the best position to decide whether or not they need to do it.
>>:
That's sort of the break the glass sort of functionality, though, isn't it?
>> THOMAS WILDER:
Well again, we need to take a step back and remember the whole purpose of what we're trying to do here is get better care to people. And so we shouldn't set up these kinds of artificial rules and processes that interfere with getting better care for people.
>> KIRK NAHRA:
Let me jump in again for a second, Tom. I mean, it seems to me you're making two different points, and I guess I want to identify them as being different. One is, I think, the question we started with, which is if a patient or provider can't meet a particular identity-proofing standard or any of the identity-proofing standards, and therefore their information is not going to be entered into the record or whatever, that shouldn't affect their ability to get care. I think that's the point we were focused on and really had had our discussion about.
You're raising a second point as well, which is the doctor's flexibility to access information, even without the ability to identity-proof somebody, that strikes me as a fair issue to talk about, but a very different issue.
And one that I'm not sure is really on-- I mean, it's not-- I don't know that it's not on the table, but it's not this issue, I think.
>> THOMAS WILDER:
Okay, well, I guess I had misunderstood what this issue was. I mean, I would agree with the first point and I actually would push for the second point as well, but I'll defer as to whether or not you think it's part of this letter.
>> KIRK NAHRA:
Let's focus on the first one, and see if we can come to some conclusion on that one, then let’s talk about whether we want to get to the second.
I guess let's go back to my question, which is you could argue that this sentence basically says to the doctor, you have to treat them. I don't know if we want to say that, just because that's-- you know, that's in some way a removing flexibility, or could be viewed as removing flexibility. Do we want to be an advocate here or do we want to be neutral on it? This shouldn't create new burdens on receiving treatment.
>> THOMAS WILDER:
Since we're wordsmithing here, if we want to change the word “interfere” with the word “impede” or something softer, aren't we essentially holding a fairly strong position but at the same time we're giving some leeway, there? I mean, we're not taking-- I hear what you're saying, Kirk, that that's an awfully strong position to take.
>> JODI DANIEL:
Impeding access to care?
>> KIRK NAHRA:
Maybe that would be something, impede access to care. Do you want to type that in and see how it looks? Or access to healthcare services?
So let's just read it out in case anyone doesn't have it in front of them. Failure to meet identity-proofing requirements for electronic access to health information should not impede access to healthcare services.
>> JOHN HOUSTON:
I think you need to make sure it's clear what's not being impeded. There's really two different audiences here, there is the physician user and some people might read it at the same time to mean that the patient wouldn't be excluded from healthcare if they didn't-- if there was some decision not to participate.
And I understand we're talking about identity-proofing, but we want to make sure we understand what the target audience is here who would not be affected. So, not impede patient access to healthcare services.
>> KIRK NAHRA:
Well, that, I mean, I guess I struggle making those words say that somebody could be impeded, but would patient access do that? I mean, would that--
Who was that making that comment?
>> JOHN HOUSTON:
John Houston.
>>:
If we're not going to address the other side of that equation which is the provider's access to data, if we're only hitting this first side, and saying specifically that we're talking about patient access to healthcare services would do that. But it does blatantly leave that other side of the coin out at that point.
>> JOHN HOUSTON:
We just have to be very clear, because I think this sentence can be-- I think you could interpret this sentence three or four different ways, based upon the way it's drafted.
>> KIRK NAHRA:
Does adding the word patient reduce that to one way to read it?
>> JOHN HOUSTON:
Probably-- actually, I'm still pulling up the website, I apologize, so I'm listening over as you read it out loud, so give me a--
>> JODI DANIEL:
Do you want us to read it again?
>> JOHN HOUSTON:
Yeah, please, I'm sorry.
>> KIRK NAHRA:
Failure to meet identity-proofing requirements for electronic access to health information should not impede patient access to healthcare services.
>> JOHN HOUSTON:
Okay but now the first part of it is whose failure to meet identity-proofing standards?
Who would that be? Who would be failing to meet those-- the--
>> KIRK NAHRA:
The full recommendation is identity-proofing of the patients.
>> JODI DANIEL:
Right, this would now fall within recommendation 1, which says entities that offer healthcare consumers electronic access should perform identity-proofing, and then it gives the three options. So it would be in that context, that it would be the entities that are conducting the identity-proofing, if they're unable to sufficiently do that.
>> JOHN HOUSTON:
So a patient's failure-- or which one is it? Is it a patient or the healthcare provider's failure to--
>> KIRK NAHRA:
Well, the provider is doing the identity-proofing.
>> JOHN HOUSTON:
But who is failing-- who is actually--
>> JODI DANIEL:
How about instead of meet failure to--
>> KIRK NAHRA:
Successfully--
>> JODI DANIEL:
Successfully identity-proof or comply with one of the recommended identity-proofing--
>> PAUL FELDMAN:
I think what I'm hearing his point is that the patient can't show you a picture ID or prove to you that they are who they are, or is it the healthcare provider can't somehow succeed in the identity-proofing process? Is that--
>> JODI DANIEL:
I think it would be either one.
>> KIRK NAHRA:
Either one, is what I--
>>:
>> Does it make a difference?
>> KIRK NAHRA:
Yes.
>>:
If the patient-- it seems to me regardless of why it is, if they can't meet the standard the patient is still entitled to care.
>> JILL DENNIS:
This is Jill Dennis, I wonder if I could just jump in too. Because I think it is either one, the effect is the same. But I think what we were trying to say originally was that doesn't relieve someone of what may be their legal obligation to provide care to a patient. But that you wouldn't necessarily then go on and set up an electronic account for someone, you know, to have access to their data. Do you see what I'm saying? There's a difference between access to care itself, and then setting them up for an electronic account, where they can browse their PHR or whatever
>> JODI DANIEL:
You might want to get rid of services, and just say access to healthcare, because the electronic accessing information could be a related service. So just end it at healthcare. That might clarify that we're just talking about the care itself, as opposed to--
>>:
Do you want to add--
>>:
I still think we want to add the word patient.
>>:
For that access. No-- yeah, right before access.
>> JOHN HOUSTON:
I apologize, I pulled up the AHIC, the site for this meeting. Is somebody typing something on a screen?
>>:
It's not happening.
>> STEVEN DAVIS:
John, it's not live, you're just going to have to follow with your electronic version or whatever copy, if you've got a printed copy.
>> JOHN HOUSTON:
I'm not missing anything.
>>:
No, you're not. Our technology isn't very good, apparently.
>> KIRK NAHRA:
So here's the current version. Failure to meet identity-proofing requirements for electronic access to health information should not impede patient access to healthcare.
>> JOHN HOUSTON:
Read it one more time, please.
>> KIRK NAHRA:
Failure to meet identity-proofing requirements for electronic access to health information should not impede patient access to healthcare.
>>:
I would agree with it.
>> KIRK NAHRA:
Any questions or comments on that language? Everybody okay with that language?
>>:
I think it's clear.
>> KIRK NAHRA:
All right. Sold.
Any other questions or comments on-- we'll go now back to the background and discussion. That sentence has been moved out of that section now, but with the rest of the background and discussion section, any additional questions or comments? Going once, going twice. All right, moving on.
General statements, starting on page 2 of the working draft. Any questions or comments about general statement 1?
All right, anything on general statement 2?
>> SUSAN McANDREW:
This is Sue McAndrew. Back on general statement 1.
>> KIRK NAHRA:
Yeah.
>> SUSAN McANDREW:
I think it would help throughout to keep emphasizing that we're just talking here about identity-proofing of the consumer, and this isn't an identity-proofing structure for all people who may be wanting access, such as third-party users or others.
>> KIRK NAHRA:
I think that's a fair point, I'm not sure that general statement-- I mean, general statement 1 I think is-- would apply to anyone, wouldn't it?
>> SUSAN McANDREW:
Right, but we don't care about that.
>> STEVEN DAVIS:
Sue, this is Steve. I think to make it more specific we could put patient in front of identity-proofing.
>> SUSAN McANDREW:
Okay.
>> STEVEN DAVIS:
This is the definition from the Federal Register so we're not really open to editing it, I would say, but we can, I think, make it more specific with that modifier.
>> SUSAN McANDREW:
Okay.
>> JODI DANIEL:
I can also note that in the background section the first sentence of the second paragraph specifically says the recommendations below intend to establish a base point for patient identity-proofing in the electronic health information exchange environment. So-- so you're just saying carry that through?
>> SUSAN McANDREW:
Yes.
>> JODI DANIEL:
Okay.
>> KIRK NAHRA:
All right, anything else on 1 or 2? How about number 3, under general statements? Anything on number 4 about general statements?
>>:
Number 3? Couldn't we just say rather than saying all data, including secure messaging, EHRs, or PHRs are sensitive, shouldn't we say should be considered sensitive?
>> KIRK NAHRA:
Is there a concern that you're trying to address with that?
>>:
Some people might argue that they might read that and say that's not the case, and you'd say well, let's just consider it to be that.
>> KIRK NAHRA:
Thoughts on that?
>> DEVEN McGRAW:
I mean, I certainly see the point. You could add to the end of that sentence “to someone”, and that would make it unequivocally true. Now, I think that the point on the phone is that what's contained therein may or may not be sensitive. But we're not able to determine that.
>>:
We’re assuming it’s sensitive.
>> DEVEN McGRAW:
Only the individuals --
>> KIRK NAHRA:
All right, so “should be considered sensitive”? Anyone have a concern with that? All right, anything on number 4?
All right. Last chance, anything on the general statements section in its entirety?
>>:
That would be a good place, by the way, on 4, to put the word "patient" before identity-proofing.
>> KIRK NAHRA:
Okay. Anything else for anyone on the general statements?
All right, we are finished with that, let's move on to the recommendations. Recommendation 1, entities that offer healthcare consumers or their authorized proxies electronic access to data and services through secure messaging, PHRs, or EHRs should perform or rely upon identity-proofing performed by the entity or an accountable trusted third party that meets or exceeds one of the following options.
Note, if the primary method chosen by an entity does not apply in some instances, one of the other methods below should be chosen.
So very much an introductory description going into our specific recommendations. Any questions or comments on that first paragraph of recommendation 1?
>> PAUL FELDMAN:
I just have a question about the footnote. A trusted third party is an entity that both the healthcare consumer or their authorized proxy and entity trust for purposes of performing-- that to me implies that everybody knows who actually did the identity-proofing, and I'm not sure that that's always the case. I mean, in a truly interoperable world, if somebody receives a message -- they may not know -- who ultimately releases information. They may not know who actually did the identity-proofing up front.
If someone sends a message from their PHR to a lab asking for lab data, is the lab going to know that Dr.Jones or Dr.Smith conducted the identity-proofing? I doubt it.
>> STEVEN DAVIS:
I think that's what the point of the footnote is, and maybe it doesn't say it well. But to-- but it's part of a, of a transitive trust, I guess? So that there will be-- there will be burdens along the way for entities seeking to authenticate to the network to have robust identity-proofing and credentialing and that sentence, it sort of acknowledges that-- it's to say that the entity itself is not going to be doing this, it's obviously incredibly impractical.
>> KIRK NAHRA:
Well, but let's--Paul is raising a fair point and I'm trying to see whether, how this accounted trusted third party fits into that.
I mean, my understanding of the third party is that I'm-- I go into a notary, and let's use a notary as an example, I go into a notary and the notary identity-proofs me. Doesn't the hospital have to know where that's coming from? In order to rely on it? At some level? Otherwise, they haven't done anything.
>>:
Well, a notary is a notary.
>> KIRK NAHRA:
Yeah, but they have to know it's a notary.
>>:
That’s right.
>> KIRK NAHRA:
They don't have to know anything about John Smith's personal background as a notary I suppose, but they need to be able to rely on the fact that a notary has done that.
>>:
But you have said that already here, because you've essentially said that it has to be a trusted source on all sides.
>> KIRK NAHRA:
Right, I agree with that, but that goes to Paul's question. Paul’s saying one of the sides sometimes won't know-- I guess I'm questioning that. In this third-- in this situation where a trusted third party is the one that's doing the identity-proofing, are there situations where the healthcare entity won't know who that third party is?
>>:
Well, I guess that's making the position that you can't consider them a trusted third party unless you know and trust them. I mean, by definition you can't.
>>:
Then you shouldn't be engaging in any of these activities, unless you have a contractual understanding.
>>:
Right, by definition it wouldn't be occurring, there wouldn't be the exchange if it wasn't a known entity with whom there was a relationship. Just by definition of the concept of identity-proofing and trusted parties. It's part of the package.
>> DEVEN McGRAW:
And in the notary example, you would trust, as an institution, that notary even if you don't know them personally, because there's a notary seal.
>> KIRK NAHRA:
But you would know it's a notary.
>> DEVEN McGRAW:
You would know it was a notary. And it really becomes your decision, then, when it's a third-party source that's done the identity-proofing on the patient side, for example, whether you would trust that or not.
>>:
And you're actually trusting that institution.
>> DEVEN McGRAW:
Right. Identity-proofed. And on the patient side, that provides the patient with some measure of confidence that in fact they know who is identity-proofing them. Which I assume is probably going to be the more likely scenario, where the patient has used a certain source, and it's up to the institution, if it's--
>> KIRK NAHRA:
Well, we're talking about patient identity-proofing there again, back to the other point. So I guess, Paul, is your situation actually ever going to come up?
>> PAUL FELDMAN:
I would think so. I mean, use my example in the case of the PHR, a patient has purchased the PHR, somebody has identity-proofed that person. As I understand it, in a truly interoperable world the PHR will be able to send messages to various providers to download information. It seems like we're saying either each individual provider needs to identity-proof that patient every time they send a message with the initial message. Which I don't believe would be the case.
>> DEVEN McGRAW:
But that's when the--
>> SUSAN McANDREW:
Not to use the terminology consumer access of this entitysort of operating on behalf of linking all of consumers or many consumers with many different provider or encounter levels. Encounter institutions. So that they don't have to do it on a one-off basis, it's just a service that is a trusted third party that's doing that.
But certainly, I would anticipate that a provider would need assurance from that trusted third party before they relinquish the data.
>>:
Then it could be the case that actually another provider becomes that trusted third party just by virtue of the fact that they went in to their doctor and they were identified and then they were put into the system. Now that system is being accessed by another provider, the fact that they were put into the system itself, someone somewhere had to identity-proof them to get them in there. And so by virtue of that, you're treating another provider as that trusted third party.
>>:
Right.
>> STEVEN DAVIS:
This Is Steve, I guess I have two solutions. The quick and dirty simple one would be to say that the Workgroup assumes a trusted third party, and finish the sentence, or we can digress a little bit further and walk this out a little bit more. I think what Paul is getting at is envisioning the technical solutions of what it would mean in vision of that. I think other people with more technical expertise and background that have dealt with digital certificates and whatnot, there's a certificate authority that issues -- that's the trusted third party, they issue me-- if they issue-- company XYZ a certificate, and I try to communicate with company XYZ and they give me their certificate -- you probably have been presented with this type of option when you go on the Web and do something -- and I look at the certificate they present me and if it's from this certificate authority, and I trust that authority and I accept their certificate.
So there's that central point of trust in that part of the relationship. So that's kind of where I think this is getting at. And the assumption could change, then that's where we might want to put in that first little blurb that I was talking about.
>> KIRK NAHRA:
The point you're making, Paul, is that at some point down the road when these become-- you know, automatic and fully integrated and all of that stuff, you're not going to do individual checking each time you provide a piece of information out. But I think what is going to happen is that the record is going to be-- there's going to be some approval of the PHR in the first place that gets it into the system. That's going to be equivalent of that. It's going to be a different kind of trusted third party, but otherwise the lab that's sending that stuff out is just willy-nilly sending it to whoever asks. And so the lab has to have some reason to have confidence that that's the right person.
>> PAUL FELDMAN:
I agree with all of that. So I just get back to my initial question, does this imply some direct relationship between the healthcare entity releasing, and the person that gets it. I mean, to trust someone I need know them. Does it require that type of personal relationship or not?
>> KIRK NAHRA:
I think it's-- I don't think it's a contract-- back to Alison's point earlier, and I don’t think -- you have to be able to rely on it in some way. And maybe you rely on it because they're a part of this interoperable system that's already done that work.
>> JODI DANIEL:
What about if you changed the word trust, before for the purpose, to is willing to rely upon for the purpose, or something like that.
>> PAUL FELDMAN:
Or can rely on upon. Reasonable reliance.
>> JODI DANIEL:
Or reasonably rely upon.
>>:
Is that it?
>> JODI DANIEL:
So for folks who are not present in the room this would now read, if this is-- based on what we just talked about, a trusted third party is an entity that both the healthcare consumer or their authorized proxy and the healthcare entity trust or reasonably rely upon for the purpose of performing identity-proofing on behalf of the entity
>> PAUL FELDMAN:
How about “can reasonably rely upon”.
>> JODI DANIEL:
Can reasonably rely upon.
>>:
Does that get to your concern?
>>:
-- (Inaudible) conversations we had-- about trusted third parties but we were trying to--
>> :
No, no, I understand.
>> KIRK NAHRA:
All right, let's dive into 1.1, questions or comments on 1.1?
>>:
I have a question at the risk of breaking-- are we saying that only one identity-proofing can be achieved by using a valid government-issued, are we suggesting that only one is sufficient?
>> KIRK NAHRA:
I think we are suggesting that. Am I right in that?
>>:
I don't know that you want to make policy decisions today, but rather recommendations for what would be common, and typically accepted and useful tools for conducting this in-person identity-proofing.
>> KIRK NAHRA:
Let me break-- I'm breaking things down into multiple issues, here, which I know is going to take a lot, but are we saying that one is enough, is that what this recommendation says right now? I think that is what this recommendation says. Is that a correct reading?
>> STEVEN DAVIS:
It says can be achieved, so I think that's the intent.
>> KIRK NAHRA:
Is that the right answer? Should we be saying that? I mean I guess my sense is that that's-- pretty common these days, but--
>> :
Well, maybe we could say at least one.
>>:
One or more.
>>:
That way we’re not, you know. A softer floor.
>> KIRK NAHRA:
It is although-- boy, I would be concerned about recommending that people have to have more than that, which I don't think that does, but--
>> :
Why? Just asking, why?
>> KIRK NAHRA:
I don't know, I mean, who carries around more than one of those things? I mean, the only time I ever do that is if I'm traveling internationally and I need my passport. Otherwise I have my driver's license, I never carry my-- I don't have a military ID, I don’t have a-- you know. I just think that would be a very high standard.
>> JILL DENNIS:
This is Jill Dennis. Keep in mind it's really not one, it's one in combination with the fact that they're standing in front of you and you're looking at them. So it's not like someone is faxing in a copy of a driver's license. You're comparing a driver's license to the person who is standing in front of you, and doing some sort of comparison.
>> KIRK NAHRA:
In-person identity-proofing, I'm sorry.
>>:
That's right.
>>:
Then you have the card or something and you have the face matching.
>> :
I don't see any problem with making it at least one, though. It doesn't say that people have to have more than one. It leaves it open for institutions or organizations that for some reason may want to have more than one.
>>:
Or it interferes with the existing process that has two, and they get confused, who knows.
>> KIRK NAHRA:
I don't have an objection to that. Does anyone have an objection with adding “at least one”?
>>:
Not an objection, per se, just a question of can anyone help identify other situations that we need to produce one or more? As the “or more” I'm looking for, similar situations where we're trying to protect our identity.
>> PAUL FELDMAN:
I mean, I just applied for a passport, I have to provide my old passport, a driver's license, another piece of documentation, and my phone or an electricity bill showing my address.
>>:
Right, that was to get the passport, not for-- or was that considered their identity-proofing?
>> PAUL FELDMAN:
That was their identity-proofing to show that I am who I say I am.
>> KIRK NAHRA:
Well, okay, but let's play that out, Paul. I think you give them the old passport so there aren't two passports floating around, right?
>> PAUL FELDMAN:
Or a copy, yeah.
>> KIRK NAHRA:
But the utility bill wouldn't fit this, because that's not a government-issued picture ID, even in that situation I'm not sure you have more than one government-issued picture ID. We could debate whether turning in the old passport meets that or not, maybe that does, but-- the other things you mentioned would not fit this criteria, because it's not a government-issued picture ID.
We could say you've got to bring a picture ID plus a bill or a letter addressed to you at your address, but we haven't-- we certainly haven't gone that direction so far.
>>:
So if we were to say at least one or more valid government-issued picture ID to verify, are we not locking them into having more than one of those specifics? Rather than-- you know, somebody might want to make-- an organization might want to make a risk-based decision that I want to see a government ID, but I also want to see your last bill from us, or an EOB, or something, you know.
>> KIRK NAHRA:
Well, this is-- I mean, it seems to me this is saying can be achieved. We're not forcing anybody to do anything as a result of this. We're just saying it's an appropriate identity-proofing method to show up in person with a driver's license or a passport. And we were concerned that people might not have driver's licenses, so you know we put in some of these other-- other ideas, and we set examples without trying to be exclusive. I don't think we want to be in a position where it looks like we're saying you've got to have more than one of these things.
But similarly, if somebody says I don't want to identity-proof based solely on that, I don't read anything that precludes them from saying I need a bill or I need something else.
>>:
Could we say identity-proofing can be achieved by using at a minimum at least one valid. And then that provides that other option, if somebody wants to be more stringent.
>> JODI DANIEL:
Or you could have just at a minimum and get rid of at least one, because then it could mean other documentation rather than government ID. Because if you say at least one government ID, it assumes that somebody might want two government IDs as opposed to a government ID and a bill or something like that.
>> KIRK NAHRA:
I suppose the only issue I get with “at a minimum” is someone compare-- so “at a minimum” would be you have to start with one of these things, and you could add something else to it, rather than replace that?
>>:
Utility bill(inaudible) ID.
>> JUDY SPARROW:
It's true, the way it reads now it doesn't say that they have to have a government ID. It's saying that that's how you can achieve it. Through a government ID.
>>:
But a government idea would be the floor.
>> KIRK NAHRA:
At a minimum make that a floor.
>>:
Yeah, it does.
>>:
And raising another question, are we just going to go U.S. government entity ID? Because that's the list here, I think.
>>:
Passport wasn’t intended to--
>> :
Passport could be from some other country but if there are other means of identification in officialgovernment -- you know, picture ID, valid.
>> KIRK NAHRA:
I'm sorry, I'm not sure which direction you're going on this. Saying it should be?
>> :
You're right, Steve, I had initially read passport to be -- because everything on the list but the passport is arguably U.S. government.
>>:
-- driver's license.
>> KIRK NAHRA:
Why wouldn't a British driver's license fit, why wouldn't a-- Iranian or Iraqi military ID count, I mean --
>>:
I mean you know--
>> KIRK NAHRA:
Maybe we want to research it a little more but--
>> LORRAINE DOO:
Well, and Kirk?
>> KIRK NAHRA:
Well, I mean the question is at some point do we have the ability to judge the validity of a military ID from-- wherever.
>>:
There's a comment.
>> KIRK NAHRA:
I'm sorry, someone had something on the phone?
>> LORRAINE DOO:
I'm sorry, Kirk, this is Lorraine, and I don't know if this is an issue or not, but what about, because we’re talking now about government ID and other ID for undocumented aliens, and for uninsured and people who are on the edges of society, will they have this kind of documentation? To prove who they are?
>> KIRK NAHRA:
Well, that's partially why we've got things beyond 1.1 as a recommendation.
>> LORRAINE DOO:
Okay, as long as we're going to accommodate that, because I suddenly had this realization that we were going to be causing a lot of trouble--
>> KIRK NAHRA:
And part of the issue-- I mean, we've gone back and forth on this, maybe this goes back to the point about impeding care. I mean, at some point if someone walks into a facility with no identification of any kind, no prior relationship, none of these things, we don't want that to impede the doctor's ability or obligation to treat them, but we're not sure we want to start plugging their information into an electronic medical record system.
So that was-- that led in part to the clarification that this isn't intended to impede care. But we are intending to set some standard for people to get access to the information through this network.
And so we wanted to accommodate that, but I think we wanted to accommodate it up to a point. I don't think identity-proofing could be anything anybody wants to show that says who they are.
>> LORRAINE DOO:
I don't disagree with you, Kirk, but I also don't want to set up a system where we are reserving the use of electronic health records only for people who are documented or in this country legally. I mean, I agree that the whole care-- I mean, there are health benefits that inure to being part of this system, and I don't want to set up a situation where we're essentially de facto saying that only people who are in this country legally--
>> KIRK NAHRA:
But I guess I don't view-- I mean, we could be subject to that issue if 1.1 was the only recommendation.
>>:
Right.
>> KIRK NAHRA:
I don't see how that's a valid criticism when we have 1.1, and 1.2, and 1.3. I mean if you can't meet 1.1, 1.2, or 1.3-- if we say “or anything else”, that means we've abandoned the idea of having identity-proofing.
>> STEVEN DAVIS:
So in the interest of time why don't we take that instance, which is important, I agree with you, and then like walk through all three and then see how we feel.
>> LORRAINE DOO:
I agree, it's just the listing of documents, but I'm willing to drop it, because I agree that the other pieces are meant to cover folks who don't have the picture ID from a sort of traditional source.
>> STEVEN DAVIS:
And I will acknowledge that I share and I think others-- you know, share the issue that this is-- it reads-- it has some import to it.
>> LORRAINE DOO:
Right, but I'm--
>> STEVEN DAVIS:
Right, it's-- thanks, yeah.
>> KIRK NAHRA:
Well, I'm sorry, so what do we want to do?
>>:
We're going to finish 1.2, 1.3, and then test-- I think the undocumented without government-issued ID is the test case.
>> KIRK NAHRA:
All right, any other comments on 1.1?
1.2? Everyone is fine with 1.2?
>>:
I have a question on 1.2.
>>:
Yes.
>>:
I don't understand the objectives, (Inaudible) had a concern here.
>>:
You have to move closer.
>>:
Oh, sorry.
>>:
There was a concern expressed by some of the folks over at military health systems, particularly with telephonic identification, and that there was concern that perhaps there should be a greater expectation of a give and take with respect to someone is on the phone, say a patient with a medical practice, that perhaps they should be expected to give some form of information that proves their identity when over the telephone.
I think there was less concern about, say, a patient walking into a practice and being visually recognized by a provider with whom they have an established relationship. However, over the phone, particularly given if there's change in staff at a practice, or if-- if the practice was of a size that you have a number of different staff or patients coming and going, that perhaps there should be a little bit more stringency with the telephonic recognition.
>>:
So is this just a-- it says where confirmation occurs at the time of their request, is it-- if we just made a clarification there, would that-- I mean, because the assumption is that there is some opportunity to clarify at the time that you're talking to the person on the phone, that they are indeed that person.
>>:
Yeah. Yes. And that if there was something that suggested they might be exchanging a basic identity element--
>>:
Well, see, that's where I sort of thought we already covered that by saying “where confirmation occurs at the time of the request” gives you that ability to say can you tell me the last time you came in, or something that would identify thatI'm not talking to the patient's father who sounds a lot like the patient, I'm talking to the actual patient.
>> KIRK NAHRA:
Well, and the example you're giving of a new staff person. A new staff person wouldn't be able to recognize the voice if they had never had the voice before, it would have to be something else. So I guess I'm not--
>> STEVEN DAVIS:
I think a key part to this, and this option probably gives the largest amount of flexibility in terms of whoever is doing the identity-proofing, using the relationship to determine -- and using that relationship as a basis to determine how they validate that confirmation. So that's pretty much where we're getting at, and in-person and telephonic were just one of-- one or two of many examples we could have offered, I think. They're probably the easiest and most frequent that we heard of, and that's basically what we were getting at. You know, obviously over the phone, and that's how-- how they determine what the relationship is, is what's going to happen, and we're not dictating how that would happen. So that's where the flexibility in this recommendation is.
>>:
Well, would we want to add a footnote that references 1.3.2 that speaks to that relationship? Identity-proofing?
>> KIRK NAHRA:
I guess my preference, just for clarity, would not be to add a footnote to the next paragraph. I'd like to cut down on the footnotes, rather than add to them, if we can. It is the next thing we talk about.
>> STEVEN DAVIS:
I don't know if we want to use another option or re-reference one of the other options, you know what I mean?
>>:
Well, it's just not-- it's that-- (Inaudible) what we mean by using basic identity information where a relationship exists, for the telephonic example. I mean, if you wanted you could just put-- you know, in parentheses, such as point 2 below, if you want to avoid a footnote. It would just be so we didn't have to define it at another place.
I mean, I'm not hell-bent on another footnote, I'm just trying to be more explicit.
>> KIRK NAHRA:
I guess maybe I've lost the-- I mean, what--
>>:
The concern was that whatever it is that's being exchanged to verify the identity of someone over the phone, whether-- and again, you know, regardless of what that is, but that the requirement wasn't quite explicit enough. And that if they were asking, for example--
>> KIRK NAHRA:
Is it not explicit enough, or not strong enough?
>>:
And do you have suggested language? More to the point?
>>:
The suggested language was to use something to the effect of basic identity, or I think the example that Steven just mentioned, or someone just mentioned, about date of last visit, but something that might be particular to the patient. Would be effective.
>> JODI DANIEL:
The information contained in 1.3.2.
>> KIRK NAHRA:
I guess the problem I'm having with that, and maybe I'm just not sure I understand, 1.3 was intended to work where 1.1 and 1.2 don't. And so if 1.3 becomes the same as 1.2, how is that-- I mean, if we're using the same criteria, how is that a better alternative?
>>:
We're not, we're just saying that, you know, we think that the person over the phone is who they say they are, we have this long-term trusted relationship, but before we're going to absolutely seal the deal with that person in a conversation, we're going to ask them some piece of information that we know they should know based on our relationship.
>>:
So we say “examples may include” and then you say where confirmation occurs to the entity's satisfaction at the time of the request. And then you can ask your questions however you need to structure your questions. And then that gives you the bandwidth to know the person, be able to ask the questions you need to ask, to feel confident that you were indeed dealing with that person.
>>:
Entity apostrophe S?
>>:
Sure.
>> JODI DANIEL:
So for those on the phone, this is now in the second sentence of 1.2. And it now, after the colon, it says in-person or telephonic recognition, et cetera, where confirmation occurs to the entity's satisfaction at the time of the request.
>>:
I don't have any objection with that.
>> JUDY SPARROW:
Okay.
>> JILL DENNIS:
This is Jill. My only question about that one is it's just taking me awhile to process it. If we say to the entity's satisfaction, do we intend to say that that's-- I mean, where's the concept of reasonability here? You know what I mean? I mean, do we intend to make that the standard, is that,well, I was satisfied with it, so that's good enough, or-- do you see what I'm saying? Whether or not they should reasonably be satisfied with that is perhaps an open question.
>>:
I would just think that's going to come down to a risk-based decision no matter what you do. The entity is going to have to make that decision.
>> KIRK NAHRA:
We're, I think, not in any of these recommendations intending to-- I mean, somebody used the word floor, earlier. I mean, I don't think any of these recommendations say that if somebody wants more, they're not entitled to ask for more.
>> JILL DENNIS:
I wasn't worried about that so much about that as the opposite, Kirk, where the solo physician practice said hey, it was a voice on the phone and I was satisfied with it. And do we intend to say that that was good enough, and that they didn't ask additional questions? You know I'm just saying what really are we saying, here, in terms of--
>>:
So if we were to say to the entity's reasonable satisfaction, are we then putting some expectation of them making a reasonable determination on that?
>> JILL DENNIS:
Yeah, but I think we've done that elsewhere, I mean, where we've said reasonably rely and things like that, so I'm wondering if somebody is going to see that and spot a nice little loophole opportunity to not do what's reasonable.
>> KIRK NAHRA:
I don't know that there's any way we can stop somebody from-- I mean, if we're going to permit somebody to take action based on a phone call, and they want to-- you know, the new receptionist who has never heard of this person, can't find any record of them in their books, and says okay, you say you're Paul Feldman, I'm sure you are, move right along, I mean, is there anything you can do to stop that?
>> JILL DENNIS:
You can't stop it in advance, but what you can do is say with a reasonability standard, it gives somebody a leg to stand on that that wasn't an appropriate activity. In some of these other criteria where we’ve said reasonably rely, the implication there is they're not going to be able to cite these floor standards that, you know, section 1.2 as evidence of the fact that they didn't have to use, you know, reasonable care in listening to the voice on the phone.
That's my only fear, is that in this one, it just seems much weaker than the others in terms that there is no reasonability standard here.
>>:
What you just did on the screen, I think if you put that where the cursor is, rather than in brackets, that might get to that.
>>:
Identity data might not be sufficient, it could also be other relationship-related data like date of last visit or something like that.
>> STEVEN DAVIS:
Is the concept there, you just want to move it?
>>:
Yeah.
>>:
And then based on basic identity or relationship data.
>> KIRK NAHRA:
But again, I guess I'm not sure that's going to go to Jill's point, which is just, this is an example. Do we need to put--
>> STEVEN DAVIS:
Back to Mazen's comment, if DOD wanted more clarification just with the telephonic example, more so than anything else, that's where the intent of the changes were being -- for people that are listening, we were trying to bring back Allison's point of just referencing the identity data to the telephonic recognition.
So they wanted more clarity on what would happen to confirm telephonic recognition.
>>:
Doesn't that just bring us back to 1.3?
>>:
Sort of.
>>:
What makes this different?
>> KIRK NAHRA:
I mean, it seems to me that what we're sayingis -- and that was the point I was getting at a few minutes ago. I think what we're saying is we put this a little bit in order of priority. Our first choice, although I don't think we say this anymore, our first choice is in-person identity-proofing using, you know, the various IDs.
Then you've got 1.2 as a second choice for someone who is not in person. I mean, if you're in person, you're not going to rely on a phone voice, presumably.
>>:
Or if they don't have a picture ID. You could use 1.2.
>> KIRK NAHRA:
You could use 1.2? Okay, fair point. Then 1.3 is if 1.1 and 1.2 don't work, you also have the ability to use some kind of basic identity data to authenticate them, I mean to identity-proof them, excuse me, but that that is a weaker choice than 1.2.
But I want to make sure we don't-- if we make 1.2 and 1.3 the same-- we're playing with the document right now.
>>:
Then if you were to take out the relationship data and say okay, we have to have some basic identity data there, then you've got an in-between between the 1.1 and the 1.3.
You have to have something a little bit more hard there than just--
>> JUDY SPARROW:
Is the difference that it's or, it could it be one or the other, whereas 1.3 you have to have both?
>>:
But I thought 1.2, I thought the problem was just with the telephone example, right? Is that--
>>:
Yeah, and now I'm wondering if-- if it's-- if the issue is the use of the word "entity" on the second line, the predicate. That instead-- what we're meaning is given that it's supposed to be a longstanding trusted, known relationship, then the person doing the work would have to know the individual. Isn't that the idea?
I mean, it's to get to the point of anybody working at this big clinic just having somebody phone in should not be sufficient.
>>:
Correct.
>>:
But it's not with an entity, it's with--
>> STEVEN DAVIS:
It's with the entity staff. The person. I don't know how you--
>>:
I think the father and son who sound exactly the same, does that get you any closer to avoiding the issues we're concerned about?
>> KIRK NAHRA:
Well, I mean a couple of things. One is just practically, the father and the son are both going to know basic identity data, right? I’m going to know--
>>:
Which is the relationship information.
>>:
Right. We're not going to fix that.
>> KIRK NAHRA:
Well, I mean, it strikes me that we're at sort of a basic question here now. Are we going to require more? I mean, I think the point of this, the idea here was if I've been going to my doctor for 10 years, and the doctor now has these electronic records, and I want to-- I and the doctor want to use them on some time when I don't have a visit to him, they can rely on the fact that I've been going there for 10 years to identity-proof me. I mean, that was the prototype.
>>:
So for 1.2 you're really talking about identity-proofing them based on a known relationship.
>> KIRK NAHRA:
Right.
>>:
And I think we just say that. That it's based-- that that confirmation is based on known--
>> KIRK NAHRA:
-- that we have an established and durable relationship.
>>:
My recollection is that the telephonic piece of this, I think we had initially envisioned this to be in person, and that we added the telephonic piece for rural areas, and--
>> STEVEN DAVIS:
We're not that concerned about--
>>:
-- rural pieces of it, and I sense that we're overcomplicating it by making the correction that's been requested on the telephonic piece apply to, apply more broadly to the entire recommendation--
>> KIRK NAHRA:
I think that's partially right, but let's talk about Paul's point for a second, which is I've been going to the same hospital for 20 years, and I got my foot taken care of there and I have my physical-- you know, all these kinds of things, but whoever is answering the phone I've never seen before. Never met them, it's a new-- you know, whatever. So what happens in that situation?
I have a longstanding, trusted relationship with the entity, the hospital. I have no relationship with the person I'm talking to.
Now, maybe we don't care about that because the person answering the phone isn't going to give me access to anything. But I mean, I think that's the-- that's the discrepancy.
I mean, your concern in the back was the person they're talking to isn't really a part of that existing, durable relationship.
>>:
But doesn't that then take you to 1.3 anyway? Either you have the relationship or you don't have the relationship.
>> KIRK NAHRA:
The problem is there's a relationship with who. If you're talking about entity you've got a relationship with the entity that is longstanding, established, and durable, but do you have to have it with the particular person you're talking to?
I mean, that's a question, that's the problem that was raised, I'm not sure if it's a problem or not.
>>:
I think the genesis of this conversation is though when we're trying to only talk about secure messaging, and so we were talking about establishing secure messaging standards between, you know, patients and providers, where you're not talking about a hospital, institution, necessarily, you're talking about a smaller practice where the likelihood that you know the person, you know, is-- trying to make it less onerous for a patient who lives 40 miles away to have to come in for a visit expressly to start having an e-mail exchange with their provider.
I mean, that's how we got into having this conversation. SoI'm not sure that--
>>:
That, and the undocumented individual.
>>:
Right. Right.
>>:
Who doesn't have the ID, was another motivator for this.
>>:
Right.
>>:
-- telephonic.
>> KIRK NAHRA:
What do we want to do about this?
I guess my reaction is the way it's written, the receptionist on the phone couldn't really rely on the relationship to confirm anything because they don't have-- they don't have the ability to do that.
It fits very well the prototype of I'm calling my doctor that I've been going to for 10 years.
>>:
I think if you operationalize that, you're going to have the new receptionist answering the phone and Mr.Jones is going to say I've been going to you for 15 years, and then this person is going to get over to the provider or to the nurse that's been there for 10 of those 15 years and say I've got this guy on the phone that says he's been going here for 15 years, and you're going to be able to confirm that, maybe not with the individual.
You're still going to be able to work through that even though you might have an isolated individual conversation on the phone.
>> KIRK NAHRA:
I guess where I'm coming at is I think that's fine the way it's written. But I think the concerns, the potential concerns strike me as situations that are not going to happen very often, or will be fixed the way you're talking about. And I haven't heard a suggestion so far that doesn't make this worse, I think, rather than better.
So we need to either find a way to improve it, to deal with that particular issue-- I don't want to make this worse, or easier, in order to fix that problem.
>>:
So does replacing the word "recognition" with "conversation" help? Convey--
>>:
I'm not sure if it's specific enough to-- to indicate that there's a give and take that is unique to that individual.
>> KIRK NAHRA:
But again, the receptionist who doesn't know the person can't recognize their voice.
>>:
They can have a conversation.
>> KIRK NAHRA:
They can do it wrong, but they can't actually recognize their voice.
>>:
How about dialog?
>> KIRK NAHRA:
Yeah, they could--
>>:
How about let's use the word dialog there, that way you're having a telephonic dialog with the person, and you might use that opportunity and other people -- we've already said the very first sentence there's a durable relationship with the entity. So somewhere in that identity there's a durable relationship. And if you're having a dialog, if you can't confirm it you're going to confirm it somewhere. And then we say when confirmation occurs at the time of the request.
>> JILL DENNIS:
This is Jill, again. Personally I was fine with the way it was originally. The only time I started to worry is when we started to get into the language to the entity's satisfaction. Because I felt that it-- just gave a little wiggle room, you know?
>> KIRK NAHRA:
I assume the idea of the entity's satisfaction is always going to be there whether we say it or not.
>> JILL DENNIS:
But it seems to imply that that's the legal standard. And then using the-- using these recommendations as evidence that they met the standard of care by the fact that they were satisfied, it's kind of circular. Chasing the tail kind of thing to me.
But that's where my doubt about it started to creep in. I thought it was fine beforehand.
>> JODI DANIEL:
This is Jodi. It's the relationship with the entity, and then the concerns that I'm hearing more about, a particular individual within the entity that doesn't-- isn't privy to that relationship. And I'm wondering if in the second line, if this is with an entity, this relationship could be used, you know, that-- it says this relationship could be used, personal relationships could be used to confirm, or something like that, or personal knowledge, or something to say that it's not just the relationship with the entity, but somebody who can verify that on a personal level. If that's what we're saying.
>> JILL DENNIS:
Or not even on a personal level, but just verify that. In other words, if the receptionist on the phone who is trying to set up a secure messaging what the patient said, what are you being treated here for, what was your last visit, there's all kinds of ways to accomplish that. I don't think they have to talk to someone they actually know, I mean, that's--
>> JODI DANIEL:
Okay, so what was just put on the table was “verification of this relationship”, instead of just “this relationship will be used to confirm”.
>>:
I think it was okay the way--
>> KIRK NAHRA:
I'm not sure what that means.
>>:
Given that the first sentence is so strong, there is a durable relationship, that relationship is going to be borne out somewhere in that interaction. And if you can verify that it's borne out, then you use 1.2. If you can't do that, then you go down to 1.3.
>> JODI DANIEL:
Exactly.
>> KIRK NAHRA:
The verification of the relationship sounds like have you been here before? Yeah. Okay.
>>:
Leave it the way it was.
>>:
Yeah.
>>:
Leave in dialog?
>>:
No. Stop.
>> JODI DANIEL:
Sothe proposal on the table is that you revert back to the language in the original document.
>>:
With the exception of changing “telephonic recognition” to “telephonic dialog”, that's it. Excellent.
>>:
So we take out the “to the entity's satisfaction”?
>>:
Yeah.
>>:
Okay.
>> JODI DANIEL:
Now the first sentence is completely unchanged. The second sentence, the only change is “telephonic recognition” is changed to “telephonic dialog”.
>> KIRK NAHRA:
Right. Any last words? Let's go on to 1.3. I'm sorry, was there someone on the phone with that?
>>:
No, I think you heard a giggle.
>> KIRK NAHRA:
All right, 1.3. Let's walk through this. When you're unable to meet 1.1 and the entity determines that 1.2 is not viable, identity-proofing should consist of a method that verifies the person's identity based on information they know or can produce about themselves when asked.
Okay. Well, why don't we stop there. What do people think of that so far?
What we're saying here I think is that there is also other ways to appropriately identity-proof based on other information that can be confirmed.
>>:
And this may help us with the migrant workers and undocumented aliens and other individuals.
>> KIRK NAHRA:
It may or may not, I mean, I don't know what that information is-- I mean, if I'm a migrant undocumented worker, what is the information that is going to be produced -- I don't how that would work.
>>:
Well it’s information they know.
>> KIRK NAHRA:
But you have to know that it’s right. You have to have some way-- again, there's-- the model for this was, you know, I remember somebody LexisNexis or something like that, where I can get on the computer and pull up the last three addresses that Paul Feldman lived at, so when Paul Feldman says I lived at this address, you can say aha, I've confirmed this with some trusted external data source. I'm not sure what that trusted-- I'm not sure where that data’s going to be for an undocumented migrant worker. So it's not clear to me how much help this is going to provide.
>>:
Well then, we do need some safety net. Because I think someone said earlier we're not supposed to be preventing access to care.
>> KIRK NAHRA:
But this has nothing to do with access to care.
>> STEVEN DAVIS:
Can I ask a question? I understand that the migrant workers and all that other parts, if someone appears on a provider's doorstep out of nowhere or wants access out of nowhere, I think everything that we're basing all our conversations on are some data out there somewhere about somebody. And if, you know, the person comes and magically appears, how are we going to deal with that person? I mean that's-- instances where that happens, a person will appear miraculously in the U.S. undocumented, without any data about them, and a lot of these systems, even 1.3double I, which is probably the most robust electronic solution to do not in person, any data that you can tell about you, if don't have any data about you in the U.S, it breaks I think the equation here. I don't think we can go down that road.
>> KIRK NAHRA:
There's two pieces of that. One is nothing we're saying here should have any ability on that person's ability to get care.
>> STEVEN DAVIS:
Right, it's about electronic access.
>> KIRK NAHRA:
Right. The second one is-- electronic access, and we have a question to discuss as to whether we think that person who magically appears like that can get identity-proofed for getting into this electronic system. What do people think about that? We've heard a couple different-- I mean, do we have to have a safety net that allows any person, without any information to back them up, to be able to get access to that system?
>>:
I think we're walking a very fine line in saying we don't believe in identity-proofing if we do that. I think we have to have some sense of-- we've got to draw it back to the whole purpose of this is to know that the person is who they say they are, and if they can't-- I mean, I certainly am an advocate of trying to make it as easy as possible for people who don't have the resources to bring to the table, to find something to help identify them. But I don't think we need to throw the baby out with the bath water, either, in this. And I think we have the potential to do that with 1.3 here.
>> STEVEN DAVIS:
This is Steve Davis. I'm wondering whether we aren't confusing identity-proofing and authentication. If we're talking about getting information about the person from someplace else, aren't we talking about authenticating that that person is who he or she is, in that other system? And then wouldn't they need to have some password or something that was given to them when they were identity-proofed when they put the information in the original system?
>>:
I think if we were just talking technology then yes, we would be talking about that, and we would be confusing it. But I think what we're talking about is finding some common ground that we can say okay, show me something that's from a source that I can depend on. Like you know, you've gotten three -- three bills to an address to your name, that has something that can tie me back to you, or something that gives me the ability to know that you are who you say you are.
>> KIRK NAHRA:
Let me stop there. I mean, I thought that we were, by talking about identity-proofing and not authentication, I thought we were essentially focusing on the first time. And so we're not talking about reaching out to some other source of information to pull in your medical information, we're talking about starting that process.
>>:
Right.
>>:
I think his point going to a reliable data source like the Department of Motor Vehicles, (inaudible), state records, would be that you're going and drawing information that's proving that--
>> KIRK NAHRA:
Right, but it's not medical information, it's not-- I mean, it's not authentication-- I think of authentication as within this, you know, EHR, PHR system, not within the rest of the world. Necessarily.
>>:
I do, too, but I think that when you start trying to use other information to prove the person is who they say they are, you do kind of cloud that.
>> KIRK NAHRA:
Well, I mean, let me go back to something I said a minute ago and make sure we're on the same page. I mean, I clearly understand why we don't want to say you have to have a driver's license. I clearly understand why don’t we want to say you have to have a passport. I think we all understand that.
The opposite of that spectrum is you could be identity-proofed with no information. I also assume we're not saying that, that's the baby out with the bath water.
So the question is, how close to that are we willing to get? And the person that shows in out of the blue-- you know, walks into an office, has none of those IDs, has no prior relationship, has no verifiable data from other sources, what are we going to do with that person? And do we have a problem saying we're not suggesting that that person can be identity-proofed in this setting?
I mean, if I bring-- if I bring in some bills addressed to my house and say here are bills addressed to Kirk Nahra, I'm Kirk Nahra, that doesn't prove anything. That's proves Kirk Nahra got bills at that address, but doesn't prove that I am -- you have to make that connection somehow.
At some point it seems to me-- I don't know that we say it this way in the document, I don't think we say in the document you're out of luck if you're only-- but I think practically, we have to have a standard for identity-proofing. And that standard has to be you have some ability to have information confirming who you are. And I think that people that have no history, no government IDs, no established relationships, no publicly verifiable data, are not going to-- are not going to fit that.
>>:
Right.
>> JOHN HOUSTON:
Could I suggest-- this is John Houston. I agree with what you're saying, and I think that this also doesn't foreclose the fact that if this individual establishes a relationship over the course of a visit or number of visits with a physician or with whomever, that they can actually then at that point in time have enough of a credential established that then they can be vouched for.
>> KIRK NAHRA:
Yeah, I think we want to leave that open, because if I show up 10 times and say I'm Paul Feldman, that doesn't make me Paul Feldman.
>> JOHN HOUSTON:
No, but I think that what will happen then is if you're showing up 10 times and you-- all these services happen to be billed for, and a Paul Feldman ever comes forward and says I've gotten ten bills here, and I never received any of these services, then the presumption becomes much, much stronger because that would also require somebody to not act upon having been billed for services.
>> KIRK NAHRA:
That's a fair point, although again-- I presume there are going to be people who don't have any of the information that we're talking about, and are insured, but there probably aren't going to be that many that fit that, you know. I assume that people that we're talking about for the most part are paying cash or paying nothing. You know, if they're insured they're going to be able to show-- they're going to be able to provide some kind of identifying data.
>> STEVEN DAVIS:
I think this gets to what John is saying, and complements it, it's just eventually the system will accumulate enough data about you to get electronic access. If you come off a plane magically for the first time and you're there, you need to-- the system needs to establish and accumulate data about you. And then you go about, you know, requesting electronic access, and that's what we're getting at here.
The first time you're pretty much, as Kirk said, going to be out of luck. But once you become part of the system, and once you step foot in the U.S, you basically get data accumulated about yourself, you know, it will happen eventually. And whether that's just establishing a one-to-one relationship with a doctor in your, you know, rural area, or if that's, you know, assuming an identity for, you know, an illegal purpose, it's going to happen, you're going to accumulate data that you can use to identity-proof.
>>:
And I think to your point, it goes back to the electronic access piece of it, not the patient care access piece of it.
>> KIRK NAHRA:
All right, let's play this out. It seems to me that the first part of 1.3 is basically saying if 1.1 and 1.2 don't work, here's another option. And that option is a method that verifies that person's identity based n information they know or can produce, that can be verified somehow. We've got a situation for people that have no prior relationship of any kind, and we've got a situation for people that have a relationship, but it's not I guess a durable and established relationship. It's some-- I've been to the doctor once but I haven't been 20-- for 10 years.
So that's what we've laid out. And all of those are going to be dependent on some information being available that can be verified.
Now, it strikes me that the no prior relationship is going to have some publicly available data that's not tied to prior doctor visits. Does the 1.3 little 2 I, so that would say I have to be able to give my name, and that I went to the doctor a month ago, and that would be enough?
>> STEVEN DAVIS:
This is Steve, this all gets to the point of the condition if the entity determines that 1.2 is not-- so the entity determines that they don't want to use 1.2. They don't want to use verifying the relationship whether it's in person or over the phone as their method. They can use 1.3 double I.
>> KIRK NAHRA:
So that would be the situation, I don't have a long enough relationship, I've been to the doctor once. So if I say my name --
>> STEVEN DAVIS:
I don't think it even needs to be that, you can have a durable relationship. They just don't want to use it.
>>:
You have a twin.
>> KIRK NAHRA:
Well, I guess what I'm saying, is this going to really provide a lot of identity-proofing? I mean, if I-- if I know that Paul Feldman went to the doctor once, and I can say-- I mean, is that going to require any more than Paul telling me he went to the doctor, and I can now be Paul Feldman?
>>:
It's usually not that level of information. This is the example of when I call my bank and I want to get access to my account, I need to tell them the amount of the last check --
>>:
What do we put as an example here in 2--
>>:
It’s much more specific.
>>:
Sub 2.
>> KIRK NAHRA:
I'm not sure my example doesn't fit this right now. Challenge the individual by some personal information specific to that relationship. When I went to the doctor last, I mean, I'm not sure that's all that much different than your check situation.
Put it this way, the difference between the check situation, I suppose, is I'm not going to tell somebody that information.
>>:
Right, the likelihood that somebody elsewould know --
>> KIRK NAHRA:
But somebody might for the-- I guess maybethat's the difference between access to care and access to the EHR. If I can get treated by saying I'm Paul Feldman, you know, I'm sure people do that all the time, that's medical identity-based, that's medical identity theft that's intentional. I mean, that people-- you have people trading cards all the time.
Do we think that little 2 I is enough of a floor?
>>:
Well--
>> STEVEN DAVIS:
Just if I can talk through it a little bit in the text that's above and below it. So in 2 I, where we are, second part, where it says “challenge the individual to provide some personal information specific to that relationship”, that re-references the above examples. You know, the last three addresses, last prescription, electronic device, some sort of other verification method, and this is not to preclude other technological advances that may be used to verify the relationship.
>> JODI DANIEL:
So is that really, those examples there, Steve --
>> STEVEN DAVIS:
That's what I'm saying you don't need to--
>> JODI DANIEL:
-- 2?
>> STEVEN DAVIS:
Yeah.
>> JODI DANIEL:
And if we move them down, would that be clearer?
>> STEVEN DAVIS:
I just put the example there because we said produce about themselves, we wanted to make it clear what they would produce.
>> KIRK NAHRA:
Well, the last three addresses has nothing to do with personal information specific to the relationship. Prescription would. Electronic device, I'm not sure what that is, exactly.
>> JODI DANIEL:
Electronic device is the presentation of some sort of-- you know, like card reader or USB that has your file on it. I had a question--
>> STEVEN DAVIS:
Yeah, and it was even along the lines of other evolutions of, you know, they get your cell phone information, they call your cell phone and then you text message them back something. And obviously there's a lot of other technical logistics, but we didn't want to preclude any of that evolutionary technology to--
>> JODI DANIEL:
So is it just the level of specificity that we were concerned with on 1.3 2?
>> KIRK NAHRA:
My question is does that give us enough-- are we comfortable with the identity-proofing can happen under 1.3 2?
>>:
I think it gives them the opportunity to say, well, I saw Dr.Smith, and then we could verify it with Dr.Smith. Who might be a trusted source. And it gives you something to hold on to.
I guess my concern would be are we heading down that path of not requiring identity-proofing?
>> KIRK NAHRA:
That's my question, is that enough of a floor, is that a high enough floor.
Now, again, that-- I guess my-- you know, why I'm going to answer that to say I think it's okay, is the true no prior relationship has a higher standard than what the data is going to be. This some relationship exists strikes me as a relatively limited threshold for the information. But there has to be some preexisting relationship of some kind.
So I guess that strikes me as being-- you know, it's not incredibly robust, but it's far enough away from that you have no information of any kind floor.
>> THOMAS WILDER:
Yeah, this is Tom Wilder, I would agree. I think the important point is, as you point out, there is a prior existing relationship, so it's not like it's out of the blue. And, you know, you're not only asking them for basic identity data, but you're asking them for some unique feature of that relationship that the two parties know about. So--
>> KIRK NAHRA:
Let me ask, this goes back to something I said a few minutes ago. Should we add something at the end of this that talks about reasonable reliance?
>>:
No.
>> KIRK NAHRA:
Why not?
>>:
I'm with--
>>:
Jill.
>>:
Jill, thank you, on the whole-- on the overuse of the term “reasonable”. In hindsight, lots of stuff that might seem reasonable when you did it, looks very unreasonable given a bad outcome. I just don't think it adds very much to the whole equation, and I think it gets us beyond sort of this set of recommendations into some issues that I think we're going to have to deal with in some of the other areas, which is risk assessment and security.
In other words, all of this, to some extent is dependent on where is the entity that holds the liability for a mistake.
>>:
I agree with that.
>>:
And I don't think you can build all of that into a set of recommendations on identity-proofing. Because there's so much more that's impacted by it.
>>:
Before we leave that? This is just personal preference, but could we change the word “challenge” in both I and II to be "require"? “Challenge” just bristles me.
>> KIRK NAHRA:
Sounds aggressive?
>>:
Yeah. It sounds like we're-- you know-- taking off our gloves.
>> KIRK NAHRA:
I'm sorry, someone else started to say something?
>> PAUL FELDMAN:
I may be going back to basics here, but I mean, isn't the information that we're looking for have to meet three standards that it has-- leave Roman 2 aside for the moment, that it has to be independently verifiable by a third party, and needs to be information that is not widely known. And a lot of people know my last three addresses. And it needs to be something that the person can produce when asked. Those are the three concepts that I think needs to be in there, the information that we're looking for
>> KIRK NAHRA:
The not widely known. I think the not widely known is sort of implicit, but I'm not sure it's explicit.
>> PAUL FELDMAN:
It's implicit-- I'm not sure why we wouldn’t be explicit about it. And I look at last three addresses, like I say, a lot of people know that about me, probably anybody, and on Lexis you'll find it for anybody.
>>:
Under .2, that last line, the individual to provide some, could we just say unique-- or information, unique?
>> KIRK NAHRA:
Which part?
>>:
The very last line.
>>:
But again, it could be unique, and still be known-- or--
>>:
Right, well, we can add language, so require the individual to provide some information that is-- you know, unique, and specific to that relationship, and not widely known. I mean, we can have-- I mean, it could be phrased differently, but -- so that you stipulate all of those conditions in that line.
>> PAUL FELDMAN:
Well, I was going to put it in the introductory part of the paragraph, is where I was focused.
>>:
It applies to both. Yeah, I think so.
>> KIRK NAHRA:
Well, but Paul was also making-- I don't know if you were making this point or not, but it raised it in my head, which is we use last three addresses, and just sort of saying well, that's not really a valid-- that's not-- I mean, Paul can look that up for me and pretend he's me and then get identity-proofed as me there.
>>:
Exactly.
>>:
We live in the world of Google.
>> KIRK NAHRA:
So is that a bad example?
>> PAUL FELDMAN:
I think it's a bad example, especially if we say it's implicit it has to be not widely known -- I would make it explicit and delete the example.
>>:
I think depending on the data you're asking for, point 2 is actually more rigorous than point 1. Because I would say that if the data exists out there in some databank, ChoicePoint, LexisNexis, whatever, it is far more widely known and accessible than whatever not widely known information I'd be able -- might be able to impart, given my unique relationship.
So I actually think that the burden is potentially higher, and the way I think of it is that it's higher under point 2 than point 1.
>> KIRK NAHRA:
That makes a lot of sense to me, if-- I haven't tried to look for my prior addresses, so maybe that's-- I mean--
Is 1 creating any kind of a floor? I mean, the-- agreeing with your point, Alison, does number 1, this is somebody who has no prior relationship, and I'm going to go in and say what's your name and what are your last three addresses, what I hear you guys saying is anybody can do that.
Anybody can answer those questions. Anybody who wants to be able to answer those questions can answer those questions. And in fact, just to play that out a little bit, the hospital is going to determine the answers to those questions by using Lexis, which is the same source that I could use to generate the answer. Right?
>> ALISON REIN:
I think they might be-- I agree, I think from their standpoint they may be relying on a third party that's going to cobble together lots of those types of questions in order to complete a portfolio on you that I would then use to validate your identity, as opposed to just your last three addresses. Whether or not that is truly, you know, more reliable , I don't know. But we don't talk about those variabilities within each of these.
>> JODI DANIEL:
So maybe the “some personal identification verifiable by a reliable data source” isn’t-- I might be hearing isn’t sufficient enough -- to be multiple points --
>> STEVEN DAVIS:
Well, sorry to interrupt, but just for clarification I think single I lends itself more towards the PHR world than any other application I would say.
>> KIRK NAHRA:
But it's not limited to that.
>> STEVEN DAVIS:
No, it's not, and I think that was the genesis of this whole “no relationship”, because if you're going within the EHR world, technically speaking, you probably have a relationship.
>>:
Well, it's the first time, though.
>> STEVEN DAVIS:
First time electronic access.
>> KIRK NAHRA:
Well no, you have lots of first time relationships with the provider, you just hope that would be dealt with on 1.1. You're hoping you wouldn't get to 1.3 in that first time.
Are we saying anything in 1 there that is useful and providing enough of a floor. I'm not convinced we were at this point. So do we have to say something more to make sure that the data that we're talking about there is not easily available to anyone who chooses to try and figure it out?
I mean, Alison's point is a fair one, which is if you have a good person doing the checking, or a good process, it's going to be variable enough that I'm trying to pretend I'm Paul Feldman, I've got to do a whole lot of work to convince them I'm Paul Feldman. If it's always the last three addresses, that's easy.
But do we want to give up the opportunity-- so again, presumably, I mean, sometimes what's going to happen is the provider is going to outsource it and somebody else going to do the check. Other times they're going to have access to the data base, and presumably at that point they're always going to check the same thing. Reality.
>>:
I would just say to put us in a situation where we either have to satisfy 1.1 or 1.2, or if I can't-- if I don't have a relationship with you, I can't access your electronic record. Unless that's what we want to say, and say maybe you have to establish a relationship to get it. If you can't satisfy 1 and 2, then you have to establish the relationship to get that access.
Maybe that's a safer way to do it, because then you are at least establishing a relationship so that you can depend on that data for patient care, because you have established a relationship. And you at least know that you're treating this particular person that comes in the door, that you now know, for diabetes. And so you know that the information that is going in there ismore accurate for that person.
>>:
But the issue is the establish of a PHR that would be an untethered, if you will, PHR that has nothing to do with the healthcare entity. And so you're going to sign up online andbuy a PHR service.
I mean, that's-- that was the intention for this.
But the idea-- but that suggests, if that's the major reason for it, that suggests that you would use -- reasonably the vendor would reasonably use a third party, a trusted third party. And therefore, you know, (indiscernible) getting at it.
>> KIRK NAHRA:
The vendor wants to sell you a PHR, they don't want to make it hard for you to buy the PHR.
>> ALISON REIN:
The question is, I think, is in the PHR world where it's untethered, so the PHR company will have no prior relationship with anybody. They need to identity-proof them to establish the relationship. The question is, what I think I'm hearing is that people are concerned that 1.3 1 is not a high enough standard. The question is, is what do we need to add there-- it seems like there's a clear consensus that we need something for that situation.
So what do we need to add there to have a floor that makes people comfortable that somebody isn't going to impersonate another individual and get access to their health information?
>> KIRK NAHRA:
But again, it's that last part that's the tough one, that access to pre-existing information. I mean, you know, again, the start of this recommendations was secure messaging. And we all had a view that something like this would be very unusual to come up in secure messaging, because doctors wouldn't do it with somebody they didn't have a history with. Then we converted it, and all of a sudden it became the other EHRs and PHRs as well.
In a PHR setting for me to just start setting up a record, you know, can be whatever threshold we decide to be, it's when you start pulling data from other places to pull into that record that it starts to become the difficult issue, right? I mean, we don't really care when it's untethered, untethered and not drawing from other sources, it's the when you start pulling stuff in.
Or pushing out may be even more of a concern, right?
>> ALISON REIN:
I guess for me what's lacking is the characterization of the sources and the types, or not necessarily the specific type, but maybe just the sources and the number of different variables that would be required.
>>:
I think what's sticking me is similar to that, in that the word basic keeps jumping out at me. And if it's basic information, it's information that anybody could probably get their hands on. If it's information, to Paul's point, is not commonly known information, then I'm feeling a little bit better about that, I feel there's a little bit more scrutiny. Because I don't have a relationship--
>> KIRK NAHRA:
Part of the problem I think is that what-- I mean, 10 years ago, would my last three addresses have been commonly known? I mean, I frankly haven't even focused on the fact that that's commonly known today, but I guess it is commonly known now.
So that's the problem. Is what's not commonly known today, and what's not going to be commonly known tomorrow. I mean, that's-- I think that's-- yeah, you want stuff that if Paul wants to steal my identity he can't figure out. What is that? And what is that especially if you don't have any relationship?
>> STEVEN DAVIS:
It was hard to come up with something encompassed all the thoughts that you're having. And that was, you know, the PHR example is one, you know, where we wrestled.
>>:
Is there a minimum number of data-- of pieces of data that would make people more comfortable, or is that not-- or do we need to say --
>> KIRK NAHRA:
But that's going back to my other point about what's the harm? If I set up a record that I have in Paul Feldman's name, I can't do anything wrong with that until it connects up somewhere else.
>> ALISON REIN:
Right, but the presumption is that it would.
>> KIRK NAHRA:
But what's the-- where is that-- what's the check there?
>> ALISON REIN:
The same service, if they're validating you based on that information, and then sharing that with a validated institution, that's much easier to identity-proof and authenticate, then they've just (Inaudible) assumed that you are who you say you are, but you're really not.
Based on, you know, whatever flimsy information (Inaudible)
>> KIRK NAHRA:
And what if -- if the real Paul Feldman has his records, again-- I'm just trying to trace where there would be a problem. I mean, if I pull incorrect information into my record, I pull Paul's health history into my record--
>> ALISON REIN:
Huge problem.
>> KIRK NAHRA:
Huge problem for me, not for him.
>> JILL DENNIS:
Oh yeah, huge problem for Paul, if Paul goes in for treatment and isn't known to that care provider and they--
>> KIRK NAHRA:
They have to reach out to something else, though.
>> JILL DENNIS:
Yeah, they would have to reach out to-- you know, someone who is -- either the PHR itself if it's a service provider, and maybe you have diabetes and Paul doesn't, and that affects treatment.
>>:
The patient care issues might --
>> KIRK NAHRA:
I understand I'm trying to figure out what-- if I'm the, you know, the crook in this --
>> STEVEN DAVIS:
You’re talking about pull to your record, you're creating two separate records with Paul's data, basically. The issue is if that data were then pushed back to someone else to provide care. But if you're just pulling-- you're just stealing information.
>> KIRK NAHRA:
And potentially harming myself
>>:
You're harming Paul.
>> KIRK NAHRA:
Only if it's a push, though.
>>:
If you’re a reporter for a less than reputable magazine that wants to publish Paul's medical history, that's a problem for Paul, I would suggest.
>> KIRK NAHRA:
Okay. That's a fair point, although-- although-- but well, let's stop there. I mean, we have a issue, how does that reporter get access to that information in the first place?
>>:
Because he's gone in and says I'm Paul Feldman, and here's my last three addresses, or whatever it is --
>> KIRK NAHRA:
Oh, because he's brought it in? Okay, well, how is this going to stop that person? That person is clearly going to be able to-- he is going to know Paul's last three addresses, and he’s going to be able to do that.
>>:
That's the point of information-- and you're right--
>> KIRK NAHRA:
So this is not good enough.
>>:
No.
>>:
Right, that's what I suggest.
>> ALISON REIN:
I think we're saying it's not good enough. But we're trying to figure out how do we fix what we have --
>> STEVEN DAVIS:
Without being overly proscriptive in terms of numbers of data sources and where the data comes from.
>> ALISON REIN:
Because that's the dominant paradigm that the market wants to move to. I mean, I think everybody around the table knows that, with respect to PHRs, at least I think that's a fairly safe assumption, but it's a pretty scary proposition when you look at it like that. So are we as a group wanting to, as Deven said, try and walk that delicate line of not being overly proscriptive, but --
>> KIRK NAHRA:
You said something that I think is very important, which is this is what the market is going to-- 1.3 little I is the biggest thing we've got to worry about, and we don't have it right yet.
>> JILL DENNIS:
The day we took testimony, we did have the one gentleman who talked about use of publicly available, but a combination of publicly available data, that according to their algorithms was good enough. As far as identity-proofing. And I, forgive me, can't remember what all the combinations were that he was using, but--
>> KIRK NAHRA:
Well, and part of the concern, part of the concern that we had in this setting, though, was forcing people to essentially buy someone's services.
>> JILL DENNIS:
Right.
>> KIRK NAHRA:
In order to do this. We were going to set up-- if our conclusion is-- and I'm not sure it's the wrong conclusion, but if the conclusion is if you have no prior relationship with the entity you've got to buy some high-level software program from some expensive software company in order to do what the market-- you know, for any company to have a PHR, that's going to be a tough-- that's a very severe recommendation.
>> JILL DENNIS:
Well, but what I'm not-- I'm not suggesting that, what I'm suggesting is that perhaps because that company is doing it, perhaps there are some best practices out there in terms of combinations of data elements that statistically are highly likely to be, you know, reliable for identity-proofing.
>> KIRK NAHRA:
Right, but that goes back to the overly proscriptive, we've got to say so many elements of which-- you know, whatever-- let me ask this, are we going to be able to figure this out today?
>>:
You know, if you look at this again -- I'm sorry I'm not answering your question, I think we can. So I did answer your question. But if you read this slowly, it does require both 1 and 2, it doesn’t, we're not just-- I was reading it in isolation, as though 1 was all we had to do, or 2. But we don't say 1 or 2, we say 1 and 2. And so we are-- we're asking them to give us that basic information. Your name, address, your date of birth, give us some basic information, and provide us with some personal information that's verifiable by another source.
So we're not just giving away the farm, here. We are requiring them to give us the basic information, and requiring them to give us something that we can verify somewhere else.
>> KIRK NAHRA:
But I think the problem is that-- for example, the examples we're giving there are examples that somebody else could also find very easily. The fact that it's publicly available and can be confirmed by a vendor means I can find it by Googling it. That's the concern, I think, is that if I want to do this, if I'm the-- maybe the reporter is a good example, because I have trouble seeing why I as a patient would want to intentionally misrepresent who I am so that Paul's information gets in my record. That's going to harm me a lot, that's a bad idea, and it's against my self-interest. The reporter who wants the pull his data, that's the one I understand, I don't know how typical it is, but I can see that, and saying “publicly available data”, that works both ways. If it can be confirmed, I can probably find it. That's the problem, I think.
>>:
That is, so maybe our examples are not the kind of examples that would allow you to really do that. For example, what if we had employer-- if I can't tell you who I really am, but I work for somebody, and I can say, you know, I can give you my employer's phone number, and he can put me on the phone, and that can be verified. Maybe it's our examples that are examples that don't allow that.
>>:
It could be your buddy working at the--
>> STEVEN DAVIS:
To play off that a little bit. Just to explain that. The examples are based on the word, the modifier “reliable”. And that's what we've built the examples off of, that they need to be reliable sources. So we've provided reliable sources of data. You know, most of those are-- I don't want to say government entities, or other types of entities that are commonly used for reliable data.
>> KIRK NAHRA:
But what's the DMV going to have about me that someone who wants to be me can't find?
>>:
Height, weight, color of your eyes.
>>:
Traffic violations.
>>:
But a lot of that stuff is on public record.
>>:
That's right--
>> JOHN LOONSK:
DMV in Washington requires in-person identity-proofing with a fairly rigorous set of information that it was hard for me to deliver when I was there. Original Social Security card--
>> KIRK NAHRA:
Okay, but what data points there that you're going to check with them? I mean, I don't know if they're a source you can check with anyway, but they're not going to have the original Social Security card, they're going to have the Social Security number.
>> JOHN LOONSK:
I do think this argument could continue quite a long duration, that the critical part of it is some degree of responsibility for accurate identification of that, and I'm not sure if you're ready to go there in terms of that being part of it. But you can have lots of different permutations of identity data, identity-proofing information, but the issue with 1.3 dot small I is the group that-- you just don't want groups out there willy-nilly, if you'll excuse the expression, identity-proofing people because it's part of their business model to put as many people online with identities as possible, and that there has to be some accountability for that.
>>:
So I'll go back to my earlier question. In 1.3 do we not want to take the position that if you can't satisfy 1.1 and 1.2 then you have to establish the relationship? Because we’re really not talking about -- I think we float back and forth in the conversation about whether we're talking about access to electronic data, or whether we're talking about access to care.
I think, you know, we have to keep that straight, that we're talking about access to electronic data. And if we really believe that we need to protect that data and provide some sort of identity-proofing to that individual before we give them that access or we infiltrate that data into other data sources, then don't we want to take that position?
>> KIRK NAHRA:
Let me ask you this -- what does do with Alison's point about what the market is trying to do? If I'm a PHR company and I want to sell you a PHR, what is the relationship that I'm going to get with you?
>> ALISON REIN:
You're going to have to use a trusted third party who is going to in-person identity-proof all of this. If you took out 1.3 1.
>> KIRK NAHRA:
I was an advocate awhile ago of pushing the in person more. Are we defaulting back to some of that? I mean, are we saying somebody has got to in person-- you don't have to be in person with the vendor but you've got to be in person with somebody?
>>:
Or 1 3 2
>> KIRK NAHRA:
That's a relationship. What would the relationship be for a PHR company?
>>:
And I guess I'm not worried about establishing an untethered PHR and whether we need to establish any recommendations for that at all. But in either a push or a pull scenario, where we're talking about a Nationwide Health Information Network, then we really do care who you are. And that is what we should care about.
>> KIRK NAHRA:
Is there-- I know less about the market than many of you folks do, I mean, is there such a thing at this point in time as an untethered PHR --
>>:
Yes.
>> KIRK NAHRA:
Wait a minute, an untethered PHR that has no pull and no push?
>>:
Yes, many of them.
>>:
Almost most.
>> KIRK NAHRA:
Okay. Is that something that we-- I mean, if we're going to make a recommendation about that because we're concerned that it's not really a risk area, we'd better very clearly say that, because right now it doesn't-- it's absolutely not limited to that.
>>:
Well, except that what we're aiming for are recommendations that apply to the breakthrough areas. All of which involve push or pull type scenarios.
>> KIRK NAHRA:
So making a recommendation doesn't help us very much in those breakthroughs.
>>:
It's not (indiscernible) a PHR model.
>>:
And it won't be over time.
>> KIRK NAHRA:
So we can't-- again, this is where I started and I'm now clearly not right. You can't-- it's not a question of no harm, here. There's very clearly a potential harm, because we have to assume that we're in an either push or pull or both environment.
>> JOHN LOONSK:
Even in secure messaging you can come up with scenarios where pretexting could cause significant problems.
>>:
If we were to take 1.3 little I out, and make 2 little I I, isn't it going to drive the industry back to 1 and 2, which is our preferred methods anyway?
And we're also leaving enough of an out to where if you want to establish a relationship you can.
>> KIRK NAHRA:
Yes, but it then seems to me we're missing what I hear many of you saying is the dominant model, which is untethered PHRs, but that there are still going to be push and pull pieces. So we can't just ignore-- we can say we have to figure that out still.
>>:
We don’t have to figure it out.
>>:
We don’t have to figure anything out for untethered PHRs.
>>:
That has nothing to do with the breakthroughs. We need to make clear-- with the intention of them being interoperable, a free-standing PHR that you can enter your stuff in, who cares who you are.
>> KIRK NAHRA:
Okay. I'm making a different point, I want to be clear about this. What I heard a minute ago was there's no point making a recommendation about an untethered PHR that's not connected to anything else. That's my diary. I understand that, I accept that. But-- so we're not going to talk about that. But we do need to say something about this dominant business model which is going to be push and pull. Right? What are we prepared to say about that model at this point? I hear David's suggestion being if we pull that out we haven't dealt with situation-- and I know you're not suggesting-- the results of your suggestion is if we pull little I out, we have nothing to deal with that situation.
>>:
I don't think that's true. I think what we're saying is that the model that the market would like to work in, which is no in-person-- because it's easy, right? I don't have to see you in person, and I can-- is in fact not a model that we think that we would recommend. And the way--
>> KIRK NAHRA:
What would happen, then? What happens-- I mean, 1.1 pushes back to a healthcare entity. Are we talking about having something that is some trusted third party doing in-person identification? I'm sorry, in-person identity-proofing?
>>:
There's a plus side and a down side to this, though. I mean, the plus side is we make a statement about what we think is-- you know, reliable and sort of this normative direction. The down side is that then you you're then dictating the form of the market to come for PHRs, and I don't-- I don't want to be responsible for dictating what that is. I would like to see a solution, I just don't know that we're there yet.
This is where a lot of sort of the future or potentially prohibitively expensive technologies come in now, there's a lot of fodder for discussion. But I guess, you know, I don't necessarily want to say that the only institutions that can provide PHRs are those that are healthcare institutions, because maybe they're not going to be the ones that serve the best interests of all consumers.
>> KIRK NAHRA:
Okay, that's-- I agree with everything you said. Let me ask one followup to that, which is, for the PHR model that’s not provided by healthcare, so anyone else that's out there. We have a couple of choices today. One is punt for today. I want to be clear that that is a choice today.
Two is to come up with some version of what's now little I, that has a better set of criteria, and I haven't heard anything today that leads me to think we're going to get there today.
Third is to say that where there is no prior relationship with the entity providing the PHR, there's got to be some kind of in person with somebody.
>> JODI DANIEL:
And if I could just pick up on your third scenario, it seems that if you change 1.1 so it says “should be referred by the healthcare entity”, that if that's not broad enough to include a PHR vendor, then we could modify that so that in person identity-proofing either directly or through a third party could work in a PHR scenario.
>> KIRK NAHRA:
Then you would eliminate the need to have--
>> JODI DANIEL:
1 3 1.
>> KIRK NAHRA:
1 3 1. Or not that we eliminate the need, we basically say that 1 3 1, no relationship, no in person is not an option.
>>:
Yeah, I agree.
>> KIRK NAHRA:
Does that cross your line of setting-- you know, telling the market what-- I'm not sure how hard that is to say PHR, you've got to have somebody to-- you know, you've got to check somewhere, I don't know.
>>:
It would cross my line today.
>>:
I'm thinking that we run the risk then of people just saying, listen-- is it where I would prefer to see things go? Absolutely. But I also think it would make a whole bunch of institutions look at our recommendation and be, like, eh.
>> WILLIAM CRAWFORD:
This is Bill Crawford from CMS, I just joined the call recently. I'm sitting in for Elizabeth sitting in for Tony. And -- people got sick. But I just wanted to echo that, however, that it would be crossing, in my opinion, a line, and I think in the opinion of many people in my agency, a line.
>> JODI DANIEL:
Well, this is Jodi Daniel. It seems to me if CMS set up a PHR or something like that, that they would fall within 1 3 2, having a relationship, that CMS would have a relationship, and could get basic identity data or (indiscernible) to provide specific information or use a third party to do that.
>> WILLIAM CRAWFORD:
Right, from our own programmatic perspective that's correct, and in terms of what we're doing right now with my.Medicare.gov. CMS is, of course, a special case, given that when people become Social Security eligible there are a number of mechanisms in place that are all linked in there. We're still interested in avoiding things which would chill other people from adopting this whole set of recommendations, however.
>> KIRK NAHRA:
Let's play it out a little bit. CMS would fit in 1.3.2. Tom Wilder, I don't know if you're still on the call, by I'm assuming insurers would fit under 1.3.2 also, because they have a relationship with their customers.
>> THOMAS WILDER:
Yes, that's correct.
>> KIRK NAHRA:
So we're really talking about people that are getting a PHR-- you know, a sort of off-the-shelf PHR. So let's go back to-- I mean, if somebody is-- you know, I'm now-- PHRs “R” Us.
>>:
There are affinity group PHRs as well.
[multiple speakers]
>> KIRK NAHRA:
The affinity group would presumably have a relationship with them.
>>:
Unless you sign up with them in order to gain access to -- I mean, you may not have a prior relationship on which to base it. So--
>> KIRK NAHRA:
So what do we want-- all right, that's the scenario, it’s an affinity group, PHRs “R” Us, what do we want to-- I'm trying to make it clear and obvious that it's somebody who has no other-- that's all they're doing is basically selling you basically a software package.
>>:
Right.
>> KIRK NAHRA:
Are we going to require in-person somewhere? I mean, I think I like that answer, but I also understand the market issues with that.
Are we going to say we can come up with a set of identity-proofing criteria today for what those people have to do? I mean, today they're doing nothing, I assume, essentially. They're just selling you the software.
>> WILLIAM CRAWFORD:
Could I throw out just a thought, here, that when I originally read this draft letter, I did not read it particularly as applying as much to the stand-alone PHR providers unless they were releasing the patient-provided data to a third party within the system.
So an emergency room doctor or another caregiver would either have had to have a specific grant of access made by the patient, which is generally the model that those systems use, or if it was done in a more generic way, granted to an emergency room, for instance, that the emergency room would have to be proofed as an emergency room, that could access that data.
That PHR would be responsible as the proxy of the user in the other scenarios, where the user registers that PHR with a hospital, or with Medicare, or with an insurance company, to receive a feed of personally identifiable healthcare data.
So I didn't get all that worked up about the PHR alone as a disseminator of data, and that being able to get a PHR into which you could put data doesn't necessarily require the identity-proofing activity.
>>:
But what if that data is coming from a physician's office or from a hospital, from a healthcare provider?
>> WILLIAM CRAWFORD:
If the data is coming from a healthcare provider, then that relationship does have to be identity-proofed. I mean, there has to be an establishment that this is the individual, and that needs to be communicated back through to the-- to the provider.
>> KIRK NAHRA:
All right, hang on, we're talking about two different things, and I guess I thought we had answered a factual question a few minutes ago. And now what you're saying is something different, which is the idea of a PHR that is just purely stand-alone, nothing going in and nothing going out, is not a real-world issue today. It's just not-- that's not going to happen, those records do not exist to be a personal journal of your health history, it's designed to either push or pull.
>>:
People do use them, but that's not the system or the environment we're discussing.
>> KIRK NAHRA:
Right, so that saying something about those non-push, non-pull records is not worth saying.
So go back, I'm sorry, I forgot the name of the gentleman who was just speaking. But all of the examples we're talking about involve pushing or pulling. So don't we have to get worked up about this?
>> WILLIAM CRAWFORD:
Yeah, I think-- I think we're speaking at somewhat cross-purposes, and I don't want to go into too much depth because I haven't been in some of the precursor conversations to this.
The focus being if the-- I guess my question is does the identity proofing activity always, even in the case where information is being pushed into the PHR or pulled by the PHR from a clinical information system, does the proof of identity have to be presented at the source of the data, or at the PHR side?
In that is the PHR vendor responsible for doing identity-proofing in a way that is then transitive to the original source of the healthcare information, or does the user have to be identity-proofed at the hospital and the insurance company anyway. And if the hospital has provided the PHR directly, it's a one step activity. If it's an insurance company-provided PHR it's a one step activity. If it's a third-party PHR, does the patient, in order to have their information either pushed into their third-party PHR or made available to be pulled into that third-party PHR, do they need to proof themselves at the individual sources of data, or can they be proofed by-- at the PHR, which is then responsible for extending that proof of identity out to the insurance company or the hospital or wherever?
>>:
Same as the discussion we were having earlier, where I thought we came to the conclusion that in fact one entity is going to do it and it is transitive, others can rely on it. Not every source of data is going to identify a person before they release the information. At least in the model as I would imagine it happening.
>>:
Which places a higher priority on getting it right in the first place.
>>:
Absolutely.
>> WILLIAM CRAWFORD:
Thank you for clarifying that for me.
>>:
Which to me goes back to 1.3.1, I think that that provides no value to that.
>> KIRK NAHRA:
So all right, let me-- we are now totally behind. It seems to me that we are not-- we're not going to come up with, today, a set of replacement criteria for name, address, date of birth, and some personal information verifiable by a reliable data source. Does that sound right? We're not going to be able to list criteria today.
The idea of having some in-person proofing somewhere in the system, if I could try to summarize what I heard people saying, has some appeal to a lot of people, but we're concerned about that being in a very different place than where the market is going right now, and therefore we're not ready to recommend-- we're not in a position to recommend that right now. Ready, because I'm not sure we'll ever get there, but that's not something we could recommend. Is that correct?
>>:
And the fact that we could scare people off.
>> KIRK NAHRA:
Could scare people off. So our choice, then, if those two statements are both correct, is continue having this discussion today, or punt on this issue for the time being.
>>:
I'm wondering if we can affirmatively punt in the letter. In other words, to acknowledge the fact that there are these specific scenarios where, you know, we recognize that an in-person type of identity-proofing is not realistic, but that there needs to be a set of criteria to ensure that, in fact, in the scenarios that we're considering, all the breakthroughs, and in any other, quite frankly, set of circumstances where personal health information is pushed into or pulled from a healthcare data source, that we need-- that we're going to be working on coming up with subsequent recommendations about how that would take place .
>> KIRK NAHRA:
So I think-- yeah, I think we should have an affirmative punt rather than a sub silencio punt. I would suggest-- let’s throw this out for discussion, I would suggest redoing 1.3 to basically make it-- you know, just including the healthcare relation-- you know, relationship that doesn't meet 1.1, 1.2. So eliminating little I.
I would not suggest doing some of this (Inaudible) right now. So eliminating that, creating a 1.4 to be the punt.
And we have to write something that says-- I mean, again this is not at all the words, but essentially, we recognize that there are also situations where electronic access will be related to people where there is no preexisting relationship of any kind, e.g.,free-standing PHR, or whatever we're going to say. We have explored but have not yet come to agreement on appropriate identity-proofing steps in those situations, big part of the market, need to deal with it, will continue to do so, something like that.
Comments, thoughts?
>> JODI DANIEL:
The one addition I would have, just based on what I've heard, is that so do you want-- in that scenario, where there's an untethered PHR, but that is pushing and pulling data, that having in-person would be desired, and that you may want to change in 1.1 the healthcare entity to make it clear that if a PHR vendor is not considered a healthcare entity they can still do in person identity-proofing?
>> KIRK NAHRA:
Let's go with that for a second. We can do that one of two ways. Does anyone disagree with the idea that in-person should be a viable alternative for an untethered PHR? That if they can do-- that the people's concern was not that that isn't a good idea, but that we can't force that as the only option.
So we can say affirmatively, and I don't know Jodi whether it's better to tie 1.1 or to make that 1.4, but the thing that we really don't know yet is where -- well, we don't know either that we're prepared to say only in person, or if we need something as an alternative to in person, we're not sure what that is yet.
For the PHRs where there's not any kind of other relationship.
Is that a better way to do it? To say in person is clearly a viable option in those untethered situations. We recognize-- well, we need to continue to debate whether that's the only recommendation we'll make, or we need to find appropriate other alternatives for those non-relationships --
>>:
Could we even go a little stronger than that and say it's the preferred option? It's not saying it's the only, but it's certainly the one that we would prefer.
>> KIRK NAHRA:
I'm okay with that.
And again, and I didn't want to foreclose the idea that we might decide that that's the only thing we can recommend. I don't think we're prepared to do that at all today, and I hear lots of hesitation -- we may never get there. But I don't want to take that off the table, either, I think we should consider whether that's really -- You've got to have some viable mechanism to do in person somewhere in the chain. Recognizing that there's many -- I don't know if we'll ever get there.
>>:
I guess my only question about preferred is while I may agree with you personally, preferred it as compared to "what" and since we haven't specified what the full spectrum of "what" might be, I'm loathe to a priori indicate that I have a preferred means.
>>:
Could we say instead of preferred, most protected or most protective? From a privacy standpoint?
>> KIRK NAHRA:
Let me do this and make it less time. We're recognizing this as a punt. Let's put in that in person in those situations is a viable option. We are examining whether there are other appropriately protective options in that situation. And leave it at that.
So our next recommendation may be, really like in person but here's something else, only like in person -- that will be the next step. Does that make sense to people?
>>:
Say that again.
>> KIRK NAHRA:
Well, I mean put-- this is not the exact wording, obviously, but our punt will be in person is a viable identity-proofing option for these untethered PHRs. We're examining whether there are other appropriately protective identity-proofing options in that situation.
>>:
Okay.
>> JODI DANIEL:
We'd be making-- under that scenario we'd be making an affirmative statement that if you have an untethered and you want to follow the recommendation, you can do it with in person. There may be another alternative that we would also recommend.
>> KIRK NAHRA:
We’re continuing to look at it.
>> JODI DANIEL:
Continuing to look at it.
>> KIRK NAHRA:
All right, any objections with that approach? We obviously need to wordsmith that language, but--
>> JOHN LOONSK:
It's not an objection, excuse the voice, I'm trying to demonstrate that voice recognition may not be a viable--
>>:
I’d still know it was you.
>> JOHN LOONSK:
But I don't think “tethered” is exactly the term you want to use, I just want to clarify that.
>> KIRK NAHRA:
Where there's no relationship.
>> JOHN LOONSK:
Data are not flowing in and out, or something like that.
>> KIRK NAHRA:
No, no, we're not saying that, because we're saying this is going to be data that's flowing in and out. It's-- PHRs in a situation where there's no existing relationship.
>> JOHN LOONSK:
Okay, then I would recommend using thatthan “tethered” at all in these discussions.
>>:
Well, it's no existing relationship, and no ability to do the in person identity. Someone could show up in an office with a driver's license, passport, and all the rest, doesn't that fit into--
>> KIRK NAHRA:
Well, we have to be a little careful there because we didn't say “couldn't”. I mean, I would have said couldn't, I think they should be in person, but we didn't want to go that far. We didn't want to say if you can't show up in person you have to show up in person. So we have to play with that. John’s point, that's a fair one, “untethered” was the word we've been throwing around, but I agree that's not-- I didn't know what that meant before we started the discussion, so-- all right, was there a second point? You said you had two I thought.
>> JOHN LOONSK:
The other was about voice recognition.
>> KIRK NAHRA:
All right, so are people okay with that approach? We will have essentially a two-- it will be two points on these no relationship PHRs. In person is an appropriate mechanism, we're exploring whether there are additional mechanisms that will be appropriate for identity-proofing in that situation.
All right, any objections to that? Last chance.
>>:
Nope.
>> KIRK NAHRA:
All right, we will be sending around some language on that, hopefully for a just circulation by e-mail sign-off.
>>:
Can I ask a question? How are we going to-- what's the next step in this?
>> KIRK NAHRA:
We have to finish the dialogue.
>> STEVEN DAVIS:
I understand that. Because in my own mind, I don't know enough -- to me what we're talking about is deep data mining, how effective is it, how protective is it, and I don't know enough, sitting here. to answer that question. My sense is that no one does, that's why we're struggling. Are we in a situation we can get testimony, information, empirical information, something?
>> KIRK NAHRA:
I think what we need to do is we need to finish this letter, and then the discussion, the next discussion was next steps. And we may now have redefined our next steps, although again, we've got to figure out how to deal with that. But that's an open question.
We were scheduled to take a break a long time ago. Can we take about-- why don't we say 10, and try to really be back then so we can get going.
All right. Thanks everybody, we'll be back in 10 minutes.
[break]
>> KIRK NAHRA:
All right, we are back, ready to keep plowing through our letter. What we'd like to try and do in hopefully the next short period of time is finish up the last couple of recommendations. These are recommendations that have not for the most part had much evolution over the last couple of times we've looked at this, so I'm hoping we won't have a lot of trouble with them.
Let's start with --
>>:
Are you insinuating we're troubling if we come up with something?
>> KIRK NAHRA:
Trouble getting through them.
>>:
A little guilty feelings?
>>:
I'll get it over it.
>>:
Recommendation 2. For the purposes of secure messaging and accessing data through a PHR or EHR, documents and the information therein or other information used solely for purposes of identity-proofing a healthcare consumer or their authorized proxies, if kept, should be securely maintained separate from the healthcare consumer's clinical data. Questions, comments on this? Again, this has been, I think, untouched in the last several evolutions.
>> THOMAS WILDER:
Yeah, this is Tom Wilder, and I apologize. I still have some problems getting my arms around this. And I know we've talked about this in great length, so let me just throw this out to everybody.
So I go into my doctor's office, and they authenticate me, they've set up a really nifty PHR for me with some basic, you know, registration and medication information, and they also have collected my-- let's say, they've collected my insurance card with my insurance ID number, and maybe my driver's license number.
That's all electronically on the system. So what do we mean when we say it's got to be kept separate? Or am I misunderstanding what we're talking about here?
>> STEVEN DAVIS:
I understand your question, Tom, this is Steve. The intent of this to say it shouldn't be part of the clinical data exchange. Does that make sense?
>> THOMAS WILDER:
What do you mean by clinical data exchange?
>> STEVEN DAVIS:
So that if the information in your-- for healthcare purposes, to treat, is exchanged, that ancillary information that was part of the identity proofing, that was used solely to identity-proof should not be part of information used to treat.
>> THOMAS WILDER:
Okay, so if you need, again -- I apologize for my slowness here, but just to try to flesh this out a little bit. So if you need to share information in my record with a specialist, you're going to send that information, but you may not necessarily-- you wouldn't send my--
>> KIRK NAHRA:
Driver's license.
>>:
Right.
>> THOMAS WILDER:
Because what got me thrown off here, because you do talk about storing.
>>:
That's not-- again, reading the recommendation raw, that's not what I read at all. I had this exact same question, this was about storing.
>>:
Well, I think the genesis is we don't want physical hard copies stored with the clinical file. This was Pam Dixon's concern, it makes it--
>> THOMAS WILDER:
Well, I guess I'd offer a couple of comments. One is we're talking about electronic records here. And two, if there's a problem with somebody, let's say it's a paper record, you know, my doctor's office, if there's somebody-- problem with somebody flitching it out of my clinical file, they're probably going to have access to get it out of -- have access to the other file, as well, so--
>> STEVEN DAVIS:
Except what you're scanning into an electronic record.
>>:
Right. I think it just, my point was it came up initially in a physical file but she was raising it as an issue with electronic files, as well, that you wouldn't want these types of information to cross-pollinate, necessarily.
>> STEVEN DAVIS:
And that's where we have the “if kept”, and part of the genesis of that was it's a bad practice to keep them.
>> THOMAS WILDER:
But I think in our last conversation, though, we talked about the fact that there might be pieces of data that you would use to identify somebody that you would also use for clinical purposes, and you didn't want to exclude that. So like the insurance card data, for example.
>> STEVEN DAVIS:
And that's why we have the “used solely for the purposes of identity-proofing”, there's that one minus--
>> KIRK NAHRA:
Should we say something specific about that disclosure part? I mean, I agree it doesn't say -- “securely maintained” does sound like storage. And I think the point is, if you keep it separately, you won't communicate it to other people. But why don't we say that more directly? I mean, why not-- you know. Basically, we don't want that-- I guess language we were using earlier, we don't want that pushed out. The driver's license information, or your Social-- you know, shouldn't be pushed out. Unless there's some specific, affirmative reason, but there's hardly ever going to be that reason.
>>:
Information necessary--
>> THOMAS WILDER:
Some of this wasn't, isn't that really--
>>:
Another term to try to avoid using.
>>:
It doesn't apply to disclosure to healthcare providers for treatment.
>>:
Good point.
>>:
Somewhat frustrated.
>> KIRK NAHRA:
I'm not sure we want to eliminate “securely maintained”, I would add the disclosure part. --
>>:
Okay.
>> KIRK NAHRA:
Should be securely maintained--
>>:
At the end.
>> KIRK NAHRA:
And not disclosed, does that mean anything? Yeah. Disclosed in information exchange, or something like that? Well, does that concept get to your concerns? Again, we can fiddle with the words.
>> THOMAS WILDER:
Yeah, I mean, again I guess I'm still having trouble-- because this file is electronic, all the information is kind of together. So I'm having trouble how you maintain something separately if it's in an electronic file and it's kept all together on the same--
>> KIRK NAHRA:
Separately maintained-- if reasonably possible, or something like that. I don't want to get hung up on--
>>:
I think it is the case from a legal perspective that where institutions might actually experience liability for failure to appropriately identity-proof, that they might actually get in the practice of keeping the information upon which they rely in order to identity-proofsomeone.
And either they'll keep it in a paper format or they'll take the paper copy and scan it. And it is possible, technologically, to segregate what you bring in electronically. And so all we're saying is this shouldn't become part of the clinical record just because it's used to identity-proof you. Does that make sense?
>> THOMAS WILDER:
That makes sense if you describe it that way. In this recommendation 2.
>>:
But that does make the assumption that your systems have that ability to do that. Separate--
>>:
Is there a system that doesn't?
>>:
Right. Our computers are pretty low maintenance, but we can scan in a fax and turn a PDF into it.
>>:
The segregation part, not the scanning part.
>>:
Well, then you can't file it.
>> THOMAS WILDER:
And what do you mean by that? Do you mean keeping a copy in a separate area of the software, so that it is not automatically produced when someone prints out a copy of the medical record, for instance, to send to a specialist?
>>:
I think that would qualify based on the language that's here currently.
>> STEVEN DAVIS:
How proscriptive do we need to be on this?
>> THOMAS WILDER:
Does Medicare need to build a new data center?
>>:
I think that separately allows, provides leeway for how that's done. It can be a separate file, it could be a separate database, it could be--
>>:
And keep in mind this is information that is collected solely for the purpose of identity-proofing. Not that, as David pointed out, not information for Medicare's purposes, which you would have and use regularly for a whole host of other purposes, like the Medicare number, like the Social Security number, date of birth, et cetera. That's why the word solely is in there.
>> STEVEN DAVIS:
So only transfer--
>>:
And not disclose? You don't need it?
>>:
Well, I don't think it addresses the initial question.
>>:
Yeah, his comment was about where you keep this information, and whether it can in fact be segregable, and why you would do it, not about--
>> KIRK NAHRA:
All right, with the explanations we've had, are people okay with the language as written?
>>:
The only reason to introduce the notion of disclosure is, you know, that very upsetting Wall Street Journal article that came out the day after Christmas where this woman is still trying to get her healthcare institutions to disaggregate the information that she felt should not have been included in her medical records, and has so far been unable to do that. So, you know, several years after the fact.
So if we're talking about keeping it separately, and then preventing, you know, further propagation, of this being commingled. Then this may be an area.
>> THOMAS WILDER:
That's really-- that's an artifact of a different issue.
>>:
Well, I understand that, but it could equally as well happen in this case.
>>:
I understand the point of keeping things separate are so that, you know, it makes it more difficult for somebody who might try to steal one type of information get at the other type of information. I'm assuming that's really the basis for this.
>>:
You can be much better at identity theft if you have more information.
>> KIRK NAHRA:
And in particular, this kind of information.
>> THOMAS WILDER:
Or if all of it is in one place. So--
>> KIRK NAHRA:
I think, again, part of the problem is that we're viewing this, I think, originally from a medical record perspective. And if I have, you know, x-rays of my foot in the medical record, it's hard to commit identity theft. If you have my name, address, Social Security number and driver's license picture, it's much easier. That was the premise, that was the premise of the testimony we heard, and that was the premise of where this recommendation was going.
So let me go back to my question. Recommendation 2 as written, do people have concerns about that as written following the discussion we've had?
All right, moving on to recommendation 3, then. Converting-- well, I won't read this, but this is essentially if all you're doing is converting paper to electronic, you don't have to identity-proof. However, when you start to provide patients with access to data in that EHR, then you go back to our recommendations number 1 on identity proofing.
Questions or comments on that recommendation?
Again, this was designed I think to address at least CMS's concern, maybe others, that they were taking existing records and turning them into electronic records. Any questions or concerns about this one?
>> PAUL FELDMAN:
Whether we should expand it to be-- I didn't think of this when I first read it-- where this conversion also provides patients with access to data or where it could be pulling data from other sources. I mean, if we're pulling data from--if a provider is pulling data from other sources, that provider wants to make sure that the person is who they claim to be.
>>:
They're pulling data from like a PHR.
>>:
Or from another provider, I mean if it's a physician's system.
>> KIRK NAHRA:
Is that authentication or identity-proofing at that point? That's making sure that you're the person who put the record into the other--
>>:
That's implied identity-proofing.
>> JILL DENNIS:
This is Jill Dennis. We're talking specifically here about converting from paper to EHR, and just personally I'm not aware of any conversion process that would do more than converting what you already have to another form. I'm not sure that anybody is doing pulling as part of their conversion process.
>> KIRK NAHRA:
What this says is pure conversion doesn't require any identity-proofing.
>> JILL DENNIS:
I know.
>> KIRK NAHRA:
And then we've got that next step. Paul is basically saying we need to have other next steps identified. Maybe we'd make that more general, and say adding any new information requires-- is that sort of your concept?
>> PAUL FELDMAN:
Yeah, or pulling data from a third source, I mean, if I’m a physician, and maybe this just doesn't exist, but if I'm a physician that now converted to an electronic system and I now have the ability to pull data from multiple sources, I want to make sure that the person I'm treating is in fact who they are before I start requesting information.
>> KIRK NAHRA:
I mean does a physician just do that independent of treating me? I mean, aren't I in there to be treated and then you have to figure out who I am?
>> STEVEN DAVIS:
This is Steve. I think that's a different recommendation, that this recommendation as is stated right now just says my doctor has converted to electronic records, I want access to my record. I have to follow the recommendation number 1. It doesn't get at what other capabilities the provider now has because they're electronic.
>> THOMAS WILDER:
This is almost a redundant recommendation, and perhaps a footnote or amendment to recommendation number 1 would be sufficient.
>> KIRK NAHRA:
Well, the concern which again a number of people expressed earlier was they wanted to make sure that if all they were doing was-- I mean, it was the first part of that sentence that was responding to a specific concern that was raised by a number of Workgroup members, which is just conversion of records. So in that sense we want to be very clear that you don't need to-- you know, you can convert your records anytime you want.
>> WILLIAM CRAWFORD:
But my point was that that could be confirmed in perhaps the context of recommendation 1. As opposed to being a third recommendation. It doesn't really recommend anything new.
>> KIRK NAHRA:
My suggestion is to keep it as a recommendation, because we've got those two points, and one is-- yeah. They're both open issues today, I suppose. Does anybody have any objection to keeping it where it is?
>>:
Nope.
>> KIRK NAHRA:
Anyone have any concerns with the language at this point?
>>:
I think the only thing that I would suggest, and this goes along with Paul's comment, is to maybe just end the recommendation after sentence one. Because we have a lot of scenarios beyond that where we would want folks to follow the schema in recommendation number 1, and by just mentioning one here, really you know, that suggests that there's a whole, potentially a universe of other activities that would be permissible. Where we've just spent a lot of time setting forth what we think our recommendations for identity-proofing in the other breakthroughs --
>> KIRK NAHRA:
Again, what this says is converting from paper to electronic doesn't require identity-proofing. However, where this conversion also provides access.
>>:
Right.
>> KIRK NAHRA:
Is there another situation where conversion of existing paper records-- I'm not sure those scenarios exist. I mean, pushing and pulling is not conversion of paper records to electronic.
>>:
It's all a part of the same process.
>> KIRK NAHRA:
But it's not paper records.
>> JOHN LOONSK:
Sharing it with another provider.
>>:
Yeah. You're assuming that everyone will think of conversion in the exact same way, which is a flip of a switch, and that's it.
>> KIRK NAHRA:
I don't know how you can convert someone else's electronic records and fit it into a converting from a paper-based to an electronic --
>>:
I don't substantively have an issue, I just worry because we're sort of starting to take on some exceptions, but not a universe of exceptions. I'm not sure why we even need that second sentence, is all I'm saying.
>>:
I agree. I think that's--
>> KIRK NAHRA:
Okay, well, here's why that's there. It's there because what if your conversion involved providing access.
>>:
Because conversion can involve a lot of other things.
>> KIRK NAHRA:
Right, but the other suggestion is you stop here, you stop after the first sentence. Does somebody read that and say if I convert and provide access at the same time I don't have to do anything. Can you read it that way?
The reason we added that was we were concerned that it could be read that way. That someone who would convert to an electronic record-keeping system and at the same time make that available to patients, and we didn't want them to do that without identity-proofing.
>>:
Until such time as patients act-- something?
>>:
Then I would just clarify that all we're talking about, with respect to sentence 1, is simply, you know, a mere conversion, a flip of the switch conversion-- and maybe that's just not the right way to do it, but again I still-- like we've got one-- we identify one particular way that conversion could be beyond just the flip of a switch.
>> KIRK NAHRA:
How about “where conversion adds any information to the existing records or provides any access would require identity-proofing”.
>>:
Right, I would just say where conversion moves beyond whatever we say above. You know, then you have to see section 1. I mean, I think it's important to point out that it's not okay for them to stop there. If there's something that comes beyond that, I think we can describe whatever comes beyond that as being more general, so as not to just raise one--
>> KIRK NAHRA:
How about this? “However, where this conversion also provides patients with access or incorporates new information from other sources. “
>>:
Or involves sharing information with other sources. Pull in, push out.
>>:
How about just exchange of information.
>>:
Exchange of information.
>>:
That's good.
>>:
That's fine.
>>:
Or incorporates interoperability with other systems.
>>:
Doesn’t have to be interoperable.
>>:
Don't we want to say other data?
>> KIRK NAHRA:
Yes. From any data, it doesn't have to be other data-- I mean if it's a paper-based --
>>:
Now you're saying if one doctor would have faxed another doctor a piece of information from the patient's record and now they're in the electronic world, and they want to electronically send the exact same information that they would have sent in paper form, they can't do that without identity-proofing the patient?
>>:
How about exchange of data with an EHR?
>>:
I think that's what you're saying.
>>:
Doesn't that set up a--
>>:
So-- okay.
>>:
This gets back to patient access. To their data. So that's what we need to keep the focus on I think, too.
>> KIRK NAHRA:
But Deven's point as I understand it is there's no reason that that's the only thing we should talking about. I agree we did talk about that, but should there be other situations where we have the same kinds of concerns.
>>:
I go back to your point, I think we could take out-- again, however, because the recommendation already assumes 1, if you go back and look at 1, 1 is already saying if you give access, we want you to follow these things, 1.1, 1.2, 1.3.
And so we are already saying that piece of it -- this is redundant to what we've already said in recommendation 1.
>>:
You could always say nothing affects recommendations 1 over this.
>>:
Yeah, I would just refer people back to recommendation, without necessarily-- I think we're just making it explicit. That there's something beyond that.
>> KIRK NAHRA:
Go back to-- who was-- somebody was asking about disclosure of information to another provider. We haven't addressed identity-proofing in that sense at all.
>>:
Of providers, right.
>> KIRK NAHRA:
We haven't really talked about identity-proofing trusted sources.
>>:
I think that's why this is talking about patient access, because it's basically referring to what recommendations we’ve already made with respect to patient--
>> KIRK NAHRA:
I was going back to recommendation 1, which says that entities that offer healthcare consumers or their authorized proxies electronic access to data or services. So that would require somebody to read this and incorporate it in a way that just means they've read it 20 times and figure it out, but it doesn't say anything about-- I mean, number 1 doesn't say anything about provider one sharing with provider two.
>>:
Correct.
>> KIRK NAHRA:
So if provider one is going to convert and then start sharing with other providers, do we need to say anything about identity-proofing the patient?
>>:
No, unless we're going to change our background, because we've talked about patient identity-proofing here.
>> KIRK NAHRA:
That's what I'm saying, do we need to identity-proof the patient when information is being exchanged between providers?
I agree we don't need to-- I agree we haven't yet talked about identity-proofing the provider, but do we need to identity-proof the patient when information is being exchanged--
>>:
That takes us down that rocky road of talking about how do we find out whether that provider is now a trusted source who has done identity-proofing on the data that they have in there? Before we receive it from them?
>> KIRK NAHRA:
The reason I'm asking that is Deven's initial concern was that there are a variety of other things beyond just patient access that link those paper records to other things.
Is that a fair paraphrase of what you were saying?
>>:
Yes. But is that a privacy and a security concern, or a data integrity issue?
>>:
Both.
>> KIRK NAHRA:
Well, I guess my question is are those other examples, Deven, things that deal with provider exchanges, and therefore really not what we're talking about?
>> DEVEN McGRAW:
My concern was that we hadn't really fleshed out the universe of what sort of beyond conversion we would or would not want to accept.
And so I'm not sure, and maybe there aren't any, but by just mentioning one, however, we've sort of-- we're suggesting that that's the only one we're worried about. And I just don't know if we've-- notwithstanding that we've talked about this an awful lot, and--
>> KIRK NAHRA:
I guess my question is-- I mean, I think it's fine-- I mean, there are a couple of suggestions on the table. One is to eliminate that sentence, and by eliminating that sentence hope that people sort of cross-reference back recommendation 1, that says when you give people access you've got to identity-proof.
I'm not sure that's-- I'm not sure that will be obvious to anyone. So we can eliminate this sentence, and assume a cross-reference, we can eliminate this sentence and replace with it a cross-reference, we can keep the sentence, or we can try to figure out if there's anything else on that list, or is it just the possibility that there might be something else we're--
I'm not sure that there's anything-- if you go back to what recommendation 1 says, I'm not sure there's anything else in what we're describing other than patient access. Because that's what recommendation 1 talks about. If you give patients access, you've got to go through these identity-proofing stuff.
So if there's some other device, I'm not sure recommendation 1 even deals with it.
>>:
If it surfaces that there are other examples we could certainly deal with them in future recommendations, right?
>> KIRK NAHRA:
I agree.
>>:
So I guess for right now instead of wracking my brain to think of an example I would rather leave it as it is, and then cross that bridge when we come to it.
>> KIRK NAHRA:
I like it the way it is, and I like it better than the cross-reference. I think it's clear, it's just saying-- you know, we're basically making an exception to number 1 which is if all you do is convert you don't have to do any of this stuff. But if you give them access, you need to identity-proof.
>>:
Does it help if you get rid of however? So it's not suggesting that's the only exception? You say converting doesn't require-- conversion as provides access does require, and it doesn't make any statement about anything else.
>> KIRK NAHRA:
All right, is everyone all right with that one modest change?
>>:
I didn't think it was modest.
>>:
Insightful, brief, perfect, but not really all that significant. How about noncontroversial?
Last chance, any comments on 3? Number 4. Recommendation 4. Entities that provide patient access to personal health information via secure messaging or a PHR should follow the identity-proofing recommendation schema noted in recommendation 1. I'm sure there was a good reason for having this, but I can't remember.
>>:
-- in EHR, the goal was to have a companion recommendation, as I recall, for secure messaging and PHRs.
>>:
Okay.
>> KIRK NAHRA:
Any concerns with number 4?
All right, number 5, Steve, I notice you have some red lining on this.
>> STEVEN DAVIS:
Yeah, we had an amendment on the floor, I guess you call it.
>> KIRK NAHRA:
Has that been circulated or not?
>> STEVEN DAVIS:
No.
>> KIRK NAHRA:
All right, let me read you the proposed change to number 5. Where applicable at the beginning. So where applicable, the Certification Commission for Healthcare Information Technology, C CHIT -- is that the way you say it?
>>:
They like C-C-H-I-T.
>> KIRK NAHRA:
C-C-H-I-T, all right. I'm going to suggest amending that. Now, should develop certification criteria for the systems and networks they certify to support the identity-proofing practices in these recommendations.
>> JODI DANIEL:
And the rationale-- this came from one of the Workgroup members-- the rationale for adding “where applicable” is that identity-proofing, some of these might just be business practices, and may not be suitable for certification criteria. So just making it clear that we're not anticipating that they will necessarily have criteria for identity-proofing, it may be that they're just business practices and not system requirements, but that they should support the recommendations where appropriate.
That was-- that was the rationale for the language change.
>>:
Is CCHIT charged with developing certifications in any other area, or do they just apply other certifications of entities to make sure they meet the criteria?
>> JODI DANIEL:
They will be developing criteria for electronic health records, both ambulatory and inpatient, as well as for networks in future years.
>> KIRK NAHRA:
All right, anyone have concerns with number 5?
>> THOMAS WILDER:
Yeah, this is Tom Wilder. I guess I was-- again, I was having a little trouble understanding CCHIT's role in all of this, because it seemed to me what we've laid out are some-- some kind of principles or business practices that are very good. But I was-- I was having difficulty figuring out how CCHIT would incorporate that into what they're doing, because it seemed to me they're going off of existing standards that are out there in the market, or whatever HITSP may develop, as opposed to kind of business practices.
>> STEVEN DAVIS:
This is Steve. I think part of the reason why we put them in here is because of the option 3, in recommendation 1, and if there were standards developed-- and this gets to why we put in “where applicable”, and how all that would coalesce in terms of if there were standards, or if there are standards out there that need to be harmonized with regards to identity-proofing through some electronic means, that CCHIT could-- you know, if they had enough material to create criteria, to certify systems that would use that standard.
And obviously, you know, it would probably be involved in this whole thing.
>> KIRK NAHRA:
Let me ask a slightly different question. Are they the right organization to figure out that issue we spent all our time discussing, which is what public data sources would be the right kinds of data sources, or is that not what they do?
>>:
I don't think that's what they do.
>>:
Too bad. (Laughter)
>>:
Nice idea.
>>:
It would be nice to be able to punt to somebody, rather than just punt.
>>:
It could also apply in the storage scenario. If you're talking about an EHR having the capability of storing the identity-proofing data separately, that is a system capability that they could have a criteria on, and a security criteria for example.
>> KIRK NAHRA:
All right, so with all that explanation any concerns with number 5?
>> THOMAS WILDER:
My preference would be to strike number 5, but since you're putting in “where applicable”, I think that would take care of my concerns.
>> KIRK NAHRA:
All right, any other concerns with number 5?
>>:
Do you have the words for the rest, number 1?
>>:
Are we going to do it offline?
>> STEVEN DAVIS:
I've got Kirk's notes for number-- you know, recommendation 1, 1.4, and 1.5. We'll take it offline, we have all the contexts that we need to create a --
>> JODI DANIEL:
Yeah, I think we have enough decision on what the Workgroup wants to do, we'll play with the language to make sure we're capturing it appropriately, we'll send it out by e-mail, and then it will get presented at the AHIC at the next public meeting, so it will have opportunity for discussion at that time as well.
>> KIRK NAHRA:
Now on to the fun part, right?
>>:
It will be presented by Paul.
>> JODI DANIEL:
So can we declare this letter, with the caveat that we will circulate language on 1.4, a new 1.4?
>> KIRK NAHRA:
We can declare this letter almost done. It’s where it’s been for awhile. All right, so let's move on to the next agenda item that was supposed to start at what, 2:30?
>>:
2:15.
>>:
Were we going to have you guys summarize is that--
>> JODI DANIEL:
Yeah. Steve do you want toexplain --
>> KIRK NAHRA:
Here's the goal of where we want to go next. We want to talk about our next steps for this group. And obviously we have an addition to that list based on the results of our discussion of that letter-- actually, before we get-- let me start with that, which is it seems to me after we've come up with the language for the letter, why don't Paul and I sit down with the staff and try to figure out a game plan as to what we want to do with that next issue. With an eye towards moving it along, but not having it bisect everything else we want to try to do.
>> JUDY SPARROW:
You mean the 1.4 issue. The punt issue.
>> KIRK NAHRA:
Right. Does that make sense? We've got to come up with a laser beam attack on that one, right? I mean, if people have any thoughts why don't they-- you know, have any particular suggestions, whether it's witnesses or types of witnesses or information they'd like to see.
>> JODI DANIEL:
You can also ask for the public to provide written testimony, if you want to consider that, as to what people--
>> KIRK NAHRA:
Let's just say for the Workgroup people if you have any suggestions that we could add into our discussion, please send them along to us, and we'll try to meet as a small group and then get something back out to the bigger group.
>>:
It seems to me that at least partially it's a conversation about trusted third parties. And I'm wondering, I'm sure there has been work done in this area. And I'm sorry that John isn't here still, I thought he would have something to say about this.
So I guess what, I guess, Steve, maybe one of the first things might be to just kind of check around and see what we might have in-house there. And I have a couple things to check, too.
>> JODI DANIEL:
We can also check with other staff support for this Workgroup to see what else people can dig up, even if it's not-- you know, ONC or HHS work that's been done, there might be some other sources we can pick from, or the other Workgroups.
>> PAUL FELDMAN:
Once we know what the landscape of trusted third parties is a little bit more, that might suggest a course of action for this.
>> KIRK NAHRA:
Well, and frankly, one of the things it might do is if we have enough applicability of trusted third parties that might push us towards the recommendation that says you've got be in person somewhere. That may be a possibility, maybe it's not.
I think one of the difficulties in just the discussion I was hearing before, was what some of those third-party data sources may be using today to confirm identities are not things that we necessarily feel comfortable with them using.
>>:
This is the example from the testimony that we heard from the financial sector, you know, trying to convince us that -- they maybe convinced some, I don't know, but that they do this quite successfully in the financial sector, and so we know all the-- you know, the analytical framework, and we can make this happen in the healthcare world, as well. But I don't think that-- I think there's a lot of people who don't necessarily believe that application of those data to the healthcare sector --
>>:
Let me just if I can--
>>:
Things are hard in healthcare, too.
>> KIRK NAHRA:
It's harder for us to say we'll take a five percent loss.
>> JODI DANIEL:
So what I'm hearing is as far as work plan next steps, that we'll do some background work, and look for Workgroup members to give feedback on information sources that are out there about trusted third parties for purposes of trying to hone in on 1.4, what will be the 1.4 punt. And that would be the first thing that we would start back up on at our next meeting.
>> PAUL FELDMAN:
Which was intended to be probably a half day of hearings, and then a half day of deliberations.
>> JODI DANIEL:
Correct.
>> KIRK NAHRA:
I'm not sure I want to say that's our next thing only because we need to have an approach for that.
>> JODI DANIEL:
Right.
>> KIRK NAHRA:
Maybe that we put it parallel, maybe that we-- you know, I'm not sure what I'm saying(indiscernible) direction
>> JODI DANIEL:
But it sounds like that's a priority in the next year that we're going to actually try to address this 1.4 punt.
>> KIRK NAHRA:
Right.
>> JODI DANIEL:
So that will be on the list.
>> THOMAS WILDER:
This is Tom Wilder again. I know the Consumer Empowerment group, when they meet, in their letter they've got some issues that they want us to consider. I think they're looking at those, and I guess my question to the staff is are any of the Workgroups coming up with some things that they'd like us to take a look at that should be moved up in the queue?
>> JODI DANIEL:
Consumer Empowerment is the one that I know of, they were talking about protecting information held by PHRs, you know, privacy policies for personal health records, and they were also talking about, at least in their draft recommendations, issues regarding access to information using a PHR.
Those are the two things that I'm aware of that are coming out of other Workgroups, although I'd open it up to other-- ask other folks who are members on any of the other Workgroups to--
>> KIRK NAHRA:
To put it this way, I suspect we will not conclude today, in the next half an hour, our discussion of our full next work plan. I think-- don't we have to save time for members of the public?
>>:
15 minutes. We can go to 4:45.
>> KIRK NAHRA:
We're talking about less than a half hour to have that discussion, so I don't think we're going to finish that discussion today. So we can also factor in and maybe even reach out to some of those other Workgroups as well, as to what they want to put in.
Steve, do you want to start off talking about some of those discussions?
>> STEVEN DAVIS:
Sure, just briefly since we don't have a lot of time anyway, just to catch everybody up to speed, since our last meeting was November 13th. As I'm sure everyone can imagine, we feel that edits to the recommendations document concurrently with sending out with just a blank template to ask members to prioritize the topics and issues they'd like to have us discuss at that 2:30 time frame today. And generally we just got a clustering of issues I would say in no particular order. The first one being I wouldn't call them secondary uses, but other uses of data and consumer rules with relation to them. With regards to how they would be used in the context of PHRs or exchanged through the NHIN and RHIOs. The next was how to deal with possible noncovered entity issues and PHRs and the like. Privacy practices, and specific principles for noncoverage situation.
And that's, I think, part of that we heard from the Consumer Empowerment Workgroup.
The next was continuing on identity-proofing, there were a few good responses, people wanted to go into providers, people wanted to delve deeper into what third-party issues there would be. Also methods for identity-proofing facilities and organizations that, you know, lend itself more to that federated identity conversation that we took off the table awhile ago.
Authentication, which is kind of the next logical step in all of this discussion, both provider and patient authentication. Access to information, policies regarding transfer of data to and from PHRs, consumer rights to information, role-based access, and how to appropriately limit need-to-know access and different types of technology.
And then finally, just policies for breaches and consumer protection, and auditing, and education, and outreach to inform people about that. So that's the run-down of where people clustered, and those are the responses. So that's just a quick feedback of what we got from people.
>> KIRK NAHRA:
And everyone has circulated a group of criteria, which frankly don't have to be the only criteria but just different things we were looking at. So, I mean, I think our sense is, you know, we want to talk about, you know, both a short-term and a longer-term agenda, we want to focus on issues that are going to be reasonably significant, we don't want to focus on things that, you know, we don't think we can get through.
I think a lot of it is going to-- you know, one of the things we want to talk about both today and in the future, should we be trying to-- the identity-proofing piece was a sort of a small piece we thought was going to be easy to bite off and chew and get through. I think despite the difficulty we had getting through it, I think it was a relatively discrete component. I think one of the issues on the table is do we try to address some of the bigger-picture policy issues, or do we try to pick other issues like identity-proofing that again are pieces of the whole that we can try to get through.
Paul, do you have any thoughts before we sort of open it up to the group?
>> PAUL FELDMAN:
I have a lot of thoughts about all of this, I've been trying to make sense of this. And I think actually one thing that would be useful is just to reflect back on what we've done with these recommendations.
First of all, what we thought would be-- well, I shouldn't say that. What was discrete, what we thought would be discrete, is. I mean, we were fairly successful at-- we had to refocus, but we stayed there, I think, which was really good.
I think that in terms of them being-- the recommendations being impactful, it raises one of the big-- it raises a large issue that's emerging, which is what are we going to do about-- you know, is there something to do that isn't in-person identity-proofing. It is an issue in the industry and in the community.
And what we now sort of self-created is some followup work with that, and there's a logical next step around authentication which is huge issues, and we-- Kirk and I have had conversations with staff about the idea of finding a piece of authentication that, if we choose to take it on, that we can wrap our hands around.
But I will also say that there are fundamental, foundational privacy, confidentiality principle stuff, that this is the place to take it on. And I think we get to it sooner or later no matter what choices we make, to some degree.
So there's that, and then the final thing, sort of like this is my little Rubik's cube of this, is the kind of focus from many, many points on to PHRs. That there's a lot happening, they're not-- you know, if they're not attached to covered entities there's no-- you know, there's a patchwork, if any, of protections and rules.
So there's probably a lot of external interests in tackling some of that.
>> KIRK NAHRA:
Well, let me just make a couple other comments. I mean, the authentication issue, again, as Paul said, is a very logical one. It also is something that's very quickly going to turn, I think, pretty technical. And it may be that we want to focus our attention on recognizing the vagary of these terms, what I would call policy issues more than some of the detailed standards. And again, that's a factor.
I think we're also seeing from some of the other-- both the Workgroups and some of the sort of industry groups, are they really are struggling with some of these sort of front-end policy issues. And on the one hand, it may be that some of the core policy issues end up at the end of the day being-- you know, political issues, more than stuff for this Workgroup, but I guess one of the things that I've thought about is to try to frame some of the big picture issues in terms of what would the impact of particular choices be.
For example, I-- you know, the things that I have read on EHRs and PHRs and the national health network, and all that stuff, is that the primary goals are designed to, you know, improve medical outcomes and reduce administrative costs. One, is that a correct statement? But put that aside. If that's the case, what would be the impact of some of the choices that we could make or recommend in terms of consumer consent, authorization, ability to pick and choose what goes in, what goes out, who it goes to. I'm not sure that-- you know, the policy issue is what are we going to recommend about that. Are we going to have a consent environment, are we going to have something else, opt in, opt out?
But I'm interested, at least in the first instance. of figuring out what the impact would be of some of those choices, and I could see, you know, a hearing that's structured around if we set up this kind of a system, here are the pros, here are the cons, here's what would happen if we do this.
Which, I think, helps us move forward on some of these issues, maybe frame the issues a little bit, even before we get to the real hard -- and that's not necessarily making a choice, but it's understanding what the options are. So again that's sort of the variable that I've looked at. The other one I suppose is a big picture variable, again could be suited for a hearing very easily, would be is this situation, again, the electronic records and particularly the integrated network, really different, or different in any particular way, from the HIPAA environment.
You know, we've talked a lot in this group about not wanting to-- you know, redo the HIPAA wheels. One of the things Paul mentioned was well, PHR has lots of people that aren't in the HIPAA structure. Okay, clearly, clearly different -- that maybe our recommendations end up going to people outside the HIPAA system. But for records inside the HIPAA system, is this really different, is it something that we should be talking about having different policies and procedures. So again, those are some of the sort of overarching issues I've thought about. We can address those sort of each time they come up, or we could try to address those as bigger-picture issues again, to try and get a sense of choices, options, impacts of different choices.
So with that sort of big background, why don't we take a few minutes, if people have-- do people have particular thoughts on what they'd like to see next, things they'd like to see us avoid, you know, anything like that? Let me start with the people in the room.
>>:
I think the issue of non-HIPAA, non-covered entities has the potential of being a big issue. And has the potential of taking what the patient population would assume to be protected under HIPAA outside of the covered entity realm very quickly.
And I'd like to see us address that and flesh that out.
>> KIRK NAHRA:
Now, on the one hand -- I think that's clearly going to be an important issue. On the one hand, in some ways we could also say it's a very easy issue. I think that putting aside my question of is it different, you know, do we want different standards from HIPAA, I think we very easily could come to a conclusion that says you know, we've got to do something with these people, we've got to have some-- a recommendation is that there be--
>> JOHN HOUSTON:
This is not a trivial issue, I can tell you from NCVHS internal work on it.
>> KIRK NAHRA:
I'm sorry, I didn't hear the start of that.
>> JOHN HOUSTON:
This is John Houston. This is not a trivial issue because I can tell you NCVHS has been trying to work on it, and this is really a weighty issue we’re going to have to deal with.
>> KIRK NAHRA:
I understand it's not trivial, but which part, what do you mean? You're struggling with an answer, or what--
>> JOHN HOUSTON:
What the right standards should be.
>> KIRK NAHRA:
Okay. Again, the way I look at it is should there be standards for these people, and what would be the impact be of having them be the same or different from other people?
>>:
Well, I think you'd to have look at the authorities that are built into HIPAA, and they were all written specifically for covered entities. And you can't really apply that directly over, so there are going to have to be some unique considerations made for non-covered entities, and how they use that information, how they're able to disclose it, what they're-- I think some of the technology recommendations that come out of the security rule, for example, are going to be transferable. But some of the other things aren't going to fit one-to-one.
>>:
They're not doing treatment and payments, so those wouldn't be very good.
>>:
Or healthcare operations.
>>:
Okay.
>> KIRK NAHRA:
Other-- just people's reactions at this point to what they'd like to see us work on? I mean, again, I think the-- the PHR and noncovered entity issue is clearly out beyond the (Inaudible), I don't know whether it's one or two or three, but it's not 25 under any scenario.
>>:
I guess I would just echo the notion that there are a lot of different entities and organizations dealing with the technical dimensions, the standards, the-- you know, a lot of different very in the weeds conversations. And I would rather, given the-- you know, sort of expertise around the table, and the, you know, broad range of groups represented, I would rather see us dealing with policy-oriented questions.
>> JODI DANIEL:
I would-- this is Jodi-- I would say that probably every issue that we have on the table has policy-related issues. And so as Paul was saying, let's assume that authentication was something we wanted to take on, we could figure out as a group, what are the policy issues there that we can then, you know, set certain guidelines so that when you do have technical folks looking at the issue, they know what the policy baselines should be.
>>:
I guess what I really-- I almost feel like in order to even draft the policy issues, you would want to have a certain level of expertise about the technical dimensions to inform that conversation, because you could end up at a different place. And I guess I just am concerned about making policy recommendations that, again, get-- you know, this is a concern I raised earlier, that it could get brushed off because it's not at all the direction where people are moving as an industry or a technical sector. And so I mean, I think if we decide as a group to tackle some of those issues, then I think we're just going to have to get a lot more testimony, or input from the technical experts, in order to make sure that we're on the right track.
>>:
To follow up on that, it seems to me that you're right, Jodi, that we can find policy issues tied to any of these points. I think I'm in the same place as(indiscernible) I wouldn't say don't do it because those aren't policy issues I would say, it's a lower priority in my mind because it's largely a technical issue, and I could see us getting very bogged down in the technical issues. Yeah, we could isolate some of the policy issues, but in terms of impact, and in terms of forward progress. I don't yet-- I don't see that one as one where the same kind of impacts would be made on the policy side.
Paul, did you have-- Deven, anyone in the room, do you have any particular thoughts on this point? How about people on the phone, in terms of issues they’d like to see us working on?
>> JOHN HOUSTON:
This is John Houston, I have a couple that I have talked to Paul about before, and there's really two. One is at some point somebody is going to need to wrestle with this whole concept of opt in versus opt out, especially as it relates not necessarily to PHRs as much as when we start to see EHRs and the like.
And then I think there's also going to have to be-- again, this is more of an EHR concentric issue, but how much consumer controls are going to be over what's in these records.
>>:
To some extent it's questioning whether HIPAA is even an appropriate paradigm. For what we currently have as HIPAA-covered entities, when you talk about electronic information. And the types of electronic information that may eventually be contained therein.
>> KIRK NAHRA:
And again, that was sort of my second of the big picture issues. Which is how, if at all, is this different from the HIPAA environment. And I think that said, that would have us look at the question of whether the HIPAA paradigm works or doesn't work. And I think that that-- you know, that could be a testimony-gathering exercise that doesn't require us-- I mean, we might conclude at the end of the day that HIPAA is bad for everything it covers, but we also could conclude no, this is the same, it's got the same issues as HIPAA, strengths and weaknesses, or it really is different and we need a-- you know, different for the following five reasons, I'm not sure what those five reasons are yet, different for those five reasons, and so we're going to come up with-- what do you call it, HIPAA plus, or just a different set of standards because of the uniqueness.
I think that would be a very good -- I think gathering that information -- is it different? -- would be a very useful exercise, the political elements of the policy debate come after that, after we gather that information. But I think we have to have that information up front in order to start really having-- and again I do think that that issue that is going to govern-- you know, pretty much, one of the differences is the presence of all these noncovered entities, clearly a difference. We're all going to agree that's a difference.
Beyond that we have to evaluate. Is interoperability something that makes it so much different from the current environment that we want a different set of rules? And I don't know the answer to that one yet.
>> DEVEN McGRAW:
I mean, it is-- it is the privacy rule on the book today, absent whatever is going on at the state level, it would be like missing the elephant in the middle of the room if we didn't deal with it, or start dealing with it, relatively quickly. Because I think that's the question on everyone's mind, because I know, when I went to give a presentation on what's going on at the federal level with health IT, I had a guy stand up and say well, HIPAA covers all of this. So I don't know what we're all worried about. Like, why does the form of the record make all that much of a difference?
So I mean, it's definitely a question on people's minds.
>>:
Well, and HIPAA does cover some things like-- that would reach out to organizations outside of that covered entity realm with the business associate concept. So there are some ways that there might be some reach. But I think to your point, we almost stifle the possibilities if we try to not challenge what some of those other things might become. And say let's stay open to this, because this may take on a life of its own, and we may lose the whole opportunity to have electronic health records, and interoperability, by trying to put it in a box.
>> KIRK NAHRA:
Let me make sure we can get through the other folks on the phone call. John, were those the points you wanted to make?
>> JOHN HOUSTON:
Which ones, the--
>> KIRK NAHRA:
You had a list, I didn't know if you had gone through your list.
>> JOHN HOUSTON:
I just said consumer control over content, and opt in versus opt out.
>> KIRK NAHRA:
That was the end of the points you wanted to make.
>> JOHN HOUSTON:
Those were the only two I hadn't heard that I thought need to be on the list somewhere.
>> KIRK NAHRA:
Okay, other folks on the phone who had issues they wanted to suggest?
>> JILL DENNIS:
Yeah, this is Jill. I would agree, by the way, with the opt in, opt out. I think that's an important question that somebody has got to start working on.
As far as the whole HIPAA discussion, I think it's an important one. I would cast it a little bit differently, though. To me the policy question is should the protections follow the data, rather than being a function of who has it. And I think somebody coming to some conclusion on the yes, but. Yes, it should, is going to open up those kinds of discussions. And I think resonate with consumers, as well.
And then you look at, well, is it HIPAA, is it an extension of HIPAA, is it something that looks like HIPAA. But somebody has got to first make that-- make that declarative statement. As to whether or not the protection should follow the data.
And I think that's really high priority. Because eventually it's going to get in the way of adoption of these systems, and it's going to lead to consumer push-back on some of these issues, and it's going to cause people to want to opt out. So I think it's a threshold issue.
>> KIRK NAHRA:
Okay. Other people on the phone at this point who have suggestions?
Matt, are you on the line?
>> MATT McCOY:
Yeah, I am. Do you want to see if anyone wants to make a public comment?
>> KIRK NAHRA:
Flash the number, yeah.
>> MATT McCOY:
Sure. For all the members of the public looking at the Webcast, you'll see very shortly when the screen refreshes there will be a slide with information about calling in and making a comment. We also have some members of the public who dialed in to get the audio for this meeting earlier. If you are already on the phone just press star 1 and that will put you through.
If the Workgroup has a minute or two of business to take care of, you can do that and I will jump in and let you know if somebody gets in the queue to ask a question or make a comment.
>> KIRK NAHRA:
I'd like to finish, make sure we've gone through everybody on our group on the call, just to make sure there are no other comments.
Are there comments from anyone else on the call at this point about particular topics they would like to see us addressing?
>>:
I have one question on what the last speaker said, this isfrom Family and Medical Counseling. The question was should the protection follow the data, or should the protection follow who has the data. I just want to verify the question that the speaker raised.
>>:
Yeah, I think that's a good report of the question.
>>:
Okay.
>> KIRK NAHRA:
Anyone else on the call who has not had a chance to give their thoughts on next steps today? This is obviously not the last chance for this.
>> WILLIAM CRAWFORD:
Again, this is Will Crawford from CMS. I just want to say that you probably will be getting some thoughts on next steps from Tony or Elizabeth
>> KIRK NAHRA:
Okay, great
>> SUSAN McANDREW:
This is Sue McAndrew. I would just also note that in trying to frame the HIPAA question, and-- we like to thing of ourselves as the hippopotamus in the room rather than the elephant in the room.
>>:
I stand corrected.
>> SUSAN McANDREW:
That aside, I mean, one aspect, at least one reality that will need to be grappled with, is to what extent do you shape your consideration of what to do with these entities and these activities that are currently outside of the scope of HIPAA, in terms of a regulatory regime or a policy regime of privacy principles there that should at least be able to live with HIPAA, or-- unless you feel that in some of these recommendations it would-- you would wind up in a world where you withdrew HIPAA entirely and just replaced everything with this new regime. And I will express some skepticism as to the ability to achieve that kind of world.
So I think we need to be dealing with some concept that doesn't wind up with covered entities being in any way conflicted or with dual sets of standards simply because they want to participate in the NHIN.
>> KIRK NAHRA:
Right. Okay. That's certainly a fair set of points.
All right, anyone else on the call from the Workgroup at this point who has comments to make?
All right, why don't we turn to the comments from the public. Are there any at this point, Matt?
>> MATT McCOY:
No, there are not.
>> KIRK NAHRA:
Okay.
>> JODI DANIEL:
So how do you want to-- how do you want to proceed with this? I mean, the original thinking was that we would, since this Workgroup is on the agenda for the AHIC meeting in January, that we would both talk about the recommendations as well as talk to them about sort of future plans. Clearly, we need some more discussion about future issues that we are going to address, a plan for that. How would you like to handle that?
>> KIRK NAHRA:
Let me suggest that we will-- you know, our next meeting of the co-chairs should be to talk about two topics, the particular on the 1.4 punt, and maybe come up with a specific proposal for the people to talk about, I think it's hard to-- you know, we gathered a lot of good information about priorities, and lists and things like that, and obviously more than people talked about today, but I think we can try to put our heads together and come up with-- you know, two or three steps next.
>> PAUL FELDMAN:
Well, except that our intention was to have something for this meeting on the 23rd, which doesn't sound like we can do. We can certainly talk about the things that have risen to the top of the list. I'm not sure how much farther we'll get.
>> KIRK NAHRA:
We need to do that as a next step, independent of what we do at AHIC.
>> JODI DANIEL:
Perhaps what we can do is what you're suggesting, at least talk to the AHIC meeting, these are the issues people are raising as a Workgroup. And you know, perhaps we can even submit something even some presentation at the next meeting. Or just send a letter to them separately saying this is how we plan to proceed. And, you know, do a followup that way. Unfortunately, Judy is not here to run it by her, but we can talk offline on how best to do that. I think we should at least try to think about how we can present-- you know, show that we've got some progress on next steps, and, you know, even if it's not finalized. And then followup.
>>:
Now, is our 1.4 punt going to continue the dialog about other trusted sources, and how we might identify them and be able to-- you know, it kind of goes into the authentication discussion, but it also goes into the discussion we've had today about how do you uniquely recognize them.
There's that flip side of it, we've talked about the patient side of it, what about the other provider side of that. What about the other organizations that are going to need to be identified and trusted?
>>:
Yeah, we'll try to pull all that together.
>>:
I think there's a lot more information about how to identify other organizations than there is about consumer identification. Is that what you mean?
>> PAUL FELDMAN:
Uh-huh. Yeah. Right. Including but not limited to the patient-- I mean, the provider identifier issue.
>> KIRK NAHRA:
Okay, check on any other members of the public?
>> MATT McCOY:
Nope.
>> KIRK NAHRA:
All right, thank you very much, everybody, for participating. It was a littledifferent than we had anticipated today, but I think we made a lot of progress, and we will look forward to speaking with you in the near future. Thank you very much.
>>:
Bye.