[Openid-specs-heart] Principles for selecting "Vanilla" OAuth vs. UMA

Adrian Gropper agropper at healthurl.com
Thu Jul 2 03:43:25 UTC 2015


I'd like to add a few more to the typical health service encounter: Co-pays
with or without a Health Spending Account and receiving a
digital prescription when you are asked which pharmacy to send it to
without knowing the relative price of the drug. In my experience, a 60%
difference in price for medicines costing hundreds of dollars is common.

Let's also keep in mind that this list of a dozen or more patient realities
is repeated for many of the relying parties a patient deals with. Also,
please note that I've not even touched the barrage of other questions such
as allergies, primary care physician and emergency contact info.

I hope we can all step back for a bit from the institutional perspective
and consider what we could do to actually make the HEART profiles serve the
patient first and foremost. For most use-cases, UMA enables us to serve the
patient perspective in ways that OAuth can't. UMA is young, but in these
interesting times we need to help it grow up quick.

Adrian

On Wednesday, July 1, 2015, Adrian Gropper <agropper at healthurl.com> wrote:

> 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.
>
> Will a combination of OAuth and UMA make sense to patients faced with the
> 9 realities at each and every service provider?
>
> Adrian
>
> On Wed, Jul 1, 2015 at 3:50 PM, Justin Richer <jricher at mit.edu
> <javascript:_e(%7B%7D,'cvml','jricher at mit.edu');>> wrote:
>
>> 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.
>>
>> 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.
>>
>>  — Justin
>>
>> On Jun 29, 2015, at 5:12 PM, Josh Mandel <
>> Joshua.Mandel at childrens.harvard.edu
>> <javascript:_e(%7B%7D,'cvml','Joshua.Mandel at childrens.harvard.edu');>>
>> wrote:
>>
>> 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.
>>
>> 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:
>>
>> *Example principle #1: "Do all the things"*
>> 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.
>>
>> *Example principle #2: "KISS"*
>> 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.
>>
>> *Example principle #3: "UMA everywhere"*
>> 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.
>>
>> (I've tried to state these examples neutrally, but I must admit bias in
>> favor of #2. Does that come through?)
>>
>> Looking forward to discussion,
>>
>>   -Josh
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> <javascript:_e(%7B%7D,'cvml','Openid-specs-heart at lists.openid.net');>
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> <javascript:_e(%7B%7D,'cvml','Openid-specs-heart at lists.openid.net');>
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>
>
> --
> Adrian Gropper MD
> Ensure Health Information Privacy. Support Patient Privacy Rights.
> *http://patientprivacyrights.org/donate-2/*
> <http://patientprivacyrights.org/donate-2/>
>
>

-- 
Adrian Gropper MD
Ensure Health Information Privacy. Support Patient Privacy Rights.
*http://patientprivacyrights.org/donate-2/*
<http://patientprivacyrights.org/donate-2/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150701/5307fa4e/attachment.html>


More information about the Openid-specs-heart mailing list