<div dir="ltr"><div>Me too. <br><br>I would further suggest that we define "entire clinical record" as HIPAA does - meaning all clinically actionable information for that one patient.<br><br></div>Adrian<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 25, 2016 at 3:17 PM, Aaron Seib <span dir="ltr"><<a href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
    
<div>I am all for these suggestions.  </div><div><br></div><div><br></div><div><br></div><div><span style="font-size:15.4224px">Aaron Seib</span><div><span style="font-size:17.489px">@CaptBlueButton<br></span><div dir="auto"><span style="font-size:15.4224px" dir="auto">(O) <a href="tel:301-540-9549" value="+13015409549" target="_blank">301-540-9549</a></span></div><div dir="auto"><span style="font-size:15.4224px" dir="auto">(M) <a href="tel:301-326-6843" value="+13013266843" target="_blank">301-326-6843</a></span></div><div dir="auto"><span style="font-size:15.4224px" dir="auto"><br></span></div><div dir="auto"><span style="font-size:15.4224px" dir="auto">"The trick to earning trust is to avoid all tricks.  Including tricks on yourself."</span></div><div dir="auto"><br></div></div></div><div><div class="h5"><br><br>-------- Original message --------<br>From: Josh Mandel <<a href="mailto:Joshua.Mandel@childrens.harvard.edu" target="_blank">Joshua.Mandel@childrens.harvard.edu</a>> <br>Date: 2016/01/25  12:59 PM  (GMT-07:00) <br>To: Eve Maler <<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>> <br>Cc: <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a> <br>Subject: Re: [Openid-specs-heart] Ad hoc get-togethers to work on elements of UMA "semantic" profiling <br><br><div dir="ltr">Hi Eve,<div><br></div><div>A quick tweak on your description of SMART on FHIR scopes, and then a suggesion.</div><div><br></div><div>You wrote:<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">There, the scope string has been designed to have a complex pattern of "permission/resource.access", or in extended explanatory form, "who-has-permission/to-what-</span><span style="font-size:12.8px">resource.with-what-access", or very roughly in terms of parts of speech of authorization policy, "subject/object.verb". The subject is "patient" or "user". The verb is "read" or "write". The object can be a variety of standard resource strings. (Check me if I'm wrong...)</span></blockquote><div><br></div><div>The first piece isn't quite "who-has-permission". Instead, it's "what-level-of-permission", where "level" should be interpreted as "patient-level" or "user-level". In other words, when authorization is given, it's given to "resources belonging to this <b>patient</b> record", or to "resources available to this <b>user</b>". This allows SMART apps to say "I want one record" or "I want all your records" (and "<i>your" </i>is context-sensitive here; but it could be all the records available to a clinician in her practice practice, or all the records available to a parent in her portal account.</div><div><font face="monospace, monospace"></end tweak></font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">---</font></div><div><br></div><div>I can see how mapping these terms into UMA concepts like "resource id" and "scope" might feel unnnatural. Here's how I'd suggest approaching the mapping:</div><div><br></div><div> * eliminate the "user" vs "patient" prefixes from SMART's scopes</div><div> * initially, limit requests to one patient at a time (throw away the "user/" concept)</div><div> * represent each patient's "entire clinical record" as a single UMA resource</div><div><br></div><div>Then apps can ask for scopes of access into these resources. For example, </div><div><br> * an RqP that wanted to all of Patient 123's records would make a request that the RS would associate with its "Patient 123's entire clinical record" resource, and a scope of "*.read". <br></div><div><br></div><div> * an RqP that wanted to know all prescriptions for Patient 123 would make a request that the RS would associate with its "Patient 123's entire clinical record" resource, and a scope of "MedicationOrder.read". </div><div><br></div><div>Later on it might be worth bringing back user-level permissions, which would map to new UMA resources (ones that represent "the pile of all  data that User 123 can see" as a single UMA resource). But that's several steps down the road, in my opinion. We could make plenty of progress without it.</div><div><br></div><div>  -J</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 25, 2016 at 2:35 PM, Eve Maler <span dir="ltr"><<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I promised to send a description of what elements of UMA semantic profiling might look like, to see who might be interested to get together at times offset from our regular calls to push forward on them.<div><br><div><b>Resource sets and scopes</b></div><div><br></div><div>We have become familiar with "scopes" from our draft <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.bitbucket.org_HEART_openid-2Dheart-2Dfhir-2Doauth2.html&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=6l_dXC_ZgvWc8H1KnQO3L8tAaIS6x3NM1L-RYlayLaE&s=DX7NZxWP_wwUTEJo8zlYCoEY7XOB5GBatwQ3HF2KPl4&e=" target="_blank">HEART profile for FHIR OAuth scopes</a> (which, so far, is based closely on the SMART on FHIR work). There, the scope string has been designed to have a complex pattern of "permission/resource.access", or in extended explanatory form, "who-has-permission/to-what-resource.with-what-access", or very roughly in terms of parts of speech of authorization policy, "subject/object.verb". The subject is "patient" or "user". The verb is "read" or "write". The object can be a variety of standard resource strings. (Check me if I'm wrong...)</div><div><br></div><div>UMA breaks things down a bit differently, and has further options. A "resource set" (often abbreviated simply "resource") is declarable separately from the "scopes" that apply to it; this makes it especially easy to have scopes that are custom to a resource set.</div><div><br></div><div>Resource sets can be given named "types", so that any resource sets that are of standardized types (e.g. have standard data taxonomies applied to them) can be marked as such, and perhaps given special automated authorization/consent treatment. These data types could connect to security labeling taxonomies as appropriate.<br></div><div><br></div><div><div>Any scopes we define can be declared in such a way that even those not using the official FHIR API (or using an extended FHIR++ API or whatever) could be invited to apply them to their own resource sets, thus encouraging greater interop.</div><div><br></div><div><b>Claims to satisfy policy</b></div><div><br></div><div>Here's how UMA operates: The authorization server executes a resource owner's requirements for "elevating trust" in the requesting side of the equation before associating authorization data with a token that it gives the requesting party's client app. Then when the client brings the token to the resource server, the latter matches the token's authorization data against the kind of access attempted before letting the client in.</div><div><br></div><div>We talk about the resource owner's requirements being expressed in "policy", though UMA doesn't actually have a way to express policy on the protocol wire. (Systems may internally use XACML or whatever they wish.) However, the ability of an authorization server to handle resource owner policy-setting and policy decision-making is intertwined with its needs and abilities around detecting characteristics of the requesting side of the equation.</div><div><br></div><div>That requesting side consists of two parts: the client application and the requesting party (which could be a "natural person" or "legal person"). The biggest element of trust elevation we usually talk about is "claims-gathering", though there can be more to it.</div><div><br></div><div>Briefly, some of the use cases that can be solved with claims include:</div><div><ul><li>Identification: Who is the requesting party?</li><li>Authentication: How strongly were they authenticated?</li><li>Attributes: What professional certifications do they have?</li><li>Purpose of use: What do they promise to do or not to do with my data?</li></ul></div><div>-----</div><div><br></div><div>Perhaps more to come as we discuss and learn, such as potentially profiling "design patterns".</div></div><span><font color="#888888">







<div><div><div><div dir="ltr"><div><div dir="ltr">







<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell <a href="tel:%2B1%20425.345.6756" value="+14253456756" target="_blank">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br>Join our <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=6l_dXC_ZgvWc8H1KnQO3L8tAaIS6x3NM1L-RYlayLaE&s=r0SdYnRaAJ6Hd0OvanbSEKUaCxpyJpn4pKx8AGOkf40&e=" target="_blank">ForgeRock.org OpenUMA</a> community!</p></div></div></div></div></div>
</div></font></span></div></div>

<br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQICAg&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=6l_dXC_ZgvWc8H1KnQO3L8tAaIS6x3NM1L-RYlayLaE&s=QiUBQVZ6Dxoxept-3j2Uqj3z2XlgFF7Hqtwi3_kIyn0&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQICAg&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=6l_dXC_ZgvWc8H1KnQO3L8tAaIS6x3NM1L-RYlayLaE&s=QiUBQVZ6Dxoxept-3j2Uqj3z2XlgFF7Hqtwi3_kIyn0&e=</a><br>
<br>
<br></blockquote></div><br></div></div>
</div></div></div><br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div>