[Openid-specs-heart] Alice's health resource set

[Adrian Gropper]

Debbie,

It's very important for both HEART and the UMA folks to be clear about
this.

I don't want either UMA or HEART to create any "burden" on the RS unless
there's a clear problem we're fixing. Sticking as close to FHIR as possible
seems to be a way that we can avoid an extra burden on the RS. It places
the burden of capturing and interpreting Alice's policies entirely on the
authorization server. The RS could make Alice's AS job much easier by
supporting Confidentiality Codes and other metadata as part of the scope
process but that would certainly be an added burden on the RS and should be
optional.

Introducing a HEART profile for some particular resource set that is not
just plain FHIR seems to me to be a clear burden to the RS. Now they will
have two overlapping standards to coordinate: FHIR and HEART, both talking
about resources. Interoperability will also suffer because the rule is "be
strict in what you offer and liberal in what you accept". A health RS
strictly has to offer FHIR for all sorts of reasons including apps like
SMART and participation in vendor networks like CommonWell, and directed
exchange for the Precision Medicine Initiative.

For the other side of interoperability, the HEART RS must be liberal in
what kinds of AS it accepts in order to make patient-directed exchange with
HIPAA, non-HIPAA, 42CFR, Things, decision support, and all other clients
willing to play by FHIR rules interoperable.

>From the AS perspective, HEART can certainly profile subsets of FHIR, DAF,
OpenID Connect, WebFinger, and other standards in order to improve the user
experience but these would be optional to any particular RS and would not
limit interoperability.

Adrian

On Tue, Aug 2, 2016 at 10:52 AM, Debbie Bucci <debbucci at gmail.com> wrote:

> Resource Set  - what purpose it might serve.
>
> Mind you - I don't know the thinking behind the UMA spec - but In the
> federated authentication environment when you are dealing with hundreds if
> not thousands for partners, a methods to group claims together has evolved
> to help ease the burden on the backend  for those having to configure
> release policies for each and every partner.   The ability for a RS to
> define resource sets that makes sense for their business - may have a
> similar effect.
>
>>
>>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>


-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160802/26354db8/attachment.html>