[Openid-specs-heart] Resources vs Resource sets

Wed Jul 27 18:25:27 UTC 2016

I don't understand why we would even ask the consumer what their preference is if they can't change a default used by a Covered Entity?
That is the entire point.

Aaron Seib
The trick to establishing trust is to avoid all tricks.  Especially tricks on yourself.

-------- Original message --------
From: Adrian Gropper <agropper at healthurl.com> 
Date: 7/27/16  1:22 PM  (GMT-05:00) 
To: "Salyards, Kenneth (SAMHSA/OPPI)" <Kenneth.Salyards at samhsa.hhs.gov> 
Cc: HEART List <openid-specs-heart at lists.openid.net> 
Subject: Re: [Openid-specs-heart] Resources vs Resource sets 

Adding my comments inline to Ken's...

On Wednesday, July 27, 2016, Salyards, Kenneth (SAMHSA/OPPI) <Kenneth.Salyards at samhsa.hhs.gov> wrote:

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 - KenAgree. They are metadata that can be specified and attached to any FHIR resource. - AG

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.Disagree. An institution can suggest or default a Confidtiality Code for any particular FHIR resource but the patient has full authority to change it if the institution provides that functionality. - AG

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

-         
yesAgree - AG 

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?I don't understand what "apply" means. An UMA resource server can offer Confidentiality Codes as a scope just like any other scope. The only difference is that "write" is obvious whereas a confidentiality code must link to a well known standard that the RS and AS can both reference. - AG 

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 workAgree with Eve. The availability of the codes or any other scoping tool is for the convenience of the patient in setting policy. - AG 

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 incompleteSupport for standardized metadata when available, in general, is a critical feature for all of UMA. I think this is both an UMA and a HEART imperative. - AG

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.See above. I think this is an UMA issue more than just HEART - AG
Adrian

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 Sydney, London, and Paris!

On Wed, Jul 27, 2016 at 8:51 AM, John Moehrke <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> 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
(m)
301-326-6843

From: John Moehrke [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> 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

(m)
301-326-6843

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