[Openid-specs-heart] CHIME Launches $1M Challenge to Solve Patient ID Problem
Justin Richer
jricher at mit.edu
Mon Jan 25 14:55:51 UTC 2016
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
> <mailto: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
>> <mailto: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/ 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
>>> <mailto: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 <tel:301-540-9549>
>>> (M) 301-326-6843 <tel: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
>>> <mailto:gfm at securityrs.com>>
>>> Date: 2016/01/24 7:07 AM (GMT-08:00)
>>> To: HEART List <openid-specs-heart at lists.openid.net
>>> <mailto: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/
>>> --
>>>
>>> *Glen F. Marshall*
>>> Consultant
>>> Security Risk Solutions, Inc.
>>> 698 Fishermans Bend
>>> Mount Pleasant, SC 29464
>>> Tel: (610) 644-2452 <tel:%28610%29%20644-2452>
>>> Mobile: (610) 613-3084 <tel:%28610%29%20613-3084>
>>> gfm at securityrs.com <mailto:gfm at securityrs.com>
>>> www.SecurityRiskSolutions.com
>>> <http://www.SecurityRiskSolutions.com>
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-heart mailing list
>>> Openid-specs-heart at lists.openid.net
>>> <mailto: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 list
>>> Openid-specs-heart at lists.openid.net
>>> <mailto: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/
>
>
>
>
> --
>
> 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/5367e824/attachment-0001.html>
More information about the Openid-specs-heart
mailing list