[Openid-specs-heart] Public FHIR Endpoints - are there any OAUTH endpoints to register and test

Adrian Gropper agropper at healthurl.com
Tue Jul 21 14:44:00 UTC 2015


I will take a shot at a diagram that can be used to map the Argonaut,
SMART, and HEART Use Cases.

- Adrian

On Tue, Jul 21, 2015 at 10:22 AM, Aaron Seib <aaron.seib at nate-trust.org>
wrote:

> Yes, agile.  A handy def for agile might be:
>
>
>
>    1. - *Agile* software development is a group of software development
>    methods in which requirements and solutions evolve through collaboration
>    between self-organizing, cross-functional teams.
>
>
> Perhaps, I am suggesting, we evolve the description of the requirements
> reusing what Argonaut has solved for to more explicitly delineate the
> greener-field aspects where UMA et al. compliment the solution space ?
>
> Sent from my Verizon Wireless 4G LTE smartphone
>
>
> -------- Original message --------
> From: Debbie Bucci
> Date:07/21/2015 9:47 AM (GMT-05:00)
> To: Aaron Seib
> Cc: Adrian Gropper , Justin Richer , openid-specs-heart at lists.openid.net
> Subject: Re: [Openid-specs-heart] Public FHIR Endpoints - are there any
> OAUTH endpoints to register and test
>
> Eve posted a great visual a few weeks back.  Both UMA and OpenID Connect
> are layered on TOP of OAuth.
>
> We need to start somewhere and focusing on the base seems the appropriate
> place to start from my POV.
>
> I personally need to build to see...in order to understand the
> changes/adjustments that may need to be made to the base as we build upon
> it.
>
> Agile right?
> On Jul 21, 2015 8:51 AM, "Aaron Seib" <aaron.seib at nate-trust.org> wrote:
>
>> I am in the same boat as Justin – Dragon and I had a sidebar about this a
>> week or so back and came to the same conclusion.
>>
>>
>>
>> The Use case should determine what is employed.  I am a visual guy – if
>> we had a set of concentric circles OAUTH would be the center, a band of
>> both OAUTH and UMA would surround that and then UMA would be the outer band.
>>
>>
>>
>> Probably not helpful without some arrows that label the use case
>> supported by each band but that is the way I have pictured it.  I am not
>> sure that visualization stands up as I don’t know that you ever have a use
>> case with UMA in isolation of OAUTH.  Can someone correct me?
>>
>>
>>
>> It might help to spell out a specific use case in the legacy language of
>> disclosure based on push:
>>
>>
>>
>> 1.      EMR1 sends protected health data to PHRA;
>>
>> 2.      Consumer using PHRA sends content from (1) to EMR2
>>
>> 3.      EMR2 receives content and its workflow can differentiate between
>> PGHD and data that is unchanged since it left EMR1.
>>
>>
>>
>> Could anyone on this thread convert this transaction into the OAUTH\UMA
>> domain so that a layman would understand?
>>
>>
>>
>>
>>
>> Aaron Seib, CEO
>>
>> @CaptBlueButton
>>
>>  (o) 301-540-2311
>>
>> (m) 301-326-6843
>>
>> <http://nate-trust.org>
>>
>>


-- 
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/20150721/fd095252/attachment.html>


More information about the Openid-specs-heart mailing list