[Openid-specs-heart] Resources vs Resource sets

Aaron Seib aaron.seib at nate-trust.org
Wed Jul 27 16:29:10 UTC 2016


This is much clearer for a bone-head like me.  

 

Just to be explicit – I find it very helpful to have the scopes listed out as read, write and share.  

 

Can you help me understand how to add a layer of the onion from the threads.  I sware I am not being ignorant on purpose.

 

When folks talk about Alice opting out not to share her HIV related information – how does that come into play?  Does one of the AP’s manage the process of defining what is deemed related to HIV and the user applies the Scope of Sharing = N to this “profile”?

 

Thank you for your patients.

 

Aaron

 

Aaron Seib, CEO

@CaptBlueButton 

 (o) 301-540-2311

(m) 301-326-6843



 

From: Salyards, Kenneth (SAMHSA/OPPI) [mailto:Kenneth.Salyards at SAMHSA.hhs.gov] 
Sent: Wednesday, July 27, 2016 11:25 AM
To: John Moehrke; Aaron Seib
Cc: HEART List
Subject: RE: [Openid-specs-heart] Resources vs Resource sets

 

Here is my take:

 

I thought I would take the spec (url Eve provided in an email) and create a diagram based on my understanding. The spec refers to the following:

OP: OpenID Provider which is a specialized AS

AS: Authorization Server

AP: attribute provider -> function as third-party resource server

Resource set: one or more resources that the resource server manages as a set

Example from the spec: Photo album – presumably contains one or more pictures (notice doesn’t limit pictures)

                        Scopes: e.g., viewing slideshow; printing the album

Example (mine): Health Record or Health Information or pick your own name which contains all FHIR resources available for a patient (user) (notice doesn’t limit number of resources)

                        Scopes: e.g., read; write; share (these scopes are driven by policy)

 


	
		
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


In this example you have an AP with the responsibility (scope) to read health information and another AP that shares information based on the User policy they set. No need to define the how, the endpoints would be defined and the User policies drive how each of these APs are implemented. I hope this makes it easier to separate concerns so we do not have to boil the ocean trying to define a bunch of details that are defined elsewhere through standards. Ken

 

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of John Moehrke
Sent: Wednesday, July 27, 2016 10:50 AM
To: Aaron Seib
Cc: HEART List
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

 <http://nate-trust.org> 

 

From: nlush at lgisoftware.com [mailto:nlush at lgisoftware.com] 
Sent: Wednesday, July 27, 2016 7:41 AM
To: John Moehrke
Cc: Aaron Seib; HEART List
Subject: Re: [Openid-specs-heart] Resources vs Resource sets

 

Yes John
Perhaps heart could specify the objectives - I could write the first pass if  you like
Then FHIR group can explain the best way to achieve- hopefully using standards already specified.

On 2016-07-26 20:39, John Moehrke wrote:
> Aaron 
> 
> My point with "magic" is to clearly say there is a big problem to
> solve, but to say this problem is not what HEART should focus on.
> Trying to solve both is what is causing lots of churn, and keeping
> progress from happening. 
> 
> DS4P is one solution to magic. So is total control by the patient...
> That is when the patient totally controls the RS they can put tags on
> themselves. A UI by the RS might be offered too, for example my doctor
> gives me this kind of control through their patient portal... Many
> other solutions are possible. ...  
> 
> The point is to draw a line and declare the side of the line you are
> going to solve. The other side is a dependency... 
> 
> John 
> 
> On Jul 26, 2016 4:28 PM, "Aaron Seib" <aaron.seib at nate-trust.org>
> wrote:
> 
>> I am getting foggy on my understanding of where things are heading.
>> I follow the notion that magic will happen on the resource server
>> side that will tag data using the confidentiality codes. What I
>> don’t follow is who does the coding for that informs this magic on
>> how it should work?
>> 
>> It may be a sin amongst this crowd but I am thinking of how DS4P is
>> designed. There is a code set that gets populated by some
>> “authority”” and the software says – oh this code is found
>> in my table of HIV related codes and I tag it as HIV.
>> 
>> For me the entire DS4p scheme falls down because no one has the
>> authority to say if you populate your Code sets with these values
>> then you follow the clients preference you are in a safe harbor and
>> no one can ding you for sharing when you shouldn’t.
>> 
>> John – where you say this should include the patient UX am I to
>> understand that for a given code set the every patient will have the
>> opportunity to configure what is in that code set of things that get
>> tagged with a confidentiality code?
>> 
>> I think that is an improvement over DS4P but it still hinges on the
>> question – am I as the RS disclosing a patient’s data doing so
>> in a safe harbor if I allow the patient to customize what they
>> consider sensitive or not?
>> 
>> Or is that the bit of Harry Potter magic that takes place? Or
>> should we be explicit and say that it is another assumption about
>> the CEs in the role of discloser being compliant if they allow the
>> patient to configure the LOV to aligg with their own sensitivities?
>> 
>> Aaron Seib, CEO
>> 
>> @CaptBlueButton
>> 
>> (o) 301-540-2311 [1]
>> 
>> (m) 301-326-6843 [2]
>> 
>> [3]
>> 
>> FROM: Openid-specs-heart
>> [mailto:openid-specs-heart-bounces at lists.openid.net] ON BEHALF OF
>> John Moehrke
>> SENT: Tuesday, July 26, 2016 4:36 PM
>> TO: Eve Maler
>> CC: HEART List
>> SUBJECT: Re: [Openid-specs-heart] Resources vs Resource sets
>> 
>> So. I think best step forward is to say that some magic will happen
>> on the resource server side that will tag data using the
>> _confidentiality codes. This should include patient UX that aids
>> with this setting. Yes it is known today this is poorly done.
>> Default is N when it is not set.
>> 
>> But setting the tags on the RS is not in HEART scope. It is a
>> precondition.
>> 
>> UMA will control authorization to the various _confidentiality
>> levels.
>> 
>> UMA can also control resource types.
>> 
>> UMA can also control specific instances of a resource.
>> 
>> Nice clean separation.
>> 
>> John
>> 
>> On Jul 26, 2016 2:56 PM, "Eve Maler" <eve.maler at forgerock.com>
>> wrote:
>> 
>> No, sorry, I meant UMA resource set types -- semantic types, not
>> security labels. Yikes.
>> 
>> 
> https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html#resource-set-desc
>> [4]
>> 
>> In other words, we should be defining a profile that literally
>> standardizes UMA resource set types, because that's the only thing
>> in UMA that makes sense to standardize.
>> 
>> I promise never to leave off a qualifying name again, cross my
>> heart. (Uh, no pun intended.)
>> 
>> Eve Maler
>> ForgeRock Office of the CTO | VP Innovation & Emerging Technology
>> Cell +1 425.345.6756 [5] | Skype: xmlgrrl | Twitter: @xmlgrrl
>> FORGEROCK SUMMITS AND UNSUMMITS are coming to [6] SYDNEY, LONDON,
>> AND PARIS!
>> 
>> On Tue, Jul 26, 2016 at 12:26 PM, John Moehrke
>> <johnmoehrke at gmail.com> wrote:
>> 
>> You are reinventing the securityLabels solution that already exists
>> and that I have recommended. It is frustrating that this committee
>> can't focus in what UMA does and leverage the work others have
>> already put in place.
>> 
>> John
>> 
>> On Jul 26, 2016 12:06 PM, "Eve Maler" <eve.maler at forgerock.com>
>> wrote:
>> 
>> If we have Alice check off the FHIR resources she wants to share
>> individually and not share them as a prepackaged "first visit"
>> bundle, then a number of things get a bit easier for the services
>> involved (though the "HIV problem" doesn't get solved).
>> 
>> We can next set about defining UMA resource sets and their attendant
>> scopes for that list of FHIR resources. Note that the scopes _can_
>> be unique per resource set, but need not be.
>> 
>> I recommend that we plan for these to be profiled UMA resource set
>> TYPES. Alice's instance of a medication list type would differ from
>> Carol's, which would differ from David's, and so on.
>> 
>> Eve Maler
>> ForgeRock Office of the CTO | VP Innovation & Emerging Technology
>> Cell +1 425.345.6756 [5] | Skype: xmlgrrl | Twitter: @xmlgrrl
>> FORGEROCK SUMMITS AND UNSUMMITS are coming to [6] SYDNEY, LONDON,
>> AND PARIS!
>> 
>> On Mon, Jul 25, 2016 at 7:19 PM, Nancy Lush <nlush at lgisoftware.com>
>> wrote:
>> 
>> Hello all,
>> 
>> My sense is that we want to start with a simple example. Like,
>> Alice can choose which resources she wants to share. Those can be
>> from the list Debbie displayed today or the list I sent – or
>> whatever the final list turns out to be. (The list can be changed
>> later.) But that list is a list of ‘FHIR Resources’. Alice can
>> choose to share either all, or she can specify which in the list she
>> wishes to share. (I think this is consistent with Adrian’s most
>> recent ‘b’ point.)
>> 
>> While we can have resource sets, I don’t think we need to confuse
>> the conversation with that yet.
>> 
>> Also, we have talked about confidentiality codes and the desire to
>> have Alice share her conditions, but exclude her HIV condition. I
>> think as a group we would like to be able to do that, but because it
>> is confusing it takes us off track. Just temporarily, let’s skip
>> that detail.
>> 
>> If we start with Alice’s ability to share the FHIR resources, we
>> can work that through the more technical issues, and reach a point
>> where we agree. We can then add additional detail on top of that.
>> 
>> As a group we all come from different places, often each of those
>> very different places are technical in nature. As a result, one
>> term can have different meanings to each individual. I think we
>> are close. The next step would be to define the flow for this, then
>> bring it back to the team for review.
>> 
>> -Nancy
>> 
>> NANCY LUSH
>> 
>> nancy.lush at lgisoftware.com
>> 
>> LUSH GROUP, INC
>> 
>> Office: (401) 423-9111 [7]
>> 
>> 28 Narragansett Ave
>> 
>> PO Box 651
>> 
>> www.lgisoftware.com [8]
>> 
>> Cell:(401) 965-9347 [9]
>> 
>> Jamestown, RI 02835
>> 
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart [10]
>> 
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart [10]
>  
> 
> Links:
> ------
> [1] tel:301-540-2311
> [2] tel:301-326-6843
> [3] http://nate-trust.org
> [4]
> https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html#resource-set-desc
> [5] tel:%2B1%20425.345.6756
> [6] http://summits.forgerock.com/
> [7] tel:%28401%29%20423-9111
> [8] http://www.lgisoftware.com
> [9] tel:%28401%29%20965-9347
> [10] http://lists.openid.net/mailman/listinfo/openid-specs-heart
> 
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160727/9936d069/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 3198 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160727/9936d069/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.emz
Type: application/octet-stream
Size: 14596 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160727/9936d069/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 20516 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160727/9936d069/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.jpg
Type: image/jpeg
Size: 3204 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160727/9936d069/attachment-0003.jpg>


More information about the Openid-specs-heart mailing list