[Openid-specs-heart] Universal Patient Identifiers for the 21st Century

Wed Sep 2 01:34:53 UTC 2015

I would be happy to post to THCB but I am obviously not being clear and before I broadcast my inability to communicate I thought I would test it out amongst friends. J

I want to share my Voluntary ID with everyone that I encounter – I had left the OAUTH2 implied but obviously shouldn’t have done so.

Maybe I can post a question to THBC instead and try again based on your answer.

Aaron Seib, CEO

@CaptBlueButton 

 (o) 301-540-2311

(m) 301-326-6843

From: agropper at gmail.com [mailto:agropper at gmail.com] On Behalf Of Adrian Gropper
Sent: Tuesday, September 01, 2015 9:02 PM
To: Aaron Seib
Cc: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Universal Patient Identifiers for the 21st Century

Aaron - please post all compliments to the public blog:-)

As for your question, I have no idea how the Virtual Clipboard is different from any other resource server. Is the thing that makes the Virtual Clipboard different that it allows the patient to add information to it? I can do that with MyHealtheVet today even if I'm not a veteran.

Your example says that the Virtual Clipboard can gather info about me from, for example, the health insurer. It also says that I give the Virtual Clipboard my user ID for my insurer. What protects the insurer from anyone that knows my user ID at the insurer asking for my information? It seems like you're using a GUID /Voluntary Identifier as a password into my insurer account. This would certainly not be a good idea because anyone that had my GUID and happened to know my userID (usually my email) would be able to impersonate me and my Virtual Clipboard. 

In other words, the GUID Voluntary Identifier is not required in order for my Virtual Clipboard or MyHealtheVet to get the insurer info from a FHIR API. All that's needed is OAuth2. That's exactly what OAuth2 was designed to do.

I think you're missing the point of my THCB posting - surveillance. There's nothing about your question that implies surveillance and therefore there is nothing in your question that actually has anything to do with Unique Patient Identifiers. Everything you want can be done with UMA and with HEART.

It would be nice if you would post this question or the next one to THCB. There are going to be many people who would appreciate the discussion.

Adrian

On Tue, Sep 1, 2015 at 6:10 PM, Aaron Seib <aaron.seib at nate-trust.org> wrote:

Adrian,

I think this is the best thing you have ever written.  Bravo.

Thanks for sharing.  Is it sufficient to give the consumer the option to decline having a voluntary universal identifier assigned and to always get their permission before sharing it with a relying party?

Let’s say someone provides the Virtual Clipboard.  For arguments sake let’s say it is a benefite of membership for being a member of some benevolent fraternity.

You pay your membership dues and they send you a URL that takes you to a data capture screen where they collect some PII attributes – say the following:

·        First Name 

·        Middle Initial

·        Last Name

·        Suffix 

·        Date of Birth 

·        Gender

·        SSN – Last 4 digits

·        Address 1 & Address 2

·        City, State, Zip 

·        Home & Mobile Phones

At the bottom of the screen there is a save and continue button.  When you click the button a pop-up window appears and says – would you like us to add a voluntary unique health identifier to your Virtual Clipboard?  If the consumer says no – the data is captured and the field for the Voluntary Identifier is left null.  If they say an API is called to get a GUID and that is stored in the Voluntary identifier field.  

The user is then presented with an action that he can take.  Would you like us to gather your health insurance information?  The user decides, yeah – it would be a good thing to have this in my Virtual Clipboard and clicks yes.  Before making an Eligibility Request (equivalent to an X12n 270) to the payer we ask the user for the name of their insurer and their membership id.  We also ask the consumer if they would like us to share their Voluntary Identifier with their health insurer.  If the consumer says yes we send it along with the call to the insurers FHIR API which returns the EligibilityResponse resource which includes all the details about your health insurance plan that gets stored in your virtual clipboard.

A few weeks go by and the consumer need to schedule an appointment with a doctor.  Via FHIR the user is able to share the Patient Resource and the Eligibility resource with the docs EMR system.  Before we include the voluntary identifier we ask the consumer if they would like to have their voluntary id shared with this EMR.  If they say yes it is passed along to the EMR which incorporates it into their patient record along with the insurance card information needed to check if the patient has active coverage.- 

Is that essentially what you are recommending in the blog post?

Aaron Seib, CEO

@CaptBlueButton 

 (o) 301-540-2311

(m) 301-326-6843

 <http://nate-trust.org> 

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Adrian Gropper
Sent: Tuesday, September 01, 2015 5:00 PM
To: openid-specs-heart at lists.openid.net
Subject: [Openid-specs-heart] Universal Patient Identifiers for the 21st Century

I think this blog posting is relevant to some of our conversations. http://thehealthcareblog.com/blog/2015/09/01/universal-patient-identifiers-for-the-21st-century/

Adrian

-- 

Adrian Gropper MD

RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE:  <http://patientprivacyrights.org/donate-2/> http://patientprivacyrights.org/donate-2/ 

-- 

Adrian Gropper MD

RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE:  <http://patientprivacyrights.org/donate-2/> http://patientprivacyrights.org/donate-2/ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150901/44c51f29/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150901/44c51f29/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 3147 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150901/44c51f29/attachment-0003.jpg>