[Openid-specs-heart] Resources vs Resource sets

Tue Jul 26 23:39:43 UTC 2016

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
>
> (m) 301-326-6843
>
> <http://nate-trust.org>
>
>
>
> *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
>
>
>
> 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 | Skype: xmlgrrl | Twitter: @xmlgrrl
> *ForgeRock Summits and UnSummits* are coming to
> <http://summits.forgerock.com/> *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 | Skype: xmlgrrl | Twitter: @xmlgrrl
> *ForgeRock Summits and UnSummits* are coming to
> <http://summits.forgerock.com/> *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
>
> 28 Narragansett Ave
>
> PO Box 651
>
> www.lgisoftware.com
>
> Cell:(401) 965-9347
>
> Jamestown, RI 02835
>
>
>
> [image: LGI_logo_small]
>
>
>
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> 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/20160726/20d8d141/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 3204 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160726/20d8d141/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.gif
Type: image/gif
Size: 3006 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160726/20d8d141/attachment-0001.gif>