[Openid-specs-heart] Consumer that slightly understands the technology

Sun Aug 9 15:17:30 UTC 2015

I'm a consumer, I've led EHR implementation projects. I participated In
BlueButtonPlus, I think the work this group is doing is vital and
necessary, but insufficient.  I'm really working hard to understand the
language and the technology, but, as Adrian warned me, it's still another
language completely.  I mostly don't understand what you are all talking
about. The part that is insufficient is bringing consumers along with us.
One of my goals is to be able to write the occasional post for my readers
reporting on this work,generating some excitement and interest. I'm going
to try to write something as we speak, but my gaps in understanding are as
big as Texas.  Onward

On Thu, Aug 6, 2015 at 11:29 AM, <
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 (Moehrke, John (GE Healthcare))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 6 Aug 2015 15:29:16 +0000
> From: "Moehrke, John (GE Healthcare)" <John.Moehrke at med.ge.com>
> To: Josh Mandel <Joshua.Mandel at childrens.harvard.edu>, "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:
>         <B025BFE1B1C0AA4596EEF6AA85D6F499541188BA at CINURCNA01.e2k.ad.ge.com
> >
> Content-Type: text/plain; charset="utf-8"
>
> I agree with Josh, our problem is already infinitely impossible. Our
> ultimate goal should be the non-technical healthcare consumer, but In the
> interests of making incremental improvements can we start with a goal of a
> healthcare consumer that DOES understand the technology? We can revise and
> improve as we go (being Agile).
>
>
>
> John
>
>
>
> From: Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] On Behalf Of Josh Mandel
> Sent: Thursday, August 06, 2015 10:16 AM
> To: Maxwell, Jeremy (OS/OCPO)
> Cc: openid-specs-heart at lists.openid.net
> Subject: Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes
>
>
>
> Roughly: the resource server is what your healthcare provider hosts.
> Today, you might have various patient portals, provided by different
> healthcare organizations, each showing you different subsets of your data.
> The paradigm we're talking about with UMA is: each one of those portals is
> actually backed by a server that exposes your data through an API. Those
> servers are the resource servers. And the goal of UMA, as a protocol, is to
> get all of those resource servers to "work with" a single authorization
> server, so you can set permissions in one place.
>
>
>
> To be honest, I remain skeptical that we can orchestrate this many moving
> parts into a user experience that non-technical healthcare consumers will
> be able to understand and leverage. I don't think it's impossible for any
> theoretical reason, but it's a very, very hard design problem. The systems
> that come the closest to achieving this vision today are systems that
> succeed because they control the whole stack (e.g. in Google Docs, the
> sharing/permissions settings are great, in part because they're tightly
> integrated into the document editing environment. When you try to
> standardize each step of the process and factor the architecture out into
> separate components, it becomes harder to build such a tightly integrated
> user experience).
>
>
>
>  - J
>
>
>
>
>
> On Thu, Aug 6, 2015 at 10:57 AM, Maxwell, Jeremy (OS/OCPO) <
> Jeremy.Maxwell at hhs.gov> wrote:
>
> No worries.  I?m just trying to understand how we think this will happen
> in practice.  So for my wife (non-techie), what is her resource server?
> When she goes into her provider, what does she have to provide?
>
>
>
> Sorry if I?m being dense or revisiting things that have already been
> discussed.  I missed about 4 weeks of discussion so I?m trying to catch
> up.  I?m trying to understand what the workflow looks like to a non-techie
> patient.
>
>
>
>
>
>
>
> From: jmandel at gmail.com [mailto:jmandel at gmail.com] On Behalf Of Josh
> Mandel
> Sent: Thursday, August 06, 2015 10:52 AM
> To: Aaron Seib
> Cc: Maxwell, Jeremy (OS/OCPO); jim kragh; Debbie Bucci;
> openid-specs-heart at lists.openid.net
>
>
> Subject: Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes
>
>
>
> Apologies if this was totally unclear. The "Dear Dr. Jones..." statement
> was meant to capture what it means for a resource owner to introduce a
> resource server to an authorization server (in UMA terms). Does this help
> at all?
>
>
>
>   -J
>
>
>
> On Thu, Aug 6, 2015 at 10:16 AM, Aaron Seib <aaron.seib at nate-trust.org>
> wrote:
>
> I am not sure I even understand the statement highlighted in yellow
> accurately yet.  J
>
>
>
> That might be a start.  Predetermined choice token means?  Confidential
> token choice?
>
>
>
> Aaron
>
>
>
> Aaron Seib
>
>  <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.nate-2Dtrust.org_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=z8Y3dTNXfeIHTJOVrFI1AbuFBtR0weR9H30VsLiwJME&s=tgDfJWZHjbfBbL_Yrkm82b9zJxfIA-nZsaQ9nf5XQ5c&e=>
> NATE, CEO
>
> @CaptBlueButton
>
> (o) 301-540-2311
>
> (m) 301-326-6843
>
>
>
>
>
> From: Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] On Behalf Of Maxwell, Jeremy
> (OS/OCPO)
> Sent: Thursday, August 6, 2015 9:41 AM
> To: jim kragh; Debbie Bucci
>
>
> Cc: openid-specs-heart at lists.openid.net
> Subject: Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes
>
>
>
>
>
> 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.
>
>
>
> Perfectly fine with leaving this in the parking lot for now, but before
> we?re done we need to have very clear setup/configuration/implementation
> guidance.  It needs to be clear and easy to setup and use.  If we add a
> bunch of configuration steps it will be additional hurdles to adoption.
> Remember, many folks have struggled with certificate and trust bundle
> management in Direct.  So we need to at least be simpler than that.
>
>
>
>
>
> From: Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] On Behalf Of jim kragh
> Sent: Wednesday, August 05, 2015 8:28 PM
> To: Debbie Bucci
> Cc: openid-specs-heart at lists.openid.net
> Subject: Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes
>
>
>
> 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=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=z8Y3dTNXfeIHTJOVrFI1AbuFBtR0weR9H30VsLiwJME&s=8XR3NIglMh-Fdi8Tn07unv1E52KNE5BIepwuZRF7Vr0&e=
> >
>
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart
> <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQICAg&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=z8Y3dTNXfeIHTJOVrFI1AbuFBtR0weR9H30VsLiwJME&s=8XR3NIglMh-Fdi8Tn07unv1E52KNE5BIepwuZRF7Vr0&e=>
> &d=BQICAg&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=z8Y3dTNXfeIHTJOVrFI1AbuFBtR0weR9H30VsLiwJME&s=8XR3NIglMh-Fdi8Tn07unv1E52KNE5BIepwuZRF7Vr0&e=
>
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150806/1e18d9bd/attachment.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/1e18d9bd/attachment.p7s
> >
>
> ------------------------------
>
> 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 41
> **************************************************
>

-- 
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/503c69be/attachment-0001.html>