[Openid-specs-heart] Resources vs Resource sets

Wed Jul 27 16:49:13 UTC 2016

See my thoughts below:

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Eve Maler
Sent: Wednesday, July 27, 2016 12:25 PM
To: John Moehrke
Cc: HEART List
Subject: Re: [Openid-specs-heart] Resources vs Resource sets

Eliding older parts of this thread:

If I understand right:

  *   Confidentiality codes are not deterministically applicable to FHIR resources.

-          They are applicable to any data container - Ken

  *   Patients are not trustworthy for applying confidentiality codes to FHIR resources because they could get them wrong.

-          I agree. Patients define their policy. It is an enforcement engine (AP/RS) that is responsible for applying policy correctly.

  *   FHIR API servers (UMA RS) are trustworthy to be authoritative for applying confidentiality codes to FHIR resources.

-          yes

  *   Therefore:

     *   We posit that it makes sense for FHIR API servers as UMA resource servers to apply confidentiality codes to FHIR resources during the process of UMA resource set registration at UMA authorization servers. – does this mean at the point of sharing?
     *   We think UMA authorization servers could use this extra confidentiality code information to help patients as UMA resource owners to set sharing policy in a convenient fashion. (Concrete examples here would be good!) – I think this is reverse to how it would work
     *   It's an open question where extending the UMA resource set registration messaging flow is an in-scope activity that we in HEART should be taking on. – I think it would be in-scope for without this the process would be incomplete
If we conclude for the last bullet that it's not in scope for HEART, by the way, it's still entirely possible for an extension to be written and for a community to get implementation experience with it. And then HEART could consider adding that spec to its charter at some appropriate time.

Eve Maler
ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
ForgeRock Summits and UnSummits are coming to<http://summits.forgerock.com/> Sydney, London, and Paris!

On Wed, Jul 27, 2016 at 8:51 AM, John Moehrke <johnmoehrke at gmail.com<mailto:johnmoehrke at gmail.com>> wrote:

Hi Aaron

I think you need something in the "beyond" category. Confidentiality is rather blunt.

In the beyond category we could have dynamically created scopes. Scopes that could be invented on your RS, communicated to the UMA authority to be used in authorization statements. In this way the patient could be creative to create scopes as complex as they want, tagging their controlled PHR data how they want. This could be many scopes that overlap as desired by the patient. This kind of tag would be a security "compartment" kind of tag. (Somewhat like a http RESTful compartment).

Note that in this solution I am still putting the responsibility of tagging in the RS, and relying on RS magic. It is simply more dynamic. This dynamic function is hard. Lets walk first.

John

On Jul 27, 2016 10:28 AM, "Aaron Seib" <aaron.seib at nate-trust.org<mailto:aaron.seib at nate-trust.org>> wrote:
Thank you John.

I am still a little dull in the drawer with the broken knives but I think I get it now.

Before I trick myself into thinking I got it let me ask a question that goes one layer deeper (I am actually working on using this today for an Autism Pilot so bear with me if I am being selfish with the Task Force’s time) .

The very narrow use case that I am dealing with is the sharing of data between a consumer and a research registry.  For context – we are making a consumer controlled PHI aggregator app available for free to participants in the project (family caregiver(s), the proband and their siblings).  We are striving to make it easy for the family to gather their EHR data (today all we can support is Upload of a CDA and Transport via direct).  They are free to do with it what they will.  If they choose to do so they can mark the data as okay to share with researchers.

When I look at the classification codes I am trying to deduce what codes I would use to convey that.  In other words, if all their data was initially tagged as “V” and via the UI they could change it to “N” we could constrain what is shared with the research registry to only be that data that has a confidentiality code marked with an “N”.  But that seems sort of a strained use so I am wondering if there is some other standard that would make more sense in that kind of scenario.

Again, I want to be aligned with the standard but not sure how best to do so.  Worse, I may be trying to use the wrong standard and there is a better one to use.  Or I am putting too much thought into it and a binary value is sufficient for this use case?

Aaron Seib, CEO
@CaptBlueButton
 (o) 301-540-2311<tel:301-540-2311>
(m) 301-326-6843<tel:301-326-6843>
[cid:image001.jpg at 01D1E804.BA118A80]<http://nate-trust.org>

From: John Moehrke [mailto:johnmoehrke at gmail.com<mailto:johnmoehrke at gmail.com>]
Sent: Wednesday, July 27, 2016 10:50 AM
To: Aaron Seib
Cc: HEART List; Nancy Lush
Subject: RE: [Openid-specs-heart] Resources vs Resource sets

Yes it is a big knife today. The codes are based on privacy harm evaluation. They are not specific to CE to CE; although that is the most use. Yes all sensitive topics go into R. So yes you can't use this system more finegrain.

We can get this start.... And improve later...

Later we can add sensitivity tags. Or compartment tags. Or....

John

On Jul 27, 2016 9:20 AM, "Aaron Seib" <aaron.seib at nate-trust.org<mailto:aaron.seib at nate-trust.org>> wrote:
John

I follow you now and I think Mr. Lush’s suggestion would be fruitful and help clarify some of the things I am struggling with at this current point in time.

“The point is to draw a line and declare the side of the line you are going to solve.”  I think that you’ve diagnosed my confusion precisely.  I’d like to clearly understand what Consumer Directed means in the context of HEART specifically with regards to the use of confidentiality codes.

Just to be explicit - as I may be off the rails in my understanding already – where we make reference to confidentiality codes I am assuming we are referring to http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html

Is that a bad inference?  My read of the description of these codes seems to indicate that they were devised in relation to the exchange between Covered Entities, right?

I am assuming that on the RS side these codes would be applied based on policy interpretation of the Covered Entity and what we’ve been talking about is that for consumer directed exchange it is the consumer who would define a rule that said in effect When sharing my PHI with recipient X – the disclosing system can share anything that has a classification code assigned by the CE in (U, L, M, N) but not in (R, V).  When sharing with my PCP or consumer app you can share anything that has a classification in (U, L, M, N, R, V).

I feel like that is a sophomoric understanding but I hope putting it out their as what I am able to understand at this point might be helpful to improving everyone’s understanding.

An example of where I get confused is when there is a reference to Alice not wanting to share her HIV related PHI.  I don’t follow how this approach would get to that level of granularity as the classification system doesn’t differentiate between V’s that are classified that way because it is related to HIV versus other V’s that are classified that way because it relates to domestic violence, for example.

I am not the sharpest knife in the drawer but I really share this in the hopes that it will be helpful in getting clarity around the discussion for others in the same boat as me.

Thank you for your patients.

Aaron

Aaron Seib, CEO
@CaptBlueButton
 (o) 301-540-2311<tel:301-540-2311>
(m) 301-326-6843<tel:301-326-6843>
[cid:image001.jpg at 01D1E804.BA118A80]<http://nate-trust.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160727/bad5980e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3204 bytes
Desc: image001.jpg
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160727/bad5980e/attachment.jpg>