[Openid-specs-heart] Purpose of Use

[Justin Richer]

I'm not saying it's unimportant, and I'm not arguing against having a 
purpose of use mechanism, I'm arguing against where it was stuck 
previously. I don't think we should include it until we have decided 
exactly where it ought to go in the technical architecture. I really 
don't think having it as an RqP claim works, but defining something like 
a scope, or even an additional (optional) parameter like the "aud" 
parameter might work.

  -- Justin


On 5/12/2017 4:19 AM, John Moehrke wrote:
> PurposeOfUse is indeed a critical aspect in healthcare. It is the 
> highest differentiation, higher than user-role. It indicates the 
> broader context that the data is to be used within. For example a 
> request for data in healthcare often is onbehalf of a broader use: 
> Treatment, Coverage, Research, etc. It is not an attribute of the 
> user, it is an attribute of the request for information. It is not 
> uncommon for identity and context attributes to be conflated or simply 
> communicated in one token; however that does not mean they really are 
> the same, it just means that the environment has made a simplifying 
> assumption to combine for ease of technology. It is most closely 
> aligned with the broadest part of a OAuth scope. So it should be 
> included in the request for authorization decision, and authorization 
> token.
>
> John Moehrke
> Principal Engineering Architect: Standards - Interoperability, 
> Privacy, and Security
> CyberPrivacy – Enabling authorized communications while respecting Privacy
> M +1 920-564-2067
> JohnMoehrke at gmail.com <mailto:JohnMoehrke at gmail.com>
> https://www.linkedin.com/in/johnmoehrke
> https://healthcaresecprivacy.blogspot.com
> "Quis custodiet ipsos custodes?" ("Who watches the watchers?")
>
> On Thu, May 11, 2017 at 3:29 PM, Justin Richer <jricher at mit.edu 
> <mailto:jricher at mit.edu>> wrote:
>
>     The “pou” claim as it was specified in HEART does not fit this use
>     case, then, and it’s appropriate that we removed it. This was a
>     claim presented by the requesting party’s identity provider, and
>     had nothing to do with the request being made by the client
>     itself. That’s why I argued it wasn’t a good fit where it was. If
>     we were to add it back in, it should go elsewhere in the protocol.
>
>      — Justin
>
>>     On May 11, 2017, at 2:01 PM, Nancy Lush <nlush at lgisoftware.com
>>     <mailto:nlush at lgisoftware.com>> wrote:
>>
>>     Hello all,
>>     Per our last meeting, I agreed to provide more information on the
>>     need for the pou claim.
>>     The claim pou was recently removed from the HEART specs and needs
>>     to be restored.
>>     I spoke with Duane Decouteau from the VA team and provide the
>>     following details:
>>     Purpose of use drives policy in many electronic exchanges today. 
>>     The custodian organization uses the claimed purpose of use to
>>     interpret policy.  For instance, if the pou is ‘Treatment’ a
>>     complete record might be provided, but if the pou is ‘Coverage’
>>     the policy may limit what is sent.  If the pou is ‘Research’ then
>>     the custodian organization might need to de-identify the data on
>>     the way out.
>>     The pou is passed as a claim within the request. It is a
>>     determining factor in evaluating which policies apply to a
>>     request.  Pou is implemented in ehealth exchange as an underlying
>>     principal.  Duane feels that pou should be a cornerstone for
>>     patient consent.  It is fully implemented now in ehealth exchange
>>     at the VA, Kaiser and others.
>>     The list of pou values can be found at this link:
>>     https://www.hl7.org/fhir/v3/PurposeOfUse/vs.html
>>     <https://www.hl7.org/fhir/v3/PurposeOfUse/vs.html>
>>     Respectively,
>>     Nancy
>>     *Nancy Lush ***
>>     	
>>     nancy.lush at lgisoftware.com <mailto:nancy.lush at lgisoftware.com>
>>     *Lush Group, Inc*
>>     	
>>     Office: (401) 423-9111 <tel:%28401%29%20423-9111>
>>     28 Narragansett Ave
>>     PO Box 651
>>     	
>>     www.lgisoftware.com <http://www.lgisoftware.com/>
>>     Cell:(401) 965-9347 <tel:%28401%29%20965-9347>
>>     Jamestown, RI 02835
>>     	
>>
>>     	
>>     <image001.gif>
>>
>>     	
>>
>>     	
>>
>>     	
>>
>>     	
>>
>>     	
>>
>>     	
>>
>>     	
>>
>>     	
>>
>>     	
>>
>>     	
>>
>>     _______________________________________________
>>     Openid-specs-heart mailing list
>>     Openid-specs-heart at lists.openid.net
>>     <mailto:Openid-specs-heart at lists.openid.net>
>>     http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>     <http://lists.openid.net/mailman/listinfo/openid-specs-heart>
>
>
>     _______________________________________________
>     Openid-specs-heart mailing list
>     Openid-specs-heart at lists.openid.net
>     <mailto:Openid-specs-heart at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs-heart
>     <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/20170512/c4ac3be2/attachment.html>