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

[John Moehrke]

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