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

[Debbie Bucci]

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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20180513/46f09e71/attachment-0001.html>