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

Debbie Bucci debbucci at gmail.com
Sun May 13 01:31:51 UTC 2018


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/20180512/321e5cee/attachment.html>


More information about the Openid-specs-heart mailing list