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

Mon Jan 25 14:02:58 UTC 2016

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> 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>*
>>> --
>>>
>>> *Glen F. Marshall*
>>> Consultant
>>> Security Risk Solutions, Inc.
>>> 698 Fishermans Bend
>>> Mount Pleasant, SC 29464
>>> Tel: (610) 644-2452
>>> Mobile: (610) 613-3084
>>> gfm at securityrs.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/
>>
>>
>> _______________________________________________
>> 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/
>
>
>

-- 

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/9ee46de5/attachment.html>