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

Mon Jan 25 15:38:40 UTC 2016

Let's generously read Adrian's claim here as "a patient who cares enough
can set up her own AS, and thereby ensure that her AS's jwk is unique to
her". So yes, you can (with enough effort -- which might be driven down by
technology) get to the point of one jwk per AS, if you really want.

But even if you do so, the AS's jwk in HEART* isn't really an "encryption
key" sense in the way Adrian would have it*. In other words, the AS's jwk
is not used as an "encryption key" for the patient's healthcare data at any
point. (It *is* used to sign tokens in the UMA flow, including the PAT and
the AAT.)

By the way,
http://openid.bitbucket.org/HEART/openid-heart-uma.html#rfc.section.2.1
says that an "aud" claim in the AAT specifies the "RPT authorization
endpoint"; UMA refers to this as simply the "RPT endpoint", and I think the
HEART profile's language should be consistent (this tripped me up for 10min
just now).

  -J

On Mon, Jan 25, 2016 at 10:02 AM, Adrian Gropper <agropper at healthurl.com>
wrote:

> 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://urldefense.proofpoint.com/v2/url?u=https-3A__webfinger.net_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=qupbYXH4yZuzhNsgW0jcwq786o--G6D1m7GlkENe1lw&e=>
>>>> https://webfinger.net/
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__webfinger.net_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=qupbYXH4yZuzhNsgW0jcwq786o--G6D1m7GlkENe1lw&e=>
>>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Halting-5Fproblem&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=eVT2hXrUini0He7H6c-zHwPxd4ROV6nwfZ53AECX76o&e=>
>>>>> .)
>>>>>
>>>>> 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.*
>>>>>
>>>>> *
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.healthdatamanagement.com_news_chime-2Dlaunches-2D1m-2Dchallenge-2Dto-2Dsolve-2Dpatient-2Did-2Dproblem&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=_qW1n-yVrg_DP1kqs-CW-XiipWZapB1GXpTiUdB-pMo&e=>http://www.healthdatamanagement.com/news/chime-launches-1m-challenge-to-solve-patient-id-problem
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.healthdatamanagement.com_news_chime-2Dlaunches-2D1m-2Dchallenge-2Dto-2Dsolve-2Dpatient-2Did-2Dproblem&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=_qW1n-yVrg_DP1kqs-CW-XiipWZapB1GXpTiUdB-pMo&e=>*
>>>>> --
>>>>>
>>>>> *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
>>>>>
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.SecurityRiskSolutions.com&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=sO0EFn2RDc6nTcNVSjD-lEfCdZqy-TatdAT6ccpnTZI&e=>
>>>>> www.SecurityRiskSolutions.com
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.SecurityRiskSolutions.com&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=sO0EFn2RDc6nTcNVSjD-lEfCdZqy-TatdAT6ccpnTZI&e=>
>>>>>
>>>>> _______________________________________________
>>>>> Openid-specs-heart mailing list
>>>>> Openid-specs-heart at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=YlZbL57zFJCHlm8lTsjPaao9DWipNm9s50Q8ZFOgk54&e=>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Adrian Gropper MD
>>>>
>>>> PROTECT YOUR FUTURE - RESTORE Health Privacy!
>>>> HELP us fight for the right to control personal health data.
>>>> DONATE:
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=>
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=>
>>>> http://patientprivacyrights.org/donate-2/
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=>
>>>>
>>>>
>>>> _______________________________________________
>>>> Openid-specs-heart mailing listOpenid-specs-heart at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-heart <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=YlZbL57zFJCHlm8lTsjPaao9DWipNm9s50Q8ZFOgk54&e=>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Adrian Gropper MD
>>>
>>> PROTECT YOUR FUTURE - RESTORE Health Privacy!
>>> HELP us fight for the right to control personal health data.
>>> DONATE:
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=>
>>> http://patientprivacyrights.org/donate-2/
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=>
>>>
>>>
>>>
>>
>>
>> --
>>
>> 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/
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=>
>>
>>
>>
>
>
> --
>
> 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/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQICAg&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=YlZbL57zFJCHlm8lTsjPaao9DWipNm9s50Q8ZFOgk54&e=
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160125/6a1394b7/attachment-0001.html>