<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:899024973;
        mso-list-template-ids:692899480;}
@list l0:level1
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:"Courier New";
        mso-bidi-font-family:"Times New Roman";}
@list l0:level3
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level4
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level5
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level6
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level7
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level8
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level9
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><a name="_MailEndCompose"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Do you have a citation to the specific part of HIPAA?  I am curious how actionable is defined.  On the API task force there were a couple of interpretations and I wonder what the sources says and how it is actually applied in the real world today.<o:p></o:p></span></a></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Aaron Seib, CEO<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>@CaptBlueButton <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> (o) 301-540-2311<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>(m) 301-326-6843<o:p></o:p></span></p><p class=MsoNormal><a href="nate-trust.org"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;text-decoration:none'><img border=0 width=205 height=48 id="Picture_x0020_1" src="cid:image001.jpg@01D15785.15BD00F0" alt="cid:image001.jpg@01D10761.5BE2FE00"></span></a><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> agropper@gmail.com [mailto:agropper@gmail.com] <b>On Behalf Of </b>Adrian Gropper<br><b>Sent:</b> Monday, January 25, 2016 3:25 PM<br><b>To:</b> Aaron Seib<br><b>Cc:</b> Josh Mandel; Eve Maler; openid-specs-heart@lists.openid.net<br><b>Subject:</b> Re: [Openid-specs-heart] Ad hoc get-togethers to work on elements of UMA "semantic" profiling<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>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.<o:p></o:p></p></div><p class=MsoNormal>Adrian<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Mon, Jan 25, 2016 at 3:17 PM, Aaron Seib <<a href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal>I am all for these suggestions.  <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-size:11.5pt'>Aaron Seib</span><o:p></o:p></p><div><p class=MsoNormal><span style='font-size:13.0pt'>@CaptBlueButton</span><o:p></o:p></p><div><p class=MsoNormal><span style='font-size:11.5pt'>(O) <a href="tel:301-540-9549" target="_blank">301-540-9549</a></span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.5pt'>(M) <a href="tel:301-326-6843" target="_blank">301-326-6843</a></span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-size:11.5pt'>"The trick to earning trust is to avoid all tricks.  Including tricks on yourself."</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div></div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'><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 <o:p></o:p></p><div><p class=MsoNormal>Hi Eve,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>A quick tweak on your description of SMART on FHIR scopes, and then a suggesion.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>You wrote:<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal><span style='font-size:9.5pt'>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...)</span><o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><span style='font-family:"Courier New"'></end tweak></span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>---</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal> * eliminate the "user" vs "patient" prefixes from SMART's scopes<o:p></o:p></p></div><div><p class=MsoNormal> * initially, limit requests to one patient at a time (throw away the "user/" concept)<o:p></o:p></p></div><div><p class=MsoNormal> * represent each patient's "entire clinical record" as a single UMA resource<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Then apps can ask for scopes of access into these resources. For example, <o:p></o:p></p></div><div><p class=MsoNormal><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". <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal> * 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". <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>  -J<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Mon, Jan 25, 2016 at 2:35 PM, Eve Maler <<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal>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.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><b>Resource sets and scopes</b><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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...)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><b>Claims to satisfy policy</b><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Briefly, some of the use cases that can be solved with claims include:<o:p></o:p></p></div><div><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>Identification: Who is the requesting party?<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>Authentication: How strongly were they authenticated?<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>Attributes: What professional certifications do they have?<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>Purpose of use: What do they promise to do or not to do with my data?<o:p></o:p></li></ul></div><div><p class=MsoNormal>-----<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Perhaps more to come as we discuss and learn, such as potentially profiling "design patterns".<o:p></o:p></p></div></div><div><div><div><div><div><div><p><b><span style='color:#888888'>Eve Maler<br></span></b><span style='color:#888888'>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell <a href="tel:%2B1%20425.345.6756" 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!<o:p></o:p></span></p></div></div></div></div></div></div></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><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=" 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><o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><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" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></p></div><p class=MsoNormal><br><br clear=all><br>-- <o:p></o:p></p><div><div><div><div><div><div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Adrian Gropper MD<br><br><span style='font-family:"Arial","sans-serif";color:#1F497D'>PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE: <a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style='color:#0563C1'>http://patientprivacyrights.org/donate-2/</span></a></span> <o:p></o:p></p></div></div></div></div></div></div></div></div></div></div></body></html>