<div dir="ltr"><div>From the patient's perspective, the 9 realities of Registration, Delegation, Payer Eligibility, Consent Directives, Patient Portal, Patient Discovery for HIE directories, Secure and Insecure Messaging, and Accounting for Disclosures are likely to be a constant across all of the use-cases. As we consider the various use-cases, can we please look at this from the perspective of the patient first, and the developers second.<br><br></div><div>Will a combination of OAuth and UMA make sense to patients faced with the 9 realities at each and every service provider?<br></div><div><br></div>Adrian<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 1, 2015 at 3:50 PM, Justin Richer <span dir="ltr"><<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Of the set, I prefer option #2. That is to say, if we can solve it simply with OAuth, then let’s just do an OAuth version of it. If you’ve got a way to apply UMA to it, or it requires UMA, then sure, do so. But I think that we should simplify the alice-to-alice case to vanilla OAuth wherever we can.<div><br></div><div>Remember, this is for understanding specific use cases, and not for the work that HEART is doing overall. We’ll still produce profiles for OAuth and UMA (and the various bits and bobs that go with that). The question is when to apply which one to our use cases to understand what’s happening.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div> — Justin</div></font></span><div><br><div><blockquote type="cite"><div><div class="h5"><div>On Jun 29, 2015, at 5:12 PM, Josh Mandel <<a href="mailto:Joshua.Mandel@childrens.harvard.edu" target="_blank">Joshua.Mandel@childrens.harvard.edu</a>> wrote:</div><br></div></div><div><div><div class="h5"><div dir="ltr"><span style="font-size:12.8000001907349px">On today's call we discussed a use case where a patient can help connect her patient portal (a.k.a. her EHR account) account to an external PHR. This is a great, common use case that we know we could handle with either "vanilla" OAuth, or UMA, or both. Of course, software systems need to know, up front, whether they'll be talking vanilla OAuth or UMA -- because the wire protocols are different.</span><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">The question: When HEART encounters a use case like this, by which principle(s) we should select vanilla OAuth vs. UMA? Some examples of principles (to stimulate discussion) might be:<div><br></div><div><b>Example principle #1: "Do all the things"</b><br></div><div>We should produce two profiles each time this kind of situation comes up: one describing how to do it with vanilla OAuth, and one describing how to do it with UMA. This provides maximum flexibility for implementers with different needs/contexts. </div><div><br></div><div><b>Example principle #2: "KISS"</b><b><br></b></div><div>Any time vanilla OAuth can handle a use case, we should use vanilla OAuth. Save UMA for when it's required. This provides a simpler environment with fewer moving parts and stronger out-of-the-box software library support. </div><div><br></div><div><b>Example principle #3: "UMA everywhere"</b><b><br></b></div></div><div style="font-size:12.8000001907349px">Use UMA across the board, and avoid vanilla OAuth. Since UMA handles a more general set of use cases, and there's value in consolidation, UMA should be the preferred option in all cases. This way, implementers only ever need to do one (very general) thing.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">(I've tried to state these examples neutrally, but I must admit bias in favor of #2. Does that come through?)</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Looking forward to discussion,</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">  -Josh</div></div></div></div><span class="">
_______________________________________________<br>Openid-specs-heart mailing list<br><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br></span></div></blockquote></div><br></div></div><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></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><font size="1"><br><font size="2">Ensure Health Information Privacy. Support Patient Privacy Rights.<br></font></font><span style="font-size:11pt"><font size="1"></font></span><font size="2"><a href="http://patientprivacyrights.org/donate-2/" target="_blank"><font color="blue"><u>http://patientprivacyrights.org/donate-2/</u></font></a><font color="blue"><u>  </u></font></font><span style="font-size:11pt"></span><span style="font-size:11pt"></span><span style="font-size:11pt"><font size="1"> <br></font><div></div></span><br></div></div>
</div>