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

Aaron Seib aaron.seib at nate-trust.org
Thu Aug 6 15:45:28 UTC 2015


I think we can assume a pseudo-tech person for this work group’s purposes but we need a glossary-type aid for those of us that are catching up.

 

BTW, I don’t think it is impossible to make this typical user accessible if we assume that user behavior will follow the patterns that evolved in Moral\Societal\Institutional trust decisions made by our species.  

 

I rely on people like me to help me decide who to trust in the world.  If Deb Peel’s privacy posture is like mine or John Halamka’s I’d want a mechanism to start the configuration of my privacy preferences in an Authorization Server that is trustworthy to start off to be like his\hers.  And then be able to modify it as I walked through a guided review of what the different configuration options mean and the pro’s and cons that matter.  It isn’t necessarily something that I am expert in but there are bus loads of UI\UX people that could make this easier for consumers.

 

Any technology that is useful reflects human needs – figuring out how to make it adoptable is a distinct domain that we should all appreciate for making the stuff we do useful to the world. J

 

Aaron Seib, 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 Moehrke, John (GE Healthcare)
Sent: Thursday, August 06, 2015 11:29 AM
To: Josh Mandel; Maxwell, Jeremy (OS/OCPO)
Cc: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes

 

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/62279567/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150806/62279567/attachment-0001.jpg>


More information about the Openid-specs-heart mailing list