[Openid-specs-heart] HEART 2015-08-05 meeting notes
James Hazard
james.g.hazard at gmail.com
Thu Aug 6 15:35:47 UTC 2015
Adrian,
Thanks for including me.
John,
The gross ceremony / fine-grain issue is an interesting vocabulary that
I rather like.
Many of the issues of law and consent can be viewed as problems of
traceability. How do I know the text I'm being asked to sign or rely on
is derived from a verified source, am I informed if someone spots an
issue, which solutions are trusted by people I trust? This problem maps
well to issues in source code management, and git/GitHub provides a
really robust solution. The "legal" part of the problem is mostly a
matter of getting communities of use around particular formulations.
The goal is shared repositories/wikis - a kind of 3.0 Civil Code.
Patient consents are one of the most interesting use cases because they
are so important. We've done a number of examples. With Primavera De
Filippi (of Berkman, who also coded the current parser) we did a
3-language machine-readable model patient consent based on the form of
the Global Alliance for Genomics and Health. With Adrian, I did a swim
lanes sketch. For Apple's ResearchKit (with John Wilbanks of Sage
Bionetworks) - I did a form from one of their studies.
Global Alliance:
http://ga4gh.commonaccord.org/index.php?action=list&file=./Demo/
Swimming with Adrian:
http://www.commonaccord.org/index.php?action=list&file=/doc/roi/
ResearchKit:
http://my.commonaccord.org/index.php?action=source&file=Research/Consent/Form/Research_Consent_Form.md
None of these yet have active communities, though there are a number of
discussions at various stages.
There is a strong fit with peer-to-peer payments systems. The gross
ceremony / fine-grain issue is a lot like the legal text vs "smart
contract" discussion there.
Happy to point to more examples or make a new one.
Cheers, Jim
On 8/6/15 4:37 PM, Adrian Gropper wrote:
> This is exactly the problem Jim's Common Accord is designed to solve.
> It links human-readable documents with machine-based structures a-la
> github. We also just launched a legal subgroup in UMA. All good stuff
> that HL7 and FHIR should not have to worry about.
>
> Adrian
>
> On Thu, Aug 6, 2015 at 9:06 AM, Moehrke, John (GE Healthcare)
> <John.Moehrke at med.ge.com <mailto:John.Moehrke at med.ge.com>> wrote:
>
> I agree with your proposal for ‘Authorize for Disclosure’ and to
> de-emphasize ‘Consent’… (although this problem with ‘Consent’ is
> only a USA problem)…
>
>
> But I don’t think that a UMA/OAuth ‘token’ will be seen as
> legitimate evidence in a court. It would be quickly shown to be
> not intelligible by the layperson, I can barely read them. Thus it
> is not evidence of the act of ‘authorizing for disclosure’
> ceremony. This is indeed a practice-of-law problem that we all
> hope changes, but I have little hope that it will change in the
> coming 10 years. This is why I want the gross ceremony to be a
> pre-condition, with the UMA/OAuth technology be the fine-grain
> solution. I expect that a gross ceremony can be shown in a court
> as evidence that all parties understood the use of the technology
> would be used for fine-grain. Note that if the courtroom antics
> change, then this pre-condition simply goes away. But by putting
> it there we enable it to be used, and thus make our solution more
> palatable to the legal folks at those custodian organizations that
> are afraid to release information today.
>
> John
>
> *From:*Aaron Seib [mailto:aaron.seib at nate-trust.org
> <mailto:aaron.seib at nate-trust.org>]
> *Sent:* Thursday, August 06, 2015 7:58 AM
> *To:* Moehrke, John (GE Healthcare); 'Adrian Gropper'; 'Debbie Bucci'
> *Cc:* openid-specs-heart at lists.openid.net
> <mailto:openid-specs-heart at lists.openid.net>
> *Subject:* RE: [Openid-specs-heart] HEART 2015-08-05 meeting notes
>
> I tend to agree with John’s recommendation with a friendly amendment.
>
> We should not mis-use the word consent. We should use the term –
> authorize for disclosure.
>
> The primary reason being that the term consent has a lot of
> baggage and is defined in law for Human research protections and
> authorize for disclosure is more accurate to me. Consent – as
> pointed out by the Kind Sir from Boston (Adrian) to point out –
> meant something before 2002 that it doesn’t mean anymore.
>
> In my opinion the notion of authorize for disclosure also
> conveniently aligns with my understanding of what ab “UMA/OAuth
> token” would represent on a per transaction basis.
>
> In court we would expect the entity accused of unauthorized
> disclosure to be able to produce a valid UMA/OAuth token as a
> sufficient defense from mis-representations of trial lawyers.
>
> Aaron Seib
>
> NATE
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.nate-2Dtrust.org_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=87vCtxeoEunALdecDlNur8aIU5qcY6YWTAxWw6j34cs&s=PU_01do09mzHBYjfdhFvZCLDAP7Tpxnm1P001w-6AlU&e=>,
> CEO
>
> @CaptBlueButton
>
> (o) 301-540-2311 <tel:301-540-2311>
>
> (m) 301-326-6843 <tel:301-326-6843>
>
> *From:*Openid-specs-heart
> [mailto:openid-specs-heart-bounces at lists.openid.net] *On Behalf Of
> *Moehrke, John (GE Healthcare)
> *Sent:* Thursday, August 6, 2015 7:27 AM
> *To:* Adrian Gropper; Debbie Bucci
> *Cc:* openid-specs-heart at lists.openid.net
> <mailto:openid-specs-heart at lists.openid.net>
> *Subject:* Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes
>
> 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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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 <mailto: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
> <mailto: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=>
>
>
>
>
>
> --
>
> Adrian Gropper MD
>
> RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
--
@commonaccord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150806/e832aaaf/attachment-0001.html>
More information about the Openid-specs-heart
mailing list