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

Thu Aug 6 15:15:44 UTC 2015

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
>
> NATE
> <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=>,
> 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
> <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&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/2346a885/attachment-0001.html>