[Openid-specs-heart] CHIME Launches $1M Challenge to Solve Patient ID Problem

Mon Jan 25 15:02:10 UTC 2016

Why "most likely not"? Is it a security issue? a cost issue? We don't have
to compromise privacy for security in our connected world.

On Mon, Jan 25, 2016 at 9:55 AM, Justin Richer <jricher at mit.edu> wrote:

> But it's not like that, the arity is very different.
>
> Every record is associated with an AS, perhaps a separate AS for each
> record/patient but most likely not.
>
> Every AS is associated with a jwks_uri, but only one per AS.
>
>  -- Justin
>
>
> On 1/25/2016 9:02 AM, Adrian Gropper wrote:
>
> It means that every patient record is associated with a separate jwks_uri
> for that patient's AS.
>
> On Mon, Jan 25, 2016 at 8:59 AM, Justin Richer <jricher at mit.edu> wrote:
>
>> Yes you did. Quote:
>>
>> "The system is also much more resistant to data breaches as data holders
>> (UMA Resource Servers) must implement separate *encryption keys *for
>> each patient."
>>
>> So if you don't mean separately encrypting the data for each user, what
>> does that statement mean? The access token isn't an encryption key.
>>
>>  -- Justin
>>
>>
>> On 1/25/2016 8:57 AM, Adrian Gropper wrote:
>>
>> I never said anything about how the data is encrypted. I only talk about
>> how access to the FHIR API is controlled.
>>
>> Adrian
>>
>> On Mon, Jan 25, 2016 at 8:55 AM, Justin Richer < <jricher at mit.edu>
>> jricher at mit.edu> wrote:
>>
>>> Adrian,
>>>
>>> I've asked this before and thought we'd settled it, but it keeps coming
>>> up: where are you getting the idea of encrypting the data to the patient
>>> using a patient's key? That is not in scope for HEART, nor is it part of
>>> any of the underlying protocols.
>>>
>>>  -- Justin
>>>
>>>
>>> On 1/25/2016 8:52 AM, Adrian Gropper wrote:
>>>
>>> Establishing a separate URI for each patient is likely to be the only
>>> stable solution to the patient ID problem. The issue, however, is how many
>>> URIs will a patient be allowed to have? If the URIs are coercive, in the
>>> sense of a chip or tattoo issued by government or an equivalent global
>>> authority (Facebook?) or the URI is derived from DNA or an iris scan. (Iris
>>> scans are a good positive IDs and can be read from 30 feet away with modern
>>> technology.)
>>>
>>> Let's assume, for our purposes, that an iris scanner costs about as much
>>> as a credit card terminal, cheap enough for every front office, ambulance,
>>> and police car. Is the patient ID problem solved? I don't think so.
>>>
>>> Patients can have one or more separate URIs in order to help manage
>>> their health records. Today, we typically use email address for this
>>> purpose, with WebFinger <https://webfinger.net/>https://webfinger.net/
>>> as a standardized way to discover linked attributes such as the patient's
>>> UMA Authorization Server and the associated public key.
>>>
>>> UMA for patient ID brings numerous benefits including much greater
>>> transparency and security. The patient now has a single portal (their UMA
>>> AS) to view all current relationships under that particular patient ID
>>> persona. The system is also much more resistant to data breaches as data
>>> holders (UMA Resource Servers) must implement separate encryption keys for
>>> each patient.
>>>
>>> I think the HEART group is in a good position to compete for the CHIME
>>> challenge on this basis and I'd be happy for me and PPR to help organize a
>>> submission.
>>>
>>> Adrian
>>>
>>> On Sun, Jan 24, 2016 at 1:20 PM, Aaron Seib <
>>> <aaron.seib at nate-trust.org>aaron.seib at nate-trust.org> wrote:
>>>
>>>> I appreciate your expertise and action.
>>>>
>>>> I don't necessarily agree with some of your statements here but that is
>>>> the beauty of open processes.
>>>>
>>>> Let's strive to do all we can - together.
>>>>
>>>>
>>>>
>>>> Aaron Seib
>>>> @CaptBlueButton
>>>> (O) 301-540-9549
>>>> (M) 301-326-6843
>>>>
>>>> "The trick to earning trust is to avoid all tricks.  Including tricks
>>>> on yourself."
>>>>
>>>>
>>>>
>>>> -------- Original message --------
>>>> From: "Glen Marshall [SRS]" < <gfm at securityrs.com>gfm at securityrs.com>
>>>> Date: 2016/01/24 7:07 AM (GMT-08:00)
>>>> To: HEART List < <openid-specs-heart at lists.openid.net>
>>>> openid-specs-heart at lists.openid.net>
>>>> Subject: [Openid-specs-heart] CHIME Launches $1M Challenge to Solve
>>>> Patient ID Problem
>>>>
>>>> This is pertinent to our data-sharing use cases.  There is no current
>>>> solution to accurately sharing/gathering patients' clinical data stored
>>>> among various repositories.  In turn, that makes applying access controls
>>>> across all of a patient's data in those repositories difficult.   I'm happy
>>>> to see Chime's challenge.
>>>>
>>>> However, the related problem of discovering where all of one's data
>>>> might be is computationally intractable.  It is equally intractable to
>>>> gather and combine all access permissions and regulatory restrictions on
>>>> patients' data, even if there were a useful means to do so.  (Both are
>>>> equivalent to the halting problem
>>>> <https://en.wikipedia.org/wiki/Halting_problem>.)
>>>>
>>>> Having a single "source of truth" repository is one direction for a
>>>> solution, as is having a single access permissions source.  Keeping them
>>>> updated with new data and permissions is possible, even if difficult in the
>>>> short run.
>>>>
>>>> However, establishing unique URIs for each patient's data and
>>>> permissions is the same as having a universal patient identifier.  That
>>>> might be subject to current Congressional funding restrictions.
>>>>
>>>>
>>>> *The College of Healthcare Information Management Executives on Tuesday
>>>> launched a $1 million National Patient ID Challenge to develop solutions to
>>>> ensure 100 percent accuracy of every patient’s identity to reduce
>>>> preventable medical errors.*
>>>>
>>>> *
>>>> <http://www.healthdatamanagement.com/news/chime-launches-1m-challenge-to-solve-patient-id-problem>http://www.healthdatamanagement.com/news/chime-launches-1m-challenge-to-solve-patient-id-problem
>>>> <http://www.healthdatamanagement.com/news/chime-launches-1m-challenge-to-solve-patient-id-problem>*
>>>> --
>>>>
>>>> *Glen F. Marshall*
>>>> Consultant
>>>> Security Risk Solutions, Inc.
>>>> 698 Fishermans Bend
>>>> Mount Pleasant, SC 29464
>>>> Tel: (610) 644-2452 <%28610%29%20644-2452>
>>>> Mobile: (610) 613-3084 <%28610%29%20613-3084>
>>>> <gfm at securityrs.com>gfm at securityrs.com
>>>> <http://www.SecurityRiskSolutions.com>www.SecurityRiskSolutions.com
>>>>
>>>> _______________________________________________
>>>> Openid-specs-heart mailing list
>>>> Openid-specs-heart at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Adrian Gropper MD
>>>
>>> PROTECT YOUR FUTURE - 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/>
>>> http://patientprivacyrights.org/donate-2/
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-heart mailing listOpenid-specs-heart at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-heart
>>>
>>>
>>>
>>
>>
>> --
>>
>> Adrian Gropper MD
>>
>> PROTECT YOUR FUTURE - 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
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
>
>
>

-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160125/0d01af96/attachment.html>