[Openid-specs-heart] HEART 2015-08-05 meeting notes

[Debbie Bucci]

@Eve - yes I know its client but I'm really hung up on the token
generation/choices.   Thanks for the tweaks.

I know we clarified that the release form is NOT consent in one of our
earlier meetings  but is this (release of information) what I have heard
others refer to as simple consent?    During this process would access to
problems/meds/allergies be included in that authorization/consent flow?
I visualized more than demographics in the conversation.



On Wed, Aug 5, 2015 at 9:21 PM, Justin Richer <jricher at mit.edu> wrote:

> Thank you, Adrian, this is a great reference! I think your annotations
> make sense as well, things should map pretty plainly to the OAuth process.
> The tricky part (that we got a start on today) is going to be the scopes
> bits and getting those right.
>
> For an UMA flow, it's also similar, except that the "who can see it" is a
> set of claims instead of the client application.
>
>  -- Justin
>
>
> On 8/5/2015 9:12 PM, Adrian Gropper wrote:
>
> I've attached a very typical Release of Information authorization. I've
> annotated the 5 elements common to all such documents that I have ever
> seen. The stuff outside if the rectangles is more or less optional.
>
> This form covers one direction of the EHR-PHR Use Case. It is presented to
> the Custodian (the patient or their designate ) and approved by them by the
> Resource Server and pre-filled with information supplied by the Client, if
> available.
>
> In some cases, the Client information is not available at the time the
> Authorization form is signed. In that case, it will be up to the
> Authorization Server to consider the Client and User information and
> provide the authorization to the Resource Server.
>
> The Resource Server has the final say in all cases and could decide to
> ignore the authorization based on local or jurisdictional policy. This is
> outside the control of the Resource Owner and likely to be out of scope for
> HEART in all use-cases.
>
> This ROI Authorization Form is the only "consent" that I'm aware of in
> clinical IT. Patients are asked to sign other documents, including:
> Registration Form, Notice of Privacy Practices, and Treatment Consent but
> none of these has anything to do with sharing of health data (except for
> HIPAA TPO which we will not get into here.)
>
> Adrian
>
> On Wed, Aug 5, 2015 at 8:27 PM, jim kragh <kragh65 at gmail.com> wrote:
>
>> Thanks for sharing,...  informative and constructive in reaching the
>> patient end point.
>>
>> May all have a nice evening!
>>
>> On Wed, Aug 5, 2015 at 3:26 PM, Debbie Bucci <debbucci at gmail.com> wrote:
>>
>>> Attendees:
>>> Eve Maler
>>> Justin Richer
>>> Josh Mandel
>>> Adrian Gropper
>>> Thomas Sullivan
>>> Debbie Bucci
>>>
>>> We have decided to delineate between mechanical and semantic scope docs.
>>>
>>> For the PCP <-> PHR use case:
>>>
>>> The pre determined choice token confidential token choice and exactly
>>> what information needs (example: PHR's authorization endpoint)  to be
>>> shared in advance between the PCP's EHR and Alice's PCP was left out of the
>>> discussion for now.
>>>
>>> There is one basic mechanical Oauth  generic flow that occurs twice in
>>> the use case.
>>>
>>> Given the group has generally agreed that the SMART specifications are a
>>> good place to *start ... *for this particular use case  the only
>>> semantic FHIR scope that is necessary is the patient/*.read scope that
>>> grants permission to read any resource for the current patient.
>>>
>>> During the registration process Alice should be able to select at a fine
>>> grain level which resources she is willing to share with the PHR.   This
>>> mimic's a specific process - Adrian please provide.  This information will
>>> be used to generate the access token.
>>>
>>> The one thing left at the end of the discussion is whether the patient
>>> record is implicit or explicitly stated.  This is a design decision that
>>> may make a difference as we move towards our next use case in
>>> which delegation is a factor.
>>>
>>> Corrections/updates appreciated.
>>>
>>>
>>>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150806/d563b57e/attachment-0001.html>