[Openid-specs-heart] Resources vs Resource sets

[Eve Maler]

Below:


*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 9:49 AM, 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 - Ken
>

By "not deterministically", I mean "they are applicable and valuable, but
not in a deterministic fashion". Guess I should have broken that out into
two bullets!

>
>    - 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.
>
I think it's a bit more subtle than that, if I understand confidentiality
codes correctly. The codes are part of a system of regulatory markers about
data protection. By contrast, patient-created policies are about their
wishes for sharing, which they may create taking into account such codes,
but which they may also create without respect to the codes. On the other
hand, FHIR servers/UMA resource servers will probably have to care a great
deal about those codes in handling and releasing FHIR resources/UMA
resource sets, even to the point, possibly, of sometimes "exercising UMA's
Adrian clause" and giving less access than instructed.


>    - 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? No, at the point of
>       "putting the resources under central protection" so that Alice can set
>       policy on them. See below for a 50,000 foot take.
>       - 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
>
>
The biggest question, then, is: What are the actual use cases for the RS to
inform the AS about confidentiality codes at all? I can think of these two:

   - Providing the patient/UMA resource owner with clever criteria on which
   to base the creation of her sharing policies. This actually sounds like a
   fairly weak reason to me.
   - Providing the UMA authorization server with something it can put into
   audit logs/consent receipts that is an official statement about regulatory
   confidentiality level of the resource. More plausible, but would require
   profiling an extension to UMA that doesn't yet exist to be able to achieve
   it.



>
>    -
>
> 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>
> 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
>
> <http://nate-trust.org>
>
>
>
> *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
>
> <http://nate-trust.org>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160727/6e632377/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/6e632377/attachment-0001.jpg>