<div dir="ltr">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<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 11:29 AM,  <span dir="ltr"><<a href="mailto:openid-specs-heart-request@lists.openid.net" target="_blank">openid-specs-heart-request@lists.openid.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Openid-specs-heart mailing list submissions to<br>
        <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:openid-specs-heart-request@lists.openid.net">openid-specs-heart-request@lists.openid.net</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:openid-specs-heart-owner@lists.openid.net">openid-specs-heart-owner@lists.openid.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Openid-specs-heart digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: HEART 2015-08-05 meeting notes (Moehrke, John (GE Healthcare))<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 6 Aug 2015 15:29:16 +0000<br>
From: "Moehrke, John (GE Healthcare)" <<a href="mailto:John.Moehrke@med.ge.com">John.Moehrke@med.ge.com</a>><br>
To: Josh Mandel <<a href="mailto:Joshua.Mandel@childrens.harvard.edu">Joshua.Mandel@childrens.harvard.edu</a>>, "Maxwell,<br>
        Jeremy (OS/OCPO)" <<a href="mailto:Jeremy.Maxwell@hhs.gov">Jeremy.Maxwell@hhs.gov</a>><br>
Cc: "<a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a>"<br>
        <<a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a>><br>
Subject: Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes<br>
Message-ID:<br>
        <<a href="mailto:B025BFE1B1C0AA4596EEF6AA85D6F499541188BA@CINURCNA01.e2k.ad.ge.com">B025BFE1B1C0AA4596EEF6AA85D6F499541188BA@CINURCNA01.e2k.ad.ge.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
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).<br>
<br>
<br>
<br>
John<br>
<br>
<br>
<br>
From: Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net">openid-specs-heart-bounces@lists.openid.net</a>] On Behalf Of Josh Mandel<br>
Sent: Thursday, August 06, 2015 10:16 AM<br>
To: Maxwell, Jeremy (OS/OCPO)<br>
Cc: <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><br>
Subject: Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes<br>
<br>
<br>
<br>
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.<br>
<br>
<br>
<br>
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).<br>
<br>
<br>
<br>
 - J<br>
<br>
<br>
<br>
<br>
<br>
On Thu, Aug 6, 2015 at 10:57 AM, Maxwell, Jeremy (OS/OCPO) <<a href="mailto:Jeremy.Maxwell@hhs.gov">Jeremy.Maxwell@hhs.gov</a>> wrote:<br>
<br>
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?<br>
<br>
<br>
<br>
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.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
From: <a href="mailto:jmandel@gmail.com">jmandel@gmail.com</a> [mailto:<a href="mailto:jmandel@gmail.com">jmandel@gmail.com</a>] On Behalf Of Josh Mandel<br>
Sent: Thursday, August 06, 2015 10:52 AM<br>
To: Aaron Seib<br>
Cc: Maxwell, Jeremy (OS/OCPO); jim kragh; Debbie Bucci; <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><br>
<br>
<br>
Subject: Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes<br>
<br>
<br>
<br>
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?<br>
<br>
<br>
<br>
  -J<br>
<br>
<br>
<br>
On Thu, Aug 6, 2015 at 10:16 AM, Aaron Seib <<a href="mailto:aaron.seib@nate-trust.org">aaron.seib@nate-trust.org</a>> wrote:<br>
<br>
I am not sure I even understand the statement highlighted in yellow accurately yet.  J<br>
<br>
<br>
<br>
That might be a start.  Predetermined choice token means?  Confidential token choice?<br>
<br>
<br>
<br>
Aaron<br>
<br>
<br>
<br>
Aaron Seib<br>
<br>
 <<a href="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=" rel="noreferrer" target="_blank">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=</a>> NATE, CEO<br>
<br>
@CaptBlueButton<br>
<br>
(o) <a href="tel:301-540-2311" value="+13015402311">301-540-2311</a><br>
<br>
(m) <a href="tel:301-326-6843" value="+13013266843">301-326-6843</a><br>
<br>
<br>
<br>
<br>
<br>
From: Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net">openid-specs-heart-bounces@lists.openid.net</a>] On Behalf Of Maxwell, Jeremy (OS/OCPO)<br>
Sent: Thursday, August 6, 2015 9:41 AM<br>
To: jim kragh; Debbie Bucci<br>
<br>
<br>
Cc: <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><br>
Subject: Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes<br>
<br>
<br>
<br>
<br>
<br>
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.<br>
<br>
<br>
<br>
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.<br>
<br>
<br>
<br>
<br>
<br>
From: Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net">openid-specs-heart-bounces@lists.openid.net</a>] On Behalf Of jim kragh<br>
Sent: Wednesday, August 05, 2015 8:28 PM<br>
To: Debbie Bucci<br>
Cc: <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><br>
Subject: Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes<br>
<br>
<br>
<br>
Thanks for sharing,...  informative and constructive in reaching the patient end point.<br>
<br>
<br>
<br>
May all have a nice evening!<br>
<br>
<br>
<br>
On Wed, Aug 5, 2015 at 3:26 PM, Debbie Bucci <<a href="mailto:debbucci@gmail.com">debbucci@gmail.com</a>> wrote:<br>
<br>
Attendees:<br>
<br>
Eve Maler<br>
<br>
Justin Richer<br>
<br>
Josh Mandel<br>
<br>
Adrian Gropper<br>
<br>
Thomas Sullivan<br>
<br>
Debbie Bucci<br>
<br>
<br>
<br>
We have decided to delineate between mechanical and semantic scope docs.<br>
<br>
<br>
<br>
For the PCP <-> PHR use case:<br>
<br>
<br>
<br>
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.<br>
<br>
<br>
<br>
There is one basic mechanical Oauth  generic flow that occurs twice in the use case.<br>
<br>
<br>
<br>
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.<br>
<br>
<br>
<br>
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.<br>
<br>
<br>
<br>
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.<br>
<br>
<br>
<br>
Corrections/updates appreciated.<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a> <<a href="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=" rel="noreferrer" target="_blank">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=</a>><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart</a> <<a href="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=" rel="noreferrer" target="_blank">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=</a>> &d=BQICAg&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=z8Y3dTNXfeIHTJOVrFI1AbuFBtR0weR9H30VsLiwJME&s=8XR3NIglMh-Fdi8Tn07unv1E52KNE5BIepwuZRF7Vr0&e=<br>
<br>
<br>
<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150806/1e18d9bd/attachment.html" rel="noreferrer" target="_blank">http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150806/1e18d9bd/attachment.html</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: smime.p7s<br>
Type: application/pkcs7-signature<br>
Size: 6966 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150806/1e18d9bd/attachment.p7s" rel="noreferrer" target="_blank">http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150806/1e18d9bd/attachment.p7s</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Openid-specs-heart Digest, Vol 32, Issue 41<br>
**************************************************<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><font color="#330099">Danny van Leeuwen<br>617-304-4681<br></font><div><b><font color="#330099"><br></font></b><div><b><font color="#330099">Blog <a href="http://www.health-hats.com/" target="_blank">www.health-hats.com</a> <i><span style="font-size:8pt;font-family:'Arial Black',sans-serif">discovering the magic levers of best health</span></i></font></b></div></div><div><b><font color="#330099">Twitter </font></b><b><font color="#330099"><i><span style="font-size:8pt;font-family:'Arial Black',sans-serif">@healthhats</span></i></font></b></div></div>
</div></div>