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

Thu Aug 6 12:30:23 UTC 2015

I know I am generalizing  but this flow augments or runs parallel to the
opt-in/opt-out options I have seen for release of personal identifying
information or the options I am forced to acknowledge when
installing/initializing/registering/ authenticating to an app for the first
time .

Asynchrously identifying these sort of preferences moves us towards the
more complicated DS4P UMA like scenarios (PoF)
On Aug 6, 2015 7:27 AM, "Moehrke, John (GE Healthcare)" <
John.Moehrke at med.ge.com> wrote:

> At the federal level, under HIPAA alone, there is no need for consent for
> purposes of using the data within the Covered Entity for Treatment,
> Payment, and Normal operations.
>
>
>
> BUT, there are plenty of states that require consent… Ignoring reality of
> states regulations is not useful.
>
>
>
> AND, there are some institutions that would rather have a consent that
> authorizes them to share beyond their Covered Entity boundary. Not everyone
> reads HIPAA ‘Treatment’ as an authorization to share with any treating
> provider.
>
>
>
> AND, there are some ‘sensitive’ health topics covered by federal money
> that do come with a requirement for consent for sharing. This was the main
> focus of the DS4P efforts.
>
>
>
> So, let’s not focus on HIPAA alone. Let’s expect that ‘for whatever reason
> an organization wants to have positive evidence that the patient desires
> sharing to happen’ as the trigger to allow it to happen (otherwise deny it
> from happening. This would seem more helpful to the community we are doing
> this work for.
>
>
>
> An important aspect of all of this is how will the organization holding
> the data be able to legally defend that a UMA/OAuth token was valid
> evidence of consent that would hold up in a courtroom… We can’t address
> this in HEART, but it should not slow us down. We again, document this as a
> precondition to our work. One way this is done is that a paper trail is a
> part of the initial setup of a patient engaging with the system.
>
>
>
> John
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Adrian Gropper
> *Sent:* Wednesday, August 05, 2015 11:49 PM
> *To:* Debbie Bucci
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes
>
>
>
> I have never heard the term "simple consent". There's nothing like
> "consent" in the context of data sharing that I can think of. HIPAA removed
> the patient's right of consent in 2002
> https://patientprivacyrights.org/?s=HIPAA+Consent
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__patientprivacyrights.org_-3Fs-3DHIPAA-2BConsent&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=QPfpP6tNPhNn0uCYFnfBuRqSH5IVEwKw_Jqp3j4NGRQ&s=u1OCcH7ZkX-4jzmNs_eIhVZUi0lQOy0npXd30zYGE8I&e=>
>
> There are consent forms for research but that's not part of the use cases
> we're tackling these days.
>
> Does anyone have an example of consent for clinical data sharing to share
> with us?
>
> Adrian
>
>
>
>
>
> On Thu, Aug 6, 2015 at 12:10 AM, Debbie Bucci <debbucci at gmail.com> wrote:
>
> @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
> <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=QPfpP6tNPhNn0uCYFnfBuRqSH5IVEwKw_Jqp3j4NGRQ&s=rCzIAK2qBPKQaibR7Ns2AF69bEcf2hFBrgPF6wgZ0i4&e=>
>
>
>
>
>
>
> --
>
>
>
> Adrian Gropper MD
>
> RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=QPfpP6tNPhNn0uCYFnfBuRqSH5IVEwKw_Jqp3j4NGRQ&s=5EO5dh5y1O7CjbbjqdwxTBcdii8ABtLHO2waj3VDYfw&e=>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150806/8d8be9ac/attachment.html>