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

[Adrian Gropper]

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