<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<pre>Yes John<br />Perhaps heart could specify the objectives - I could write the first pass if you like<br />Then FHIR group can explain the best way to achieve- hopefully using standards already specified.<br /><br />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@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@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@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@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@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@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@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@lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart [10]
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart@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@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
</pre>
</body></html>