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

Thu Aug 6 12:34:38 UTC 2015

Adrian,

Nicely done. I agree the items you have outlined do tend to be common.

Note that this kind of form is the focus of a CBCC workgroup within HL7 for inclusion within FHIR. This effort is looking at the workflow including the display of a locally customized form that captures well-formed and potentially coded values. The result would be evidence that the patient has interacted in a ceremony where the patient gave instructions (consent) on how their data would be shared/used/maintained… This would leverage the FHIR Questionnaire, and would result in the evidence being recorded in a FHIR Contract Resource.  This work is progressing slowly right now because the workgroup is trying to close out previous work items. This FHIR based work will pick up this fall. I encourage people participate, we need as many viewpoints as possible to participate.

As I indicated in the last email, this ceremony evidence could then trigger the UMA/OAuth infrastructure behavior. This does not mean that the UMA/OAuth infrastructure can’t make finer-grain adjustments on a purpose-by-purpose basis. 

John

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Adrian Gropper
Sent: Wednesday, August 05, 2015 8:12 PM
To: jim kragh
Cc: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes

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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=S7fGTUy1lNMEY4BpFUBCfpXwErffmyQOSqfeJY6e914&s=l5MsLujjC585bI5bTHaNCJzydZvGFnyoxaCG5q1A_bk&e=> 

_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-heart <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=S7fGTUy1lNMEY4BpFUBCfpXwErffmyQOSqfeJY6e914&s=l5MsLujjC585bI5bTHaNCJzydZvGFnyoxaCG5q1A_bk&e=> 

-- 

Adrian Gropper MD

RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE:  <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=S7fGTUy1lNMEY4BpFUBCfpXwErffmyQOSqfeJY6e914&s=PgRD1dr-xfxxrbFasExywW6XzhrHRlPw3dwNLuaMl8w&e=> http://patientprivacyrights.org/donate-2/ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150806/529e55a1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6966 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150806/529e55a1/attachment-0001.p7s>