[Openid-specs-heart] Resources vs Resource sets

Wed Jul 27 17:22:31 UTC 2016

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
> <javascript:_e(%7B%7D,'cvml','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
>
> Agree. 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.
>
> -          yes
>
> Agree - 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 work
>       - Agree 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 incomplete
>       - Support 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
> <http://summits.forgerock.com/> *Sydney, London, and Paris!*
>
>
>
> On Wed, Jul 27, 2016 at 8:51 AM, John Moehrke <johnmoehrke at gmail.com
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
>
> <http://nate-trust.org>
>
>
>
> *From:* John Moehrke [mailto:johnmoehrke at gmail.com
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160727/7baa3dfc/attachment.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/7baa3dfc/attachment.jpg>