[Openid-specs-heart] Patient-driven interoperability

Sun Aug 9 15:03:13 UTC 2015

Adrian, I love your statement:

The one thing we haven't tried is patient-driven interoperability. Apple
has shown us how patient-directed interoperability can work in a highly
integrated system. UMA is the only standard we have that has the potential
to introduce patient-driven interoperability to healthcare.

On Thu, Aug 6, 2015 at 4:06 PM, <openid-specs-heart-request at lists.openid.net
> wrote:

> Send Openid-specs-heart mailing list submissions to
>         openid-specs-heart at lists.openid.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.openid.net/mailman/listinfo/openid-specs-heart
> or, via email, send a message with subject or body 'help' to
>         openid-specs-heart-request at lists.openid.net
>
> You can reach the person managing the list at
>         openid-specs-heart-owner at lists.openid.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Openid-specs-heart digest..."
>
>
> Today's Topics:
>
>    1. Re: HEART 2015-08-05 meeting notes (Adrian Gropper)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 6 Aug 2015 16:06:14 -0400
> From: Adrian Gropper <agropper at healthurl.com>
> To: "Maxwell, Jeremy (OS/OCPO)" <Jeremy.Maxwell at hhs.gov>
> Cc: "openid-specs-heart at lists.openid.net"
>         <openid-specs-heart at lists.openid.net>
> Subject: Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes
> Message-ID:
>         <CANYRo8iFVD=
> oKD9wSb6j9i+JQ82Z0XS7aWbbFWxincpUnYQ67w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I'm not sure what we're negotiating here. The current approach to
> interoperability does not work for many, maybe most people. Part of the
> reason it doesn't is that privacy approaches that work at a scale of 10K or
> 100K people don't work when the scale is 100 Million people. I've been a
> party to four or five generations of attempts at interoperability (IHE,
> NwHIN, CONNECT, DIRECT, BlueButton Plus) and we still don't have a clear
> solution. We've also seen that even completely centralized systems like the
> UK NHS can't deal with this problem very well so I can't see why CommonWell
> or Carequlality or Epic everywhere would succeed.
>
> The one thing we haven't tried is patient-driven interoperability. Apple
> has shown us how patient-directed interoperability can work in a highly
> integrated system. UMA is the only standard we have that has the potential
> to introduce patient-driven interoperability to healthcare.
>
> We have to give patients that understand UMA the option to use it. Patients
> who don't care will see no difference at all because the Resource Server
> will offer a default AS.
>
> Once patients have the option to specify the AS the other interoperability
> issues, including scopes, will incrementally get fixed. But the first step
> is to agree that there's only one Alice and she has an AS. That is the only
> scalable and non-coercive solution.
>
> Adrian
>
> On Thu, Aug 6, 2015 at 9:51 AM, Maxwell, Jeremy (OS/OCPO) <
> Jeremy.Maxwell at hhs.gov> wrote:
>
> > How many patients do we expect to have the technical savvy to say this to
> > their provider?  In practice, where will these authorization servers
> reside?
> >
> >
> >
> > "Dear Dr. Jones: please treat my authorization server, at
> > https://authz.alice.org, as representing my wishes for disclosure of my
> > health data. Use the decisions that server renders to guide your access
> > control decisions about my data."
> >
> >
> >
> >
> >
> >
> >
> > *From:* Openid-specs-heart [mailto:
> > openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Josh Mandel
> > *Sent:* Thursday, August 06, 2015 9:19 AM
> > *To:* Moehrke, John (GE Healthcare)
> > *Cc:* openid-specs-heart at lists.openid.net
> > *Subject:* Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes
> >
> >
> >
> > As to the division between "gross ceremony" and "finer-grain
> adjustments",
> > I want to suss out whether the following model (which readily applies to
> > UMA, though not to vanilla OAuth) is consistent with you have in mind, or
> > whether this model is addressing a different question entirely:
> >
> >
> >
> > 1. *Gross ceremony* consists of Alice introducing her resource server to
> > an authorization server of her choice. For example, she might sign a
> > document saying (effectively): "Dear Dr. Jones: please treat my
> > authorization server, at https://authz.alice.org, as representing my
> > wishes for disclosure of my health data. Use the decisions that server
> > renders to guide your access control decisions about my data." This
> > document is easily comprehensible, could serve as evidence in court, etc.
> >
> >
> >
> > 2. And then the *finer-grain adjustments* would be made by Alice in
> > concert with her authorization server (for example, establishing specific
> > policies about who can access her data, and which data, and for what
> > purposes, and under what conditions).
> >
> >
> >
> > On Thu, Aug 6, 2015 at 9:06 AM, Moehrke, John (GE Healthcare) <
> > 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]
> > *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
> > *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
> >
> > (m) 301-326-6843
> >
> >
> >
> >
> >
> > *From:* Openid-specs-heart [
> > mailto:openid-specs-heart-bounces at lists.openid.net
> > <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
> > *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
> > <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=
> >
> >
> >
> > _______________________________________________
> > Openid-specs-heart mailing list
> > Openid-specs-heart at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs-heart
> >
> >
> >
> > _______________________________________________
> > Openid-specs-heart mailing list
> > Openid-specs-heart at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs-heart
> >
> >
>
>
> --
>
> Adrian Gropper MD
>
> RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150806/7efe93a9/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
> ------------------------------
>
> End of Openid-specs-heart Digest, Vol 32, Issue 45
> **************************************************
>

-- 
Danny van Leeuwen
617-304-4681

*Blog www.health-hats.com <http://www.health-hats.com/> discovering the
magic levers of best health*
*Twitter **@healthhats*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150809/7a84f5ad/attachment-0001.html>