[Openid-specs-heart] Taking up the notion of a de-identification scope

Debbie Bucci debbucci at gmail.com
Tue May 22 17:23:24 UTC 2018


Thread update:


I am late in posting meeting notes but I want to address this specific
issue.

The HEART WG met on May 14th.

We discussed the pros and cons of adding the de-identification scope.
 Part of the discussion focused on needs for US Healthcare (not sure it
would gain traction ) to potentially being helpful to support areas of
interest such as Health IOT devices and noting that adding the scope is
consistent with the approach we have taken thus far.   We believe this
requires additional discussion.

The  group decided it was best to move ahead with the current updates to
the HEART profiles - as originally agreed to    ( briefly: Smart alignment
with use of aud to note resource server to retrieve data from , support for
public clients and UMA 2.0 spec)  and to continue the discussion of the
de-identification scope  and perhap further clarification - guidance in
future releases.

No real discussion on BTG beyond acknowledgement it was already in the
approved  prior specs.

I hope this generally aligns with the discussion.

Wanted to be sure to post this before I move to ask the OpenID Foundation
to move our updated drafts to broader review & vote.






On Sun, May 13, 2018 at 9:55 AM, Adrian Gropper <agropper at healthurl.com>
wrote:

> Debbie, I don’t understand your explanation. Who is evaluating the
> requesting party’s claims and generating an access token when Alice is
> unconscious? Is it the RS (as in the Adrian Clause) or the AS (as in
> delegation using UMA)?
>
> If it’s the RS and OAuth then the AS and RS are operated by the same
> entity and the Adrian’s Clause distinction is moot.
>
> If it’s a delegated AS, a separate operator from the RS, then it’s an UMA
> AS that is evaluating the Requesting Party claims.
>
> Which of these two scenarios are we discussing when Alice is unconscious?
>
> Adrian
>
> On Sun, May 13, 2018 at 7:30 AM Debbie Bucci <debbucci at gmail.com> wrote:
>
>> Adrian
>>
>> This conversation is focused specifically on scopes.   I'd prefer we
>> stick to the subject.  That said...
>>
>> HEART is a set of layered constrained profiles that are layered on top
>> of/extend OAUTH functionality. Implementing the HEART compliant profiles
>> does not require UMA or Openid connect  for every single use case.
>>
>> Our phr virtual clipboard use case has been profiled both ways.  With and
>> without uma (though believe we used openid for both)
>>
>> The example I used ...( agree may be ignored by an highly regulated US
>> EHR system) Alice has proactively set up her delegations to allow her
>> family access to information she has DIRECT control over.
>>
>> If Alice is unconscious, that access is not  going to happen real time.
>> She is not *present* on line to assist in the generation of that access
>> token.  Straight up OAUTh does not support. That does imply the use of UMA.
>>
>>
>> On Sun, May 13, 2018, 2:06 AM Adrian Gropper <agropper at healthurl.com>
>> wrote:
>>
>>> Before continuing this conversation about scopes let’s see if we all
>>> understand what HEART is.
>>>
>>> Quoting Debbie, “heart use cases have assumed a phr... “ is very very
>>> confusing to me. A phr does not need HEART. It’s a patient-controlled OAuth
>>> client and can be connected via FHIR / OAauth without UMA at all.
>>>
>>> What am I missing?
>>>
>>> Adrian
>>>
>>>
>>>
>>> On Sun, May 13, 2018 at 1:23 AM John Moehrke <johnmoehrke at gmail.com>
>>> wrote:
>>>
>>>> Hi all
>>>>
>>>> I am not indicating there is no place for HEART in these.
>>>>
>>>> Btg as an indicator of patient willingness to authorize appropriate btg
>>>> override, or not... This seems within the scope of HEART.  It is however
>>>> not the medical decision, just the patient allowance or forbiddance. As
>>>> such, it is not likely to considered. Which might be Adrian's point. I am
>>>> not against this meaning of btg in HEART.
>>>>
>>>> As to deid, I'm also encouraging this. I just want it to be realistic.
>>>> An indicator in the token about a level-of-anonimity would be useful and
>>>> practical. This can be used when the patient has engaged with an
>>>> app/recipient that can accept deid data. But most deid requires data
>>>> analysis driven deid that is done on the population of data and is aware of
>>>> usecases data needs and tolerance. So it is unlikely that a patient
>>>> selected deid algorithm will fit. Thus what the useful meaning and value is
>>>> not clear. Binary yes/no doesn't seem useful. More specific has no
>>>> vocabulary available.  Eventually there needs to be a deid LOA vocabulary,
>>>> like nist 800-63 has for Auth.
>>>>
>>>> Both of these are exciting buzzwords, so it is understandable why they
>>>> might be consideration, but the role HEART can play is limited. Limited but
>>>> useful is the question. So to be clear, I am not discouraging it, just
>>>> being realistic. It is possible that adding this complexity to HEART is not
>>>> helpful to overall acceptance.
>>>>
>>>> John
>>>>
>>>> On Sat, May 12, 2018, 8:32 PM Debbie Bucci <debbucci at gmail.com> wrote:
>>>>
>>>>> All
>>>>>
>>>>> I am confused. If you take a good look at the specs, heart is
>>>>> referencing HL7 standards for confidentiality and sensitivity codes.
>>>>>
>>>>>  Heart use cases have assumed a phr /health app is part of the patient
>>>>> portfolio.  In an emergency  today, a loved one or caregiver is typically
>>>>> drilled for the info as a place to start.  Wouldn't it be handy if family
>>>>> could request what is known/owned by patient  to assist in an emergency?
>>>>>
>>>>> I know resources can be tagged for security in the <meta> section but
>>>>> how does a client signal to a  resource server thats its authorized to
>>>>> recieve confidential information?   How the authorization server makes
>>>>> those decisions [consent or access control methods] are out of scope for
>>>>> HEART but the representation of that decision - I thought was in scope.
>>>>>
>>>>> Even if the header had a btg flag, wouldn't there also be a token as
>>>>> part of the request as well?
>>>>>
>>>>> I have not read the deidentified data blog yet.  Will do before
>>>>> Mondays call.
>>>>>
>>>>> I know we would like to update the specs to align with SMART and
>>>>> recognize UMA 2.0.  SMART Auth guide  is silent on these issues. With the
>>>>> exception of the deidentification scope the other scopes  were agreed upon
>>>>> in the last round of specs.
>>>>>
>>>>> Deb
>>>>>
>>>>>> --
>>>
>>> Adrian Gropper MD
>>>
>>> PROTECT YOUR FUTURE - RESTORE Health Privacy!
>>> HELP us fight for the right to control personal health data.
>>> DONATE: https://patientprivacyrights.org/donate-3/
>>>
>> --
>
> Adrian Gropper MD
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: https://patientprivacyrights.org/donate-3/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20180522/804463ef/attachment.html>


More information about the Openid-specs-heart mailing list