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

Tue Aug 2 15:57:49 UTC 2016

I am missing something.  

FHIR is a layer of abstraction from the actual way the data is stored by the RS.  A resource set is a view of that abstraction layer.  I am not sure I see a burden if it is done correctly.  That has been one of the reported benefits of using FHIR – the ability to get only the data you need for the use case your consumer wants to solve.  The notion of minimum necessary.

What am I missing.  Either I was sold on hype that hasn’t materialized yet or I don’t understand the question.

Toward the end you say that HEART can certainly profile subsets of FHIR.  Are you just indicating a preference to have the views being created by the HEART side of the equation?  Doesn’t that extinguish the minimum necessary benefits that FHIR could support?  

Aaron Seib, CEO

@CaptBlueButton 

 (o) 301-540-2311

(m) 301-326-6843

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Adrian Gropper
Sent: Tuesday, August 02, 2016 11:47 AM
To: Debbie Bucci
Cc: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Alice's health resource set

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/> http://patientprivacyrights.org/donate-2/ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160802/371bba22/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3198 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160802/371bba22/attachment.jpg>