[Openid-specs-heart] Resources vs Resource sets

[Adrian Gropper]

Debbie,

Thanks for giving me another opportunity to explain what's at stake for all
of us.

As far as the substantive point of this interchange, it doesn't matter if
only 5% or 10% of the AS are independent - it will be enough to make every
authorization service patient-centered and make transparency and
longitudinal health records the norm for all of us.

I don't understand why any AS operated by an RS matters in the HEART
context. It's entirely captive and not an interoperability issue. The only
AS that matters to HEART is the one a patient has a choice over.

Adrian

On Sunday, July 31, 2016, Debbie Bucci <debbucci at gmail.com> wrote:

>
> Adrian -
>
> My sincere apologies if I offended you.   I just voiced a personal
> opinion.  That was not the point of the paragraph though - I failed to
> state the point I was trying to make - sorry to send you off on a tangent.
>
> Totally agree with the following statement.
>
> The degree to which HEART chooses to profile particular subsets of FHIR
> has nothing to do with whether a person chooses to outsource his / her
> authorization server. It simply has to do with the person's user experience
> in setting policies that HIPAA-covered-entities and FTC-covered-entities
> and 42-CFR-covered-entities as resource servers will need to follow. In
> some cases, the resource servers will voluntarily take advantage of the
> FHIR standard while in others it will not apply at all.
>
>
> I do not see the rise of totally independent AS.   I see it more as a
> federate authorization model (kind of what MIT is thinking about with
> Datahub - DUMA - PDS).  All RS will have their own AS processes to deal
> with - even if trusted, most likely the sharing preference/consent/ROI
> would be replicated to the RA AS to manage ongoing requests.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160731/ec4e70df/attachment.html>