<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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 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";
color:black;}
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";
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New","serif";
color:black;}
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";
color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle25
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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:932512138;
mso-list-type:hybrid;
mso-list-template-ids:-2062537032 1143393074 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"\(%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.0in;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.5in;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:2.0in;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.5in;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.0in;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:3.5in;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:4.0in;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:4.5in;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:5.0in;
text-indent:-9.0pt;}
@list l1
{mso-list-id:1611668777;
mso-list-template-ids:-825868148;}
@list l1: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 l1: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","serif";
mso-bidi-font-family:"Times New Roman";}
@list l1: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 l1: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 l1: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 l1: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 l1: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 l1: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 l1: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;}
@list l2
{mso-list-id:1833597363;
mso-list-type:hybrid;
mso-list-template-ids:-1192981228 1143393074 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l2:level1
{mso-level-text:"\(%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
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 bgcolor=white lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I should let sleeping dogs lie but not knowing who is on this email lists and wanting to make sure they don’t walk away with incomplete facts (Always teaching this one is) I want to throw out this comment to make sure I was clear.<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'>When I was saying that the lines between a Payer and a Provider are blurring I don’t think I was clear enough. There are large payer entities today that are as interested in and working to collect clinical data along side the traditionally defined administrative data. That is to say in addition to the typical revenue-cycle actors who do things on behalf of a payee there are roles coming out of the mist of this blurred line that Payers didn’t traditionally have back in the 1990s. That is to say – we are seeing more and more Payer’s that not only analyze administrative data to identify quality issues but more and more are using the clinincal data associated with that administrative data to attempt to predict which members would benefit from a clinical intervention such as enrollment in a Payer operated Disesase Mgmt program. The staff that operate these kinds of interventions aren’t finance types but more akin to a care delivery actor and the data they need to succeed is much more of a clinical nature. I heard an interesting turn of phrase that described these Payviders as Health Services Companies. <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'>Below you used the “phrase electronic access controls”. I think that a claims payment clerk adjudicating a claim would have a constrained view of the clinical data and the RN helping a stroke victim recover would have a constrained view of the financial data. The consumer may have an AS configured indicating their preference to not share their STD information with either of them.<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'>The simplest thing would be for there to be discover one AS for a given consumer and apply the preferences before disclosing to anyone else, right?<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><div><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="_x0000_i1029" src="cid:image001.jpg@01D13720.E9203BE0"></span></a><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p></div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> Glen Marshall [SRS] [mailto:gfm@securityrs.com] <br><b>Sent:</b> Monday, December 14, 2015 4:57 PM<br><b>To:</b> Aaron Seib; openid-specs-heart@lists.openid.net<br><b>Subject:</b> Re: [Openid-specs-heart] "Scope" of sharing and purpose of use<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>Aaron,<br><br>I have not problem adding "payer", which would include all of the revenue-cycle actors who author and share data with each other on behalf of a payee -- provider or health consumer. Outside of electronic access control's scope they may have legal, contractual, or policy-based restrictions on authorship and sharing. Some, but not all, of those restrictions may be automated as access controls. For analysis sake, any payer is the same as any other payer. This includes things like primary and secondary insurance who coordinate benefits, and intermediate billing/collection services that some providers use. <br><br>I like simplicity. The distinctions created by various sorts of laws, regulations, contracts, etc. are out of scope for payers relative to the HEART discussions. <br><br>FWIW, I left the research leg out for now. I think it could be a policy-defined special case within provider. But the access to a single consumer versus bulk access to multiple health consumers may be a differentiator. Same/same for payers who reimburse for a patient population rather than single health consumers. <o:p></o:p></p><div><p><b>Glen F. Marshall</b><br>Consultant<br>Security Risk Solutions, Inc.<br>698 Fishermans Bend<br>Mount Pleasant, SC 29464<br>Tel: (610) 644-2452<br>Mobile: (610) 613-3084<br><a href="mailto:gfm@securityrs.com">gfm@securityrs.com</a><br><a href="http://www.SecurityRiskSolutions.com">www.SecurityRiskSolutions.com</a><o:p></o:p></p></div><div><p class=MsoNormal>On 12/14/15 16:33, Aaron Seib wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre>That would be amazing.<o:p></o:p></pre><pre>The only add I think is important to consider is adding an actor called Payer. More and more the lines that differentiate a.Payer from a Provider and a Payer from a Consumer.have.blurred but if we can work in that third leg there may be more evident ways to incorporate business cases as part of the analysis.<o:p></o:p></pre><pre>I am not alone in thinking we'd be further along with clinical interop if we hadn't artificially segregated administration Dara for some reason about a decade ago.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>Aaron Seib@CaptBlueButton<o:p></o:p></pre><pre>(O) 301-540-9549(M) 301-326-6843<o:p></o:p></pre><pre>"The trick to earning trust is to avoid all tricks. Including tricks on yourself."<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>-------- Original message --------<o:p></o:p></pre><pre>From: "Glen Marshall [SRS]" <a href="mailto:gfm@securityrs.com"><gfm@securityrs.com></a> <o:p></o:p></pre><pre>Date: 2015/12/14 4:04 PM (GMT-05:00) <o:p></o:p></pre><pre>To: <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a> <o:p></o:p></pre><pre>Subject: Re: [Openid-specs-heart] "Scope" of sharing and purpose of use <o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre> Somehow this thread has confused me. It may be only a temporary<o:p></o:p></pre><pre> lapse, but I'd like to re-wrap my head around some actors and the<o:p></o:p></pre><pre> sort of access rights they have:<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre> Providers - Am I correct in saying this category includes<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Health institutions - hospitals, ambulatory clinics, skilled<o:p></o:p></pre><pre> nursing facilities, physical rehab, substance abuse rehab,<o:p></o:p></pre><pre> long-term care, etc. <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre> Professional practitioners, e.g., physicians, PAs, NPs, RNs,<o:p></o:p></pre><pre> LPNs, dentists, podiatrists, chiropractors, licensed massage<o:p></o:p></pre><pre> therapists, non-Western medicine modalities<o:p></o:p></pre><pre> Employees and business associates of the above, authorized<o:p></o:p></pre><pre> to act on their behalf in role- or contract-limited ways.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Health consumers<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Patients<o:p></o:p></pre><pre> Authorized representatives of patients - relatives or others<o:p></o:p></pre><pre> who have been granted authorities of various sorts. <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> For simplicity's sake, I would like to assume that the providers<o:p></o:p></pre><pre> category has the general ability to author and share health data<o:p></o:p></pre><pre> with each other on behalf of multiple health consumers. Outside of<o:p></o:p></pre><pre> electronic access control's scope they may have legal, contractual,<o:p></o:p></pre><pre> or policy-based restrictions on authorship and sharing. Some, but<o:p></o:p></pre><pre> not all, of those restrictions may be automated as access controls. <o:p></o:p></pre><pre> For analysis sake, any provider is the same as any other provider.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Also for simplicity's sake, I would like to assume that health<o:p></o:p></pre><pre> consumers have the general equal ability to author and share data<o:p></o:p></pre><pre> with providers on behalf of a single patient. Outside of electronic<o:p></o:p></pre><pre> access control's scope they may have legal, contractual, or<o:p></o:p></pre><pre> policy-based restrictions on authorship and sharing. Some, but not<o:p></o:p></pre><pre> all, of those restrictions may be automated as access controls. For<o:p></o:p></pre><pre> analysis sake, any health consumer is the same as any other health<o:p></o:p></pre><pre> consumer.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Simplicity includes not trying to automate all restrictions. It<o:p></o:p></pre><pre> also means we can overlook most granularities within the actor types<o:p></o:p></pre><pre> unless law or regulation requires a differentiation, e.g., as in<o:p></o:p></pre><pre> psychiatric notes or substance-abuse treatment.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> For the providers, I'd like to assume that their dominant<o:p></o:p></pre><pre> requirement for data access is treatment, payment, or operation with<o:p></o:p></pre><pre> a guarantee of high availability and integrity.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> For the health consumers, I assume that their dominant requirement<o:p></o:p></pre><pre> is providers having and using adequate knowledge of their health. <o:p></o:p></pre><pre> Their secondary requirement is confidentiality.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Privacy is a policy-level concept that is supported by security<o:p></o:p></pre><pre> controls - technical, administrative, physical, and environmental.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Can we publish a map fir the above vocabulary to the terminology<o:p></o:p></pre><pre> used by cross-industry concepts under discussion? <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre> Glen F. Marshall<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Consultant<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Security Risk Solutions, Inc.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> 698 Fishermans Bend<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Mount Pleasant, SC 29464<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Tel: (610) 644-2452<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Mobile: (610) 613-3084<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <a href="mailto:gfm@securityrs.com">gfm@securityrs.com</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <a href="http://www.SecurityRiskSolutions.com">www.SecurityRiskSolutions.com</a><o:p></o:p></pre><pre> <o:p></o:p></pre><pre> On 12/14/15 12:10, Aaron Seib wrote:<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <!--<o:p></o:p></pre><pre>/* Font Definitions */<o:p></o:p></pre><pre>@font-face<o:p></o:p></pre><pre> {font-family:Calibri;<o:p></o:p></pre><pre> panose-1:2 15 5 2 2 2 4 3 2 4;}<o:p></o:p></pre><pre>@font-face<o:p></o:p></pre><pre> {font-family:Tahoma;<o:p></o:p></pre><pre> panose-1:2 11 6 4 3 5 4 4 2 4;}<o:p></o:p></pre><pre>@font-face<o:p></o:p></pre><pre> {font-family:Verdana;<o:p></o:p></pre><pre> panose-1:2 11 6 4 3 5 4 4 2 4;}<o:p></o:p></pre><pre>/* Style Definitions */<o:p></o:p></pre><pre>p.MsoNormal, li.MsoNormal, div.MsoNormal<o:p></o:p></pre><pre> {margin:0in;<o:p></o:p></pre><pre> margin-bottom:.0001pt;<o:p></o:p></pre><pre> font-size:12.0pt;<o:p></o:p></pre><pre> font-family:"Times New Roman","serif";}<o:p></o:p></pre><pre>a:link, span.MsoHyperlink<o:p></o:p></pre><pre> {mso-style-priority:99;<o:p></o:p></pre><pre> color:blue;<o:p></o:p></pre><pre> text-decoration:underline;}<o:p></o:p></pre><pre>a:visited, span.MsoHyperlinkFollowed<o:p></o:p></pre><pre> {mso-style-priority:99;<o:p></o:p></pre><pre> color:purple;<o:p></o:p></pre><pre> text-decoration:underline;}<o:p></o:p></pre><pre>p<o:p></o:p></pre><pre> {mso-style-priority:99;<o:p></o:p></pre><pre> mso-margin-top-alt:auto;<o:p></o:p></pre><pre> margin-right:0in;<o:p></o:p></pre><pre> mso-margin-bottom-alt:auto;<o:p></o:p></pre><pre> margin-left:0in;<o:p></o:p></pre><pre> font-size:12.0pt;<o:p></o:p></pre><pre> font-family:"Times New Roman","serif";}<o:p></o:p></pre><pre>p.MsoAcetate, li.MsoAcetate, div.MsoAcetate<o:p></o:p></pre><pre> {mso-style-priority:99;<o:p></o:p></pre><pre> mso-style-link:"Balloon Text Char";<o:p></o:p></pre><pre> margin:0in;<o:p></o:p></pre><pre> margin-bottom:.0001pt;<o:p></o:p></pre><pre> font-size:8.0pt;<o:p></o:p></pre><pre> font-family:"Tahoma","sans-serif";}<o:p></o:p></pre><pre>p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph<o:p></o:p></pre><pre> {mso-style-priority:34;<o:p></o:p></pre><pre> margin-top:0in;<o:p></o:p></pre><pre> margin-right:0in;<o:p></o:p></pre><pre> margin-bottom:0in;<o:p></o:p></pre><pre> margin-left:.5in;<o:p></o:p></pre><pre> margin-bottom:.0001pt;<o:p></o:p></pre><pre> font-size:12.0pt;<o:p></o:p></pre><pre> font-family:"Times New Roman","serif";}<o:p></o:p></pre><pre>span.BalloonTextChar<o:p></o:p></pre><pre> {mso-style-name:"Balloon Text Char";<o:p></o:p></pre><pre> mso-style-priority:99;<o:p></o:p></pre><pre> mso-style-link:"Balloon Text";<o:p></o:p></pre><pre> font-family:"Tahoma","sans-serif";}<o:p></o:p></pre><pre>span.EmailStyle21<o:p></o:p></pre><pre> {mso-style-type:personal;<o:p></o:p></pre><pre> font-family:"Calibri","sans-serif";<o:p></o:p></pre><pre> color:#1F497D;}<o:p></o:p></pre><pre>span.EmailStyle22<o:p></o:p></pre><pre> {mso-style-type:personal-reply;<o:p></o:p></pre><pre> font-family:"Calibri","sans-serif";<o:p></o:p></pre><pre> color:#1F497D;}<o:p></o:p></pre><pre>.MsoChpDefault<o:p></o:p></pre><pre> {mso-style-type:export-only;<o:p></o:p></pre><pre> font-size:10.0pt;}<o:p></o:p></pre><pre>@page WordSection1<o:p></o:p></pre><pre> {size:8.5in 11.0in;<o:p></o:p></pre><pre> margin:1.0in 1.0in 1.0in 1.0in;}<o:p></o:p></pre><pre>div.WordSection1<o:p></o:p></pre><pre> {page:WordSection1;}<o:p></o:p></pre><pre>/* List Definitions */<o:p></o:p></pre><pre>@list l0<o:p></o:p></pre><pre> {mso-list-id:932512138;<o:p></o:p></pre><pre> mso-list-type:hybrid;<o:p></o:p></pre><pre> mso-list-template-ids:-2062537032 1143393074 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}<o:p></o:p></pre><pre>@list l0:level1<o:p></o:p></pre><pre> {mso-level-text:"\(%1\)";<o:p></o:p></pre><pre> mso-level-tab-stop:none;<o:p></o:p></pre><pre> mso-level-number-position:left;<o:p></o:p></pre><pre> margin-left:1.0in;<o:p></o:p></pre><pre> text-indent:-.25in;}<o:p></o:p></pre><pre>@list l0:level2<o:p></o:p></pre><pre> {mso-level-number-format:alpha-lower;<o:p></o:p></pre><pre> mso-level-tab-stop:none;<o:p></o:p></pre><pre> mso-level-number-position:left;<o:p></o:p></pre><pre> margin-left:1.5in;<o:p></o:p></pre><pre> text-indent:-.25in;}<o:p></o:p></pre><pre>@list l0:level3<o:p></o:p></pre><pre> {mso-level-number-format:roman-lower;<o:p></o:p></pre><pre> mso-level-tab-stop:none;<o:p></o:p></pre><pre> mso-level-number-position:right;<o:p></o:p></pre><pre> margin-left:2.0in;<o:p></o:p></pre><pre> text-indent:-9.0pt;}<o:p></o:p></pre><pre>@list l0:level4<o:p></o:p></pre><pre> {mso-level-tab-stop:none;<o:p></o:p></pre><pre> mso-level-number-position:left;<o:p></o:p></pre><pre> margin-left:2.5in;<o:p></o:p></pre><pre> text-indent:-.25in;}<o:p></o:p></pre><pre>@list l0:level5<o:p></o:p></pre><pre> {mso-level-number-format:alpha-lower;<o:p></o:p></pre><pre> mso-level-tab-stop:none;<o:p></o:p></pre><pre> mso-level-number-position:left;<o:p></o:p></pre><pre> margin-left:3.0in;<o:p></o:p></pre><pre> text-indent:-.25in;}<o:p></o:p></pre><pre>@list l0:level6<o:p></o:p></pre><pre> {mso-level-number-format:roman-lower;<o:p></o:p></pre><pre> mso-level-tab-stop:none;<o:p></o:p></pre><pre> mso-level-number-position:right;<o:p></o:p></pre><pre> margin-left:3.5in;<o:p></o:p></pre><pre> text-indent:-9.0pt;}<o:p></o:p></pre><pre>@list l0:level7<o:p></o:p></pre><pre> {mso-level-tab-stop:none;<o:p></o:p></pre><pre> mso-level-number-position:left;<o:p></o:p></pre><pre> margin-left:4.0in;<o:p></o:p></pre><pre> text-indent:-.25in;}<o:p></o:p></pre><pre>@list l0:level8<o:p></o:p></pre><pre> {mso-level-number-format:alpha-lower;<o:p></o:p></pre><pre> mso-level-tab-stop:none;<o:p></o:p></pre><pre> mso-level-number-position:left;<o:p></o:p></pre><pre> margin-left:4.5in;<o:p></o:p></pre><pre> text-indent:-.25in;}<o:p></o:p></pre><pre>@list l0:level9<o:p></o:p></pre><pre> {mso-level-number-format:roman-lower;<o:p></o:p></pre><pre> mso-level-tab-stop:none;<o:p></o:p></pre><pre> mso-level-number-position:right;<o:p></o:p></pre><pre> margin-left:5.0in;<o:p></o:p></pre><pre> text-indent:-9.0pt;}<o:p></o:p></pre><pre>@list l1<o:p></o:p></pre><pre> {mso-list-id:1833597363;<o:p></o:p></pre><pre> mso-list-type:hybrid;<o:p></o:p></pre><pre> mso-list-template-ids:-1192981228 1143393074 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}<o:p></o:p></pre><pre>@list l1:level1<o:p></o:p></pre><pre> {mso-level-text:"\(%1\)";<o:p></o:p></pre><pre> mso-level-tab-stop:none;<o:p></o:p></pre><pre> mso-level-number-position:left;<o:p></o:p></pre><pre> text-indent:-.25in;}<o:p></o:p></pre><pre>@list l1:level2<o:p></o:p></pre><pre> {mso-level-number-format:alpha-lower;<o:p></o:p></pre><pre> mso-level-tab-stop:none;<o:p></o:p></pre><pre> mso-level-number-position:left;<o:p></o:p></pre><pre> text-indent:-.25in;}<o:p></o:p></pre><pre>@list l1:level3<o:p></o:p></pre><pre> {mso-level-number-format:roman-lower;<o:p></o:p></pre><pre> mso-level-tab-stop:none;<o:p></o:p></pre><pre> mso-level-number-position:right;<o:p></o:p></pre><pre> text-indent:-9.0pt;}<o:p></o:p></pre><pre>@list l1:level4<o:p></o:p></pre><pre> {mso-level-tab-stop:none;<o:p></o:p></pre><pre> mso-level-number-position:left;<o:p></o:p></pre><pre> text-indent:-.25in;}<o:p></o:p></pre><pre>@list l1:level5<o:p></o:p></pre><pre> {mso-level-number-format:alpha-lower;<o:p></o:p></pre><pre> mso-level-tab-stop:none;<o:p></o:p></pre><pre> mso-level-number-position:left;<o:p></o:p></pre><pre> text-indent:-.25in;}<o:p></o:p></pre><pre>@list l1:level6<o:p></o:p></pre><pre> {mso-level-number-format:roman-lower;<o:p></o:p></pre><pre> mso-level-tab-stop:none;<o:p></o:p></pre><pre> mso-level-number-position:right;<o:p></o:p></pre><pre> text-indent:-9.0pt;}<o:p></o:p></pre><pre>@list l1:level7<o:p></o:p></pre><pre> {mso-level-tab-stop:none;<o:p></o:p></pre><pre> mso-level-number-position:left;<o:p></o:p></pre><pre> text-indent:-.25in;}<o:p></o:p></pre><pre>@list l1:level8<o:p></o:p></pre><pre> {mso-level-number-format:alpha-lower;<o:p></o:p></pre><pre> mso-level-tab-stop:none;<o:p></o:p></pre><pre> mso-level-number-position:left;<o:p></o:p></pre><pre> text-indent:-.25in;}<o:p></o:p></pre><pre>@list l1:level9<o:p></o:p></pre><pre> {mso-level-number-format:roman-lower;<o:p></o:p></pre><pre> mso-level-tab-stop:none;<o:p></o:p></pre><pre> mso-level-number-position:right;<o:p></o:p></pre><pre> text-indent:-9.0pt;}<o:p></o:p></pre><pre>ol<o:p></o:p></pre><pre> {margin-bottom:0in;}<o:p></o:p></pre><pre>ul<o:p></o:p></pre><pre> {margin-bottom:0in;}<o:p></o:p></pre><pre>--><o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Getting<o:p></o:p></pre><pre> closer to understanding…<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Aaron<o:p></o:p></pre><pre> Seib, CEO<o:p></o:p></pre><pre> @CaptBlueButton<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> (o)<o:p></o:p></pre><pre> 301-540-2311<o:p></o:p></pre><pre> (m)<o:p></o:p></pre><pre> 301-326-6843<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> From:<o:p></o:p></pre><pre> Justin Richer [<a href="mailto:jricher@mit.edu">mailto:jricher@mit.edu</a>] <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Sent: Monday, December 14, 2015 11:23 AM<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> To: Aaron Seib<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Cc: Adrian Gropper;<o:p></o:p></pre><pre> <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Subject: Re: [Openid-specs-heart] "Scope" of<o:p></o:p></pre><pre> sharing and purpose of use<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> “Permission Type” is really a whole lot<o:p></o:p></pre><pre> simpler than people are making it out to be. <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> “patient” means “get me a single specific<o:p></o:p></pre><pre> record for a single specific person”. When there is no other<o:p></o:p></pre><pre> indicator (the “aud” parameter) this is the record for the<o:p></o:p></pre><pre> currently logged in person. This is going to be a common<o:p></o:p></pre><pre> enough use case, and it’s the default OAuth case, that<o:p></o:p></pre><pre> optimizing for this makes sense. <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> “user” means “get me all of the records<o:p></o:p></pre><pre> that I have access to”. There is no record indicator here in<o:p></o:p></pre><pre> the query because it’s basically a get-all-the-stuff type of<o:p></o:p></pre><pre> request. What matches might be a single record. It might be<o:p></o:p></pre><pre> many records. It might be aggregate data. But it’s not a<o:p></o:p></pre><pre> query for a specific record when this permission type is<o:p></o:p></pre><pre> used.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Both of these can be in cases where Alice<o:p></o:p></pre><pre> has user-to-user delegated access (her little sister Joanne has<o:p></o:p></pre><pre> granted her access to her records at Regional Hospital<o:p></o:p></pre><pre> where they both had their babies) to her family<o:p></o:p></pre><pre> members. For the “patient” scope with no “aud” parameter,<o:p></o:p></pre><pre> the token is good for Alice’s record. For the “patient”<o:p></o:p></pre><pre> scope with an “aud” parameter, the token is good for the<o:p></o:p></pre><pre> record indicated by that aud parameter. But just that one<o:p></o:p></pre><pre> specific record! Using this token to get other records will<o:p></o:p></pre><pre> fail. For the “user” scope it’s a request for all records<o:p></o:p></pre><pre> Alice has access to. She can’t specify which one, since<o:p></o:p></pre><pre> that’s not what this kind of scope is for.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> I<o:p></o:p></pre><pre> think that is clear. I think where the consternation<o:p></o:p></pre><pre> comes from is when the User isn’t a consumer but a list of<o:p></o:p></pre><pre> people who have claimed TPO access rights to a set of<o:p></o:p></pre><pre> records (patients). Is the Heart Profile silent on that. <o:p></o:p></pre><pre> This is where the policy gets confounded if each of the<o:p></o:p></pre><pre> patients doesn’t have the chance to first “recognize” that<o:p></o:p></pre><pre> the person who claims to have a Tx relationship with them<o:p></o:p></pre><pre> is in fact a doc that they believe they have a treatment<o:p></o:p></pre><pre> relationship with. This is the fly in the ointment that<o:p></o:p></pre><pre> has Serpico buzzing and I think rightly so. Not that we<o:p></o:p></pre><pre> have to address the issue that he described as Discovery<o:p></o:p></pre><pre> for the HEART work to make progress and sense – it just<o:p></o:p></pre><pre> needs to be clearly isolated.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> The<o:p></o:p></pre><pre> bottom line is there are creative trial lawyers who will<o:p></o:p></pre><pre> ascert that a breach occurred is some Provider was claimed<o:p></o:p></pre><pre> to have had a Treatment relationship with someone when in<o:p></o:p></pre><pre> fact they didn’t. Perhaps Permission Type is too simple<o:p></o:p></pre><pre> if it can’t address this concern. That or make it easy<o:p></o:p></pre><pre> enough for us to demarcate the breadth of where it comes<o:p></o:p></pre><pre> into play and put it in a parking lot for a future need.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> This<o:p></o:p></pre><pre> is a real case we had at the state level. Male Doc is<o:p></o:p></pre><pre> working in a practice. He has access to the EMR that<o:p></o:p></pre><pre> every other doc in his practice has access to so could see<o:p></o:p></pre><pre> the data of all the patients that went there. Turns out<o:p></o:p></pre><pre> the Husband of the woman he is committing adultery with<o:p></o:p></pre><pre> was a patient of another doc at the practice. This guy is<o:p></o:p></pre><pre> a father and has two kids. Husband and Wife split up. <o:p></o:p></pre><pre> Doc and woman get married and want to get custody of the<o:p></o:p></pre><pre> kids. Doc looks at ex-husbands medical records and finds<o:p></o:p></pre><pre> some sensitive information that the new couples lawyers<o:p></o:p></pre><pre> use to argue that the dad isn’t a fit parent. Fortunately<o:p></o:p></pre><pre> – the father’s lawyer figures it out and puts the keibash<o:p></o:p></pre><pre> on using that breached data and the Judge makes his<o:p></o:p></pre><pre> custody decision sans the sensitive health information<o:p></o:p></pre><pre> that shouldn’t be available (and later in another court<o:p></o:p></pre><pre> room the doc gets convicted of a HIPAA violation).<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> The<o:p></o:p></pre><pre> concern that we are all twisting around seems to be the<o:p></o:p></pre><pre> lack of distinction about the permission types. Maybe<o:p></o:p></pre><pre> there is a way to clarify it using another construct that<o:p></o:p></pre><pre> I haven’t come up with. Is this kind of concern addressed<o:p></o:p></pre><pre> somewhere else?<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> — Justin<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> On Dec 13, 2015, at 11:10 PM, Aaron<o:p></o:p></pre><pre> Seib <a href="mailto:aaron.seib@nate-trust.org"><aaron.seib@nate-trust.org></a><o:p></o:p></pre><pre> wrote:<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> I<o:p></o:p></pre><pre> still don’t think I am 100% on what Discovery<o:p></o:p></pre><pre> means in this context.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Here<o:p></o:p></pre><pre> is the def you provided:<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Discovery<o:p></o:p></pre><pre> means: the user(1) doesn't know who will<o:p></o:p></pre><pre> be on the list. That puts a lot of responsibility on<o:p></o:p></pre><pre> the RS to do the right thing(2).<o:p></o:p></pre><pre> In HIEs for example, they insist the user is a<o:p></o:p></pre><pre> practicing physician because they want to reduce<o:p></o:p></pre><pre> their liability if someone's name pops up on a list<o:p></o:p></pre><pre> that the user should not have seen.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> (1) Who<o:p></o:p></pre><pre> is the user? I am still looking to the<o:p></o:p></pre><pre> Permission Type<o:p></o:p></pre><pre> to see if I can get that set of terms to line up<o:p></o:p></pre><pre> in my head. Patient was a permission type which<o:p></o:p></pre><pre> in the health domain correlates to the patient who<o:p></o:p></pre><pre> is the subject of the PHI that the Resource Server<o:p></o:p></pre><pre> may be disclosing. The assumption being that we<o:p></o:p></pre><pre> can match the identity of the person who is using<o:p></o:p></pre><pre> a client application to connect to the resource<o:p></o:p></pre><pre> server (owned by the institution that operates<o:p></o:p></pre><pre> the Resource Server – in the API TF scope the<o:p></o:p></pre><pre> typical example being a EMR used by the caregiver<o:p></o:p></pre><pre> that the patient has had treatment) with the<o:p></o:p></pre><pre> Medical Record Number (MRN) or equivalent in the<o:p></o:p></pre><pre> Resource Servers enterprise context (I don’t see<o:p></o:p></pre><pre> any reason why we can’t say that an HIE with an<o:p></o:p></pre><pre> MPI might be able to simplify this by correlating<o:p></o:p></pre><pre> the MPI values to the person who is using the<o:p></o:p></pre><pre> client app to access data about themselves across<o:p></o:p></pre><pre> Resource Servers that have data about that person<o:p></o:p></pre><pre> “Patient”).<o:p></o:p></pre><pre> (2) Do<o:p></o:p></pre><pre> the Right Thing - <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Sorry<o:p></o:p></pre><pre> for all the verbiage – I want to get my meager<o:p></o:p></pre><pre> understanding spelt out so it can be corrected. <o:p></o:p></pre><pre> This may not be fruitful but it occurs to me<o:p></o:p></pre><pre> that something that isn’t apparent that is<o:p></o:p></pre><pre> becoming more apparent to me as I wrestle with<o:p></o:p></pre><pre> this is that the idea of User may be better<o:p></o:p></pre><pre> understood as a set of several or more<o:p></o:p></pre><pre> sub-categories.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> user<o:p></o:p></pre><pre> The scope is for a bulk set of records (I<o:p></o:p></pre><pre> am assuming that it is implied here that set of<o:p></o:p></pre><pre> records is meant to convey data for more than<o:p></o:p></pre><pre> one person – the notion of a record is not clear<o:p></o:p></pre><pre> to me here I must admit) or for aggregate<o:p></o:p></pre><pre> data not representing a single patient (is<o:p></o:p></pre><pre> this meant to be a distinction or a reiteration<o:p></o:p></pre><pre> of the bulk set of records? What is the<o:p></o:p></pre><pre> difference?), based on what is available to<o:p></o:p></pre><pre> the current user (here is where the turn<o:p></o:p></pre><pre> of phrase seems to be slipping. I am still<o:p></o:p></pre><pre> struggling with the some notion being conveyed<o:p></o:p></pre><pre> here. <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> The question that comes to mind is if we<o:p></o:p></pre><pre> look at the set of records being made available<o:p></o:p></pre><pre> ‘to the current user’ is that person’s record one<o:p></o:p></pre><pre> of those found in the set of records? There seem<o:p></o:p></pre><pre> to be a couple of distinctions that are probably<o:p></o:p></pre><pre> implied but might help to make explicit. At a<o:p></o:p></pre><pre> minimum there are two cases that come to mind:<o:p></o:p></pre><pre> (1) The case where the ‘Current User’ may<o:p></o:p></pre><pre> have a record in the set being returned and any<o:p></o:p></pre><pre> other person’s record being disclosed is permitted<o:p></o:p></pre><pre> because that other person granted the User<o:p></o:p></pre><pre> permission.<o:p></o:p></pre><pre> (2) The case where the ‘Current User’ does<o:p></o:p></pre><pre> not have a record in the current set and is<o:p></o:p></pre><pre> accessing them as a result of capacity being<o:p></o:p></pre><pre> vested in them by the Record owner, because of<o:p></o:p></pre><pre> their professional role.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> I am not sure if there is a more precise<o:p></o:p></pre><pre> way to look at it but it would seem to be that the<o:p></o:p></pre><pre> root difference has something to do with how the<o:p></o:p></pre><pre> User got the permission. It may not be evident I<o:p></o:p></pre><pre> am seeing the difference being based on how the<o:p></o:p></pre><pre> user got the permission. In case (1) I think of<o:p></o:p></pre><pre> the person as a family care giver who has access<o:p></o:p></pre><pre> to other ‘family’ members records because they<o:p></o:p></pre><pre> granted that to him\her to have access and it is<o:p></o:p></pre><pre> not in the role of providing treatment as<o:p></o:p></pre><pre> traditionally defined by HIPAA. In the (2) case I<o:p></o:p></pre><pre> see it being derived based on the fact that the<o:p></o:p></pre><pre> person is in a Treatment role as defined by HIPAA<o:p></o:p></pre><pre> and the Record Owner (i.e., the Hospital et al)<o:p></o:p></pre><pre> gives them permission to access certain records.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> I think the key to unraveling this not<o:p></o:p></pre><pre> is to differentiate between users who are not<o:p></o:p></pre><pre> acting in a professional capacity from those that<o:p></o:p></pre><pre> are as the applicable authorization to disclose is<o:p></o:p></pre><pre> derived from two separate authorities. In Case<o:p></o:p></pre><pre> (1) the User is getting permission to access those<o:p></o:p></pre><pre> other records because the patients whom the<o:p></o:p></pre><pre> records are about gave him\her permision as they<o:p></o:p></pre><pre> may given their right to share with whomever they<o:p></o:p></pre><pre> please while under case (2) they are getting<o:p></o:p></pre><pre> permission as an aspect of their professional<o:p></o:p></pre><pre> requirements as warranted by the resource owner.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Not sure if this is half baked or not<o:p></o:p></pre><pre> but there if there is a fly in the ointment it<o:p></o:p></pre><pre> seems to me that it has to do with what John<o:p></o:p></pre><pre> referred to as purpose of use earlier on. Assume<o:p></o:p></pre><pre> that the User in case 2 has a purpose of use to be<o:p></o:p></pre><pre> treatment and I think it is easier to digest. The<o:p></o:p></pre><pre> word to use for the Consumer’s purpose of use<o:p></o:p></pre><pre> alludes me right now. <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> I think the unifying issue is that the<o:p></o:p></pre><pre> user’s purpose of use must be the same for all the<o:p></o:p></pre><pre> records being retrieved. <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> I think that is the issue with Discovery<o:p></o:p></pre><pre> that is hard to get a grasp on. <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> If an HIE is granting permission to a<o:p></o:p></pre><pre> Requesting party (why do we use the word User<o:p></o:p></pre><pre> rather then requeting party here?) for a set of<o:p></o:p></pre><pre> records it should only be for one or the other<o:p></o:p></pre><pre> purpose of use and the purpose of use must match<o:p></o:p></pre><pre> the part being played for the transaction being<o:p></o:p></pre><pre> responded to by the RS as known to the RO. <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Aaron<o:p></o:p></pre><pre> Seib<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> NATE,<o:p></o:p></pre><pre> CEO<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> @CaptBlueButton<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> (o)<o:p></o:p></pre><pre> 301-540-2311<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> (m)<o:p></o:p></pre><pre> 301-326-6843<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> From:<o:p></o:p></pre><pre> <a href="mailto:agropper@gmail.com">agropper@gmail.com</a><o:p></o:p></pre><pre> [<a href="mailto:agropper@gmail.com">mailto:agropper@gmail.com</a>]<o:p></o:p></pre><pre> On Behalf Of Adrian Gropper<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Sent: Friday, December 11, 2015 5:29 PM<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> To: Aaron Seib<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Cc: <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Subject: Re: [Openid-specs-heart] "Scope"<o:p></o:p></pre><pre> of sharing and purpose of use<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Hi Aaron, Thanks<o:p></o:p></pre><pre> for highlighting the important issue of<o:p></o:p></pre><pre> discovery.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Discovery means: the user doesn't know who<o:p></o:p></pre><pre> will be on the list. That puts a lot of<o:p></o:p></pre><pre> responsibility on the RS to do the right<o:p></o:p></pre><pre> thing. In HIEs for example, they insist the<o:p></o:p></pre><pre> user is a practicing physician because they<o:p></o:p></pre><pre> want to reduce their liability if someone's<o:p></o:p></pre><pre> name pops up on a list that the user should<o:p></o:p></pre><pre> not have seen.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> I meant RO (resource owner), It makes no sense<o:p></o:p></pre><pre> for the RS to send a notice to themselves.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Yes,<o:p></o:p></pre><pre> RqP is the Requesting Party which is the party<o:p></o:p></pre><pre> that controls the Client that is accessing the<o:p></o:p></pre><pre> AS and the RS. The RqP might be the patient<o:p></o:p></pre><pre> subject (the RO) themselves using an app or PHR<o:p></o:p></pre><pre> but that case would be handled by OAuth. (We<o:p></o:p></pre><pre> call that the Alice-to-Alice case). UMA is<o:p></o:p></pre><pre> interesting because it allows the RqP user to be<o:p></o:p></pre><pre> someone other than Alice therefore enabling true<o:p></o:p></pre><pre> health information exchange. This is what makes<o:p></o:p></pre><pre> HEART so useful and our HEART Profiles so<o:p></o:p></pre><pre> important.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Adrian<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> On Fri, Dec 11, 2015 at<o:p></o:p></pre><pre> 4:53 PM, Aaron Seib <a href="mailto:aaron.seib@nate-trust.org"><aaron.seib@nate-trust.org></a><o:p></o:p></pre><pre> wrote:<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Hi<o:p></o:p></pre><pre> – I meant to ask you last week. When you<o:p></o:p></pre><pre> say Discovery in the first bullet I am not<o:p></o:p></pre><pre> sure I know what you mean. Can you expand<o:p></o:p></pre><pre> on that for me? I think I get everything<o:p></o:p></pre><pre> except that below.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> I<o:p></o:p></pre><pre> don’t know why we are trying to be so<o:p></o:p></pre><pre> cryptic on the work group. This is<o:p></o:p></pre><pre> unfortunate. <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> You<o:p></o:p></pre><pre> use RO below and I think it might be a<o:p></o:p></pre><pre> typo but have to confirm. Is it meant to<o:p></o:p></pre><pre> have been something else?<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> What<o:p></o:p></pre><pre> is RqP an abbreviation of? Requesting<o:p></o:p></pre><pre> Party?<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> From:<o:p></o:p></pre><pre> Openid-specs-heart [<a href="mailto:openid-specs-heart-bounces@lists.openid.net">mailto:openid-specs-heart-bounces@lists.openid.net</a>]<o:p></o:p></pre><pre> On Behalf Of Adrian Gropper<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Sent: Friday, December 11, 2015<o:p></o:p></pre><pre> 3:37 PM<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> To: Moehrke, John (GE Healthcare)<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Cc: <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Subject: Re: [Openid-specs-heart]<o:p></o:p></pre><pre> "Scope" of sharing and purpose of use<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Let<o:p></o:p></pre><pre> me attempt at mediation :-)<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> -<o:p></o:p></pre><pre> We're talking about resources that have<o:p></o:p></pre><pre> a single subject (the patient) Resources<o:p></o:p></pre><pre> with more than one subject, such as a<o:p></o:p></pre><pre> patient list are a completely different<o:p></o:p></pre><pre> matter because<o:p></o:p></pre><pre> they involve discovery (I don’t get<o:p></o:p></pre><pre> this? Discovery of what? The<o:p></o:p></pre><pre> identity of each person in the list?).<o:p></o:p></pre><pre> The special case of a mom with 2 kids<o:p></o:p></pre><pre> can simply, if inelegantly, be handled<o:p></o:p></pre><pre> by polling for each of the subjects.<o:p></o:p></pre><pre> There's no discovery involved.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> -<o:p></o:p></pre><pre> The major difference between OAuth and<o:p></o:p></pre><pre> UMA is that in UMA the resource is under<o:p></o:p></pre><pre> the control of a separate legal entity.<o:p></o:p></pre><pre> Therefore, when a client (and the<o:p></o:p></pre><pre> client's user) shows up to request the<o:p></o:p></pre><pre> resource, the client may present claims<o:p></o:p></pre><pre> or attributes to either or both the<o:p></o:p></pre><pre> resource server (RS) and/or the<o:p></o:p></pre><pre> authorization server (AS). To say this<o:p></o:p></pre><pre> another way: In UMA there's some kind of<o:p></o:p></pre><pre> legal agreement between the resource<o:p></o:p></pre><pre> server and the authorization server. In<o:p></o:p></pre><pre> OAuth there is none because they are the<o:p></o:p></pre><pre> same.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> -<o:p></o:p></pre><pre> The sharing of control between the RS<o:p></o:p></pre><pre> and the AS is subject to institutional,<o:p></o:p></pre><pre> local, and federal controls. All of the<o:p></o:p></pre><pre> situations that John listed boil down to<o:p></o:p></pre><pre> "good faith" and "notice" to the RO<o:p></o:p></pre><pre> when the resource server acts on the<o:p></o:p></pre><pre> instructions of the AS based on the<o:p></o:p></pre><pre> actual attributes of the client (C) by client<o:p></o:p></pre><pre> attributes do you mean attributes of<o:p></o:p></pre><pre> MSHV or of the User of MSHV, Aaron<o:p></o:p></pre><pre> Seib? and the client's<o:p></o:p></pre><pre> user (RqP –<o:p></o:p></pre><pre> this is Aaron Seib, right? What does<o:p></o:p></pre><pre> RqP stand for?).<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Adrian<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> On<o:p></o:p></pre><pre> Fri, Dec 11, 2015 at 3:01 PM,<o:p></o:p></pre><pre> Moehrke, John (GE Healthcare) <a href="mailto:John.Moehrke@med.ge.com"><John.Moehrke@med.ge.com></a><o:p></o:p></pre><pre> wrote:<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Hi<o:p></o:p></pre><pre> Eve,<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> It<o:p></o:p></pre><pre> is clear that there is a<o:p></o:p></pre><pre> communications problem between<o:p></o:p></pre><pre> those that are comfortable in<o:p></o:p></pre><pre> the language of speaking about<o:p></o:p></pre><pre> OAuth/UMA, and those that are<o:p></o:p></pre><pre> comfortable in the language of<o:p></o:p></pre><pre> speaking about Healthcare<o:p></o:p></pre><pre> Access Control needs. I can<o:p></o:p></pre><pre> read every word you have said,<o:p></o:p></pre><pre> but I have no idea what you<o:p></o:p></pre><pre> said.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> I<o:p></o:p></pre><pre> think one of our problems is<o:p></o:p></pre><pre> that we keep skipping from<o:p></o:p></pre><pre> use-cases where the “user” is<o:p></o:p></pre><pre> the “patient” trying to access<o:p></o:p></pre><pre> their own data; and use-cases<o:p></o:p></pre><pre> where the “user” is a<o:p></o:p></pre><pre> clinician trying to help the<o:p></o:p></pre><pre> “patient”. There are many MORE<o:p></o:p></pre><pre> use-cases including parents,<o:p></o:p></pre><pre> children, guardians. There are<o:p></o:p></pre><pre> many MORE use-cases around<o:p></o:p></pre><pre> researchers, public-health,<o:p></o:p></pre><pre> billing, payers. And there are<o:p></o:p></pre><pre> a huge variety of all of<o:p></o:p></pre><pre> these. There are authorization<o:p></o:p></pre><pre> mechanisms that stem from<o:p></o:p></pre><pre> direct authorization by the<o:p></o:p></pre><pre> patient, to indirect because<o:p></o:p></pre><pre> of context, and the ultimate<o:p></o:p></pre><pre> for healthcare ‘because their<o:p></o:p></pre><pre> life is in jeopardy and I am a<o:p></o:p></pre><pre> licensed clinician that can<o:p></o:p></pre><pre> save their life’. Followed by<o:p></o:p></pre><pre> many medical-ethical traps<o:p></o:p></pre><pre> like having a personal<o:p></o:p></pre><pre> discussion about a<o:p></o:p></pre><pre> particularly tragic test<o:p></o:p></pre><pre> result before the lab fact is<o:p></o:p></pre><pre> directly exposed.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> We<o:p></o:p></pre><pre> need to solve all of these,<o:p></o:p></pre><pre> however to solve any one would<o:p></o:p></pre><pre> be helpful.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> John<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> From:<o:p></o:p></pre><pre> Eve Maler [<a href="mailto:eve.maler@forgerock.com">mailto:eve.maler@forgerock.com</a>]<o:p></o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Sent: Friday, December<o:p></o:p></pre><pre> 11, 2015 11:43 AM<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> To: Moehrke, John (GE<o:p></o:p></pre><pre> Healthcare)<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Cc: <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Subject: "Scope" of<o:p></o:p></pre><pre> sharing and purpose of use<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Hi<o:p></o:p></pre><pre> John-- (I changed the<o:p></o:p></pre><pre> subject line and deleted<o:p></o:p></pre><pre> older parts of the<o:p></o:p></pre><pre> thread.)<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> When<o:p></o:p></pre><pre> you say "scope" here, I<o:p></o:p></pre><pre> suspect you mean "scope"<o:p></o:p></pre><pre> of the sharing use case,<o:p></o:p></pre><pre> rather than something<o:p></o:p></pre><pre> like an OAuth or UMA<o:p></o:p></pre><pre> scope, so I'm just<o:p></o:p></pre><pre> checking. So a<o:p></o:p></pre><pre> "single-patient scope"<o:p></o:p></pre><pre> means that the only<o:p></o:p></pre><pre> human we're paying<o:p></o:p></pre><pre> attention to in the use<o:p></o:p></pre><pre> case is the patient, and<o:p></o:p></pre><pre> "any application with<o:p></o:p></pre><pre> users that are<o:p></o:p></pre><pre> authorized to multiple<o:p></o:p></pre><pre> patients" seems to mean<o:p></o:p></pre><pre> a use case that involves<o:p></o:p></pre><pre> party-to-party sharing,<o:p></o:p></pre><pre> with multiple humans<o:p></o:p></pre><pre> involved. However, you<o:p></o:p></pre><pre> follow the latter with<o:p></o:p></pre><pre> "would need to get<o:p></o:p></pre><pre> multiple scopes", so I'm<o:p></o:p></pre><pre> not sure. Note that<o:p></o:p></pre><pre> "getting multiple<o:p></o:p></pre><pre> scopes" as a technical<o:p></o:p></pre><pre> construct doesn't have<o:p></o:p></pre><pre> anything to do with<o:p></o:p></pre><pre> sharing with an<o:p></o:p></pre><pre> autonomous third party.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> FWIW,<o:p></o:p></pre><pre> here is how I think, at<o:p></o:p></pre><pre> a high level, about configuring<o:p></o:p></pre><pre> the delegation of<o:p></o:p></pre><pre> rights to access<o:p></o:p></pre><pre> resources. It's<o:p></o:p></pre><pre> all about parts of<o:p></o:p></pre><pre> speech.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> OAuth<o:p></o:p></pre><pre> lets a user (patient) do<o:p></o:p></pre><pre> this configuration at<o:p></o:p></pre><pre> run time while using a<o:p></o:p></pre><pre> client app, by opting in<o:p></o:p></pre><pre> to the authorization<o:p></o:p></pre><pre> server's issuance of an<o:p></o:p></pre><pre> access token to that<o:p></o:p></pre><pre> app. By contrast, UMA<o:p></o:p></pre><pre> lets a user (patient) do<o:p></o:p></pre><pre> this configuration<o:p></o:p></pre><pre> anytime, generally by<o:p></o:p></pre><pre> instructing the<o:p></o:p></pre><pre> authorization server to<o:p></o:p></pre><pre> check whether some<o:p></o:p></pre><pre> combination of the<o:p></o:p></pre><pre> client app and the<o:p></o:p></pre><pre> requesting party using<o:p></o:p></pre><pre> the app meet various<o:p></o:p></pre><pre> requirements (policy).<o:p></o:p></pre><pre> So OAuth is kind of an<o:p></o:p></pre><pre> attenuated version of<o:p></o:p></pre><pre> UMA wrt the constraints<o:p></o:p></pre><pre> on delegation of access<o:p></o:p></pre><pre> rights.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> system <o:p></o:p></pre><pre> subject <o:p></o:p></pre><pre> verb <o:p></o:p></pre><pre> object <o:p></o:p></pre><pre> adjective<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> OAuth <o:p></o:p></pre><pre> client ID <o:p></o:p></pre><pre> OAuth scopes <o:p></o:p></pre><pre> (implicitly<o:p></o:p></pre><pre> some endpoints) n/a<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> (and always<o:p></o:p></pre><pre> Alice)<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> UMA <o:p></o:p></pre><pre> claims-based<o:p></o:p></pre><pre> eg Bob, UMA scopes<o:p></o:p></pre><pre> over... UMA<o:p></o:p></pre><pre> resource sets <o:p></o:p></pre><pre> claims-based e.g.<o:p></o:p></pre><pre> TPO,<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> client<o:p></o:p></pre><pre> ID/type, etc. <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> time limitations, etc.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> It's<o:p></o:p></pre><pre> possible to conflate<o:p></o:p></pre><pre> purpose-of-use into the<o:p></o:p></pre><pre> UMA scopes system, but<o:p></o:p></pre><pre> it's as awkward as<o:p></o:p></pre><pre> conflating (ordinarily<o:p></o:p></pre><pre> implicit) resource sets<o:p></o:p></pre><pre> into the OAuth scopes<o:p></o:p></pre><pre> system (resource1.read,<o:p></o:p></pre><pre> resource1.write, etc.),<o:p></o:p></pre><pre> which is why OAuth has<o:p></o:p></pre><pre> invented the audience<o:p></o:p></pre><pre> parameter to try and<o:p></o:p></pre><pre> solve the problem of a<o:p></o:p></pre><pre> single authorization<o:p></o:p></pre><pre> server protecting<o:p></o:p></pre><pre> several APIs. This is<o:p></o:p></pre><pre> why I suggest using a<o:p></o:p></pre><pre> claims-based system<o:p></o:p></pre><pre> above.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Eve<o:p></o:p></pre><pre> Maler<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> ForgeRock<o:p></o:p></pre><pre> Office of the<o:p></o:p></pre><pre> CTO | VP<o:p></o:p></pre><pre> Innovation<o:p></o:p></pre><pre> & Emerging<o:p></o:p></pre><pre> Technology<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Cell +1 425.345.6756 |<o:p></o:p></pre><pre> Skype: xmlgrrl<o:p></o:p></pre><pre> | Twitter:<o:p></o:p></pre><pre> @xmlgrrl<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Join our ForgeRock.org OpenUMA community!<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> On<o:p></o:p></pre><pre> Mon, Dec 7, 2015 at<o:p></o:p></pre><pre> 2:00 PM, Moehrke, John<o:p></o:p></pre><pre> (GE Healthcare) <a href="mailto:John.Moehrke@med.ge.com"><John.Moehrke@med.ge.com></a><o:p></o:p></pre><pre> wrote:<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> The<o:p></o:p></pre><pre> discussion on<o:p></o:p></pre><pre> the call today<o:p></o:p></pre><pre> was too hard to<o:p></o:p></pre><pre> break into. Even<o:p></o:p></pre><pre> for a big mouth<o:p></o:p></pre><pre> like me.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> I<o:p></o:p></pre><pre> am okay with<o:p></o:p></pre><pre> limiting our<o:p></o:p></pre><pre> next couple of<o:p></o:p></pre><pre> profiles to<o:p></o:p></pre><pre> single patient<o:p></o:p></pre><pre> scopes. As much<o:p></o:p></pre><pre> of the email<o:p></o:p></pre><pre> discussion has<o:p></o:p></pre><pre> pointed out<o:p></o:p></pre><pre> patient<o:p></o:p></pre><pre> controlled<o:p></o:p></pre><pre> access is our<o:p></o:p></pre><pre> primary scope,<o:p></o:p></pre><pre> and logically<o:p></o:p></pre><pre> (if not <o:p></o:p></pre><pre> technically)<o:p></o:p></pre><pre> this is easy to<o:p></o:p></pre><pre> understand with<o:p></o:p></pre><pre> scopes that are<o:p></o:p></pre><pre> single patient.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Yes<o:p></o:p></pre><pre> this means that<o:p></o:p></pre><pre> any application<o:p></o:p></pre><pre> with users that<o:p></o:p></pre><pre> are authorized<o:p></o:p></pre><pre> to multiple<o:p></o:p></pre><pre> patients would<o:p></o:p></pre><pre> need to get<o:p></o:p></pre><pre> multiple scopes;<o:p></o:p></pre><pre> so be it. For<o:p></o:p></pre><pre> now… For<o:p></o:p></pre><pre> Enterprise use,<o:p></o:p></pre><pre> this is<o:p></o:p></pre><pre> troubling; but<o:p></o:p></pre><pre> for most uses<o:p></o:p></pre><pre> that happen from<o:p></o:p></pre><pre> outside of an<o:p></o:p></pre><pre> enterprise or<o:p></o:p></pre><pre> between<o:p></o:p></pre><pre> enterprises this<o:p></o:p></pre><pre> limitation is<o:p></o:p></pre><pre> not<o:p></o:p></pre><pre> unreasonable.<o:p></o:p></pre><pre> The most common<o:p></o:p></pre><pre> APIs in<o:p></o:p></pre><pre> healthcare for<o:p></o:p></pre><pre> this are already<o:p></o:p></pre><pre> patient centric.<o:p></o:p></pre><pre> So it is not a<o:p></o:p></pre><pre> big problem.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> The<o:p></o:p></pre><pre> user experience<o:p></o:p></pre><pre> does not need to<o:p></o:p></pre><pre> be impacted by<o:p></o:p></pre><pre> this profiled<o:p></o:p></pre><pre> limitation<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> The<o:p></o:p></pre><pre> future does not<o:p></o:p></pre><pre> need to be<o:p></o:p></pre><pre> impacted by this<o:p></o:p></pre><pre> profiled<o:p></o:p></pre><pre> limitation.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Which<o:p></o:p></pre><pre> means that one<o:p></o:p></pre><pre> viewpoint for<o:p></o:p></pre><pre> scope can be the<o:p></o:p></pre><pre> identity of the<o:p></o:p></pre><pre> patient that one<o:p></o:p></pre><pre> is asking for<o:p></o:p></pre><pre> access to. This<o:p></o:p></pre><pre> is not the only<o:p></o:p></pre><pre> scope we will<o:p></o:p></pre><pre> ever support;<o:p></o:p></pre><pre> but is one<o:p></o:p></pre><pre> method that<o:p></o:p></pre><pre> would satisfy<o:p></o:p></pre><pre> some use-cases<o:p></o:p></pre><pre> today.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Another<o:p></o:p></pre><pre> view on scope,<o:p></o:p></pre><pre> that I have been<o:p></o:p></pre><pre> involved with in<o:p></o:p></pre><pre> other groups, is<o:p></o:p></pre><pre> to use a<o:p></o:p></pre><pre> high-level<o:p></o:p></pre><pre> vocabulary that<o:p></o:p></pre><pre> is used often in<o:p></o:p></pre><pre> the Access<o:p></o:p></pre><pre> Control policy –<o:p></o:p></pre><pre> PurposeOfUse.<o:p></o:p></pre><pre> This vocabulary<o:p></o:p></pre><pre> is items like:<o:p></o:p></pre><pre> Treatment,<o:p></o:p></pre><pre> Payment,<o:p></o:p></pre><pre> Research,<o:p></o:p></pre><pre> Emergency, etc…<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> To<o:p></o:p></pre><pre> go deeper than<o:p></o:p></pre><pre> these two<o:p></o:p></pre><pre> vectors through<o:p></o:p></pre><pre> scopes in a<o:p></o:p></pre><pre> general purpose<o:p></o:p></pre><pre> healthcare<o:p></o:p></pre><pre> access control<o:p></o:p></pre><pre> infrastructure<o:p></o:p></pre><pre> is futile.<o:p></o:p></pre><pre> Next<o:p></o:p></pre><pre> level deeper in<o:p></o:p></pre><pre> scopes would<o:p></o:p></pre><pre> come from<o:p></o:p></pre><pre> workflow centric<o:p></o:p></pre><pre> implementation<o:p></o:p></pre><pre> guides. That is<o:p></o:p></pre><pre> a specification<o:p></o:p></pre><pre> that is defining<o:p></o:p></pre><pre> a workflow,<o:p></o:p></pre><pre> could define a<o:p></o:p></pre><pre> scope(s) for<o:p></o:p></pre><pre> that workflow.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> John<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> _______________________________________________<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Openid-specs-heart<o:p></o:p></pre><pre> mailing list<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre>_______________________________________________<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Openid-specs-heart mailing list<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> -- <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Adrian<o:p></o:p></pre><pre> Gropper MD<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> PROTECT<o:p></o:p></pre><pre> YOUR FUTURE -<o:p></o:p></pre><pre> RESTORE Health<o:p></o:p></pre><pre> Privacy!<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> HELP us fight for<o:p></o:p></pre><pre> the right to control<o:p></o:p></pre><pre> personal health<o:p></o:p></pre><pre> data.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> DONATE: <a href="http://patientprivacyrights.org/donate-2/">http://patientprivacyrights.org/donate-2/</a><o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> No<o:p></o:p></pre><pre> virus found in this message.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Checked by AVG - <a href="http://www.avg.com">www.avg.com</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Version: 2016.0.7294 / Virus Database:<o:p></o:p></pre><pre> 4483/11158 - Release Date: 12/11/15<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> -- <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> Adrian<o:p></o:p></pre><pre> Gropper MD<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> PROTECT<o:p></o:p></pre><pre> YOUR FUTURE - RESTORE Health<o:p></o:p></pre><pre> Privacy!<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> HELP us fight for the right to<o:p></o:p></pre><pre> control personal health data.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> DONATE: <a href="http://patientprivacyrights.org/donate-2/">http://patientprivacyrights.org/donate-2/</a><o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> _______________________________________________<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Openid-specs-heart mailing list<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre> No<o:p></o:p></pre><pre> virus found in this message.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Checked by AVG - <a href="http://www.avg.com">www.avg.com</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Version: 2016.0.7294 / Virus Database: 4483/11177 - Release<o:p></o:p></pre><pre> Date: 12/14/15<o:p></o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> _______________________________________________<o:p></o:p></pre><pre>Openid-specs-heart mailing list<o:p></o:p></pre><pre><a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><o:p></o:p></pre><pre><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><pre> <o:p></o:p></pre><pre><o:p> </o:p></pre><pre> <o:p></o:p></pre><p class=MsoNormal><br><br><o:p></o:p></p><div><p class=MsoNormal>That would be amazing.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The only add I think is important to consider is adding an actor called Payer. More and more the lines that differentiate a.Payer from a Provider and a Payer from a Consumer.have.blurred but if we can work in that third leg there may be more evident ways to incorporate business cases as part of the analysis.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I am not alone in thinking we'd be further along with clinical interop if we hadn't artificially segregated administration Dara for some reason about a decade ago.<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 id="composer_signature"><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) 301-540-9549</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.5pt'>(M) 301-326-6843</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><p class=MsoNormal><br><br>-------- Original message --------<br>From: "Glen Marshall [SRS]" <a href="mailto:gfm@securityrs.com"><gfm@securityrs.com></a> <br>Date: 2015/12/14 4:04 PM (GMT-05:00) <br>To: <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a> <br>Subject: Re: [Openid-specs-heart] "Scope" of sharing and purpose of use <br><br>Somehow this thread has confused me. It may be only a temporary lapse, but I'd like to re-wrap my head around some actors and the sort of access rights they have:<o:p></o:p></p><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1'>Providers - Am I correct in saying this category includes<o:p></o:p></li></ul><ul type=disc><ul type=circle><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level2 lfo1'>Health institutions - hospitals, ambulatory clinics, skilled nursing facilities, physical rehab, substance abuse rehab, long-term care, etc. <o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level2 lfo1'>Professional practitioners, e.g., physicians, PAs, NPs, RNs, LPNs, dentists, podiatrists, chiropractors, licensed massage therapists, non-Western medicine modalities<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level2 lfo1'>Employees and business associates of the above, authorized to act on their behalf in role- or contract-limited ways.<o:p></o:p></li></ul></ul><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1'>Health consumers<o:p></o:p></li></ul><ul type=disc><ul type=circle><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level2 lfo1'>Patients<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level2 lfo1'>Authorized representatives of patients - relatives or others who have been granted authorities of various sorts. <o:p></o:p></li></ul></ul><p class=MsoNormal style='margin-bottom:12.0pt'><br>For simplicity's sake, I would like to assume that the providers category has the general ability to author and share health data with each other on behalf of multiple health consumers. Outside of electronic access control's scope they may have legal, contractual, or policy-based restrictions on authorship and sharing. Some, but not all, of those restrictions may be automated as access controls. For analysis sake, any provider is the same as any other provider.<br><br>Also for simplicity's sake, I would like to assume that health consumers have the general equal ability to author and share data with providers on behalf of a single patient. Outside of electronic access control's scope they may have legal, contractual, or policy-based restrictions on authorship and sharing. Some, but not all, of those restrictions may be automated as access controls. For analysis sake, any health consumer is the same as any other health consumer.<br><br>Simplicity includes not trying to automate all restrictions. It also means we can overlook most granularities within the actor types unless law or regulation requires a differentiation, e.g., as in psychiatric notes or substance-abuse treatment.<br><br>For the providers, I'd like to assume that their dominant requirement for data access is treatment, payment, or operation with a guarantee of high availability and integrity.<br><br>For the health consumers, I assume that their dominant requirement is providers having and using adequate knowledge of their health. Their secondary requirement is confidentiality.<br><br>Privacy is a policy-level concept that is supported by security controls - technical, administrative, physical, and environmental.<br><br>Can we publish a map fir the above vocabulary to the terminology used by cross-industry concepts under discussion? <o:p></o:p></p><div><p><b>Glen F. Marshall</b><br>Consultant<br>Security Risk Solutions, Inc.<br>698 Fishermans Bend<br>Mount Pleasant, SC 29464<br>Tel: (610) 644-2452<br>Mobile: (610) 613-3084<br><a href="mailto:gfm@securityrs.com">gfm@securityrs.com</a><br><a href="http://www.SecurityRiskSolutions.com">www.SecurityRiskSolutions.com</a><o:p></o:p></p></div><div><p class=MsoNormal>On 12/14/15 12:10, Aaron Seib wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Getting closer to understanding…</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Aaron Seib, CEO</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>@CaptBlueButton </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> (o) 301-540-2311</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>(m) 301-326-6843</span><o:p></o:p></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:image004.jpg@01D13720.E9203BE0"></span></a><o:p></o:p></p></div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><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"'> Justin Richer [<a href="mailto:jricher@mit.edu">mailto:jricher@mit.edu</a>] <br><b>Sent:</b> Monday, December 14, 2015 11:23 AM<br><b>To:</b> Aaron Seib<br><b>Cc:</b> Adrian Gropper; <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><br><b>Subject:</b> Re: [Openid-specs-heart] "Scope" of sharing and purpose of use</span><o:p></o:p></p></div></div><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>“Permission Type” is really a whole lot simpler than people are making it out to be. <o:p></o:p></p><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal>“patient” means “get me a single specific record for a single specific person”. When there is no other indicator (the “aud” parameter) this is the record for the currently logged in person. This is going to be a common enough use case, and it’s the default OAuth case, that optimizing for this makes sense. <o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal>“user” means “get me all of the records that I have access to”. There is no record indicator here in the query because it’s basically a get-all-the-stuff type of request. What matches might be a single record. It might be many records. It might be aggregate data. But it’s not a query for a specific record when this permission type is used.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal>Both of these can be in cases where Alice has user-to-user delegated access <span style='color:#1F497D'>(her little sister Joanne has granted her access to her records at Regional Hospital where they both had their babies) </span>to her family members. For the “patient” scope with no “aud” parameter, the token is good for Alice’s record. For the “patient” scope with an “aud” parameter, the token is good for the record indicated by that aud parameter. But just that one specific record! Using this token to get other records will fail. For the “user” scope it’s a request for all records Alice has access to. She can’t specify which one, since that’s not what this kind of scope is for.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I think that is clear. I think where the consternation comes from is when the User isn’t a consumer but a list of people who have claimed TPO access rights to a set of records (patients). Is the Heart Profile silent on that. This is where the policy gets confounded if each of the patients doesn’t have the chance to first “recognize” that the person who claims to have a Tx relationship with them is in fact a doc that they believe they have a treatment relationship with. This is the fly in the ointment that has Serpico buzzing and I think rightly so. Not that we have to address the issue that he described as Discovery for the HEART work to make progress and sense – it just needs to be clearly isolated.</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The bottom line is there are creative trial lawyers who will ascert that a breach occurred is some Provider was claimed to have had a Treatment relationship with someone when in fact they didn’t. Perhaps Permission Type is too simple if it can’t address this concern. That or make it easy enough for us to demarcate the breadth of where it comes into play and put it in a parking lot for a future need.</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>This is a real case we had at the state level. Male Doc is working in a practice. He has access to the EMR that every other doc in his practice has access to so could see the data of all the patients that went there. Turns out the Husband of the woman he is committing adultery with was a patient of another doc at the practice. This guy is a father and has two kids. Husband and Wife split up. Doc and woman get married and want to get custody of the kids. Doc looks at ex-husbands medical records and finds some sensitive information that the new couples lawyers use to argue that the dad isn’t a fit parent. Fortunately – the father’s lawyer figures it out and puts the keibash on using that breached data and the Judge makes his custody decision sans the sensitive health information that shouldn’t be available (and later in another court room the doc gets convicted of a HIPAA violation).</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The concern that we are all twisting around seems to be the lack of distinction about the permission types. Maybe there is a way to clarify it using another construct that I haven’t come up with. Is this kind of concern addressed somewhere else?</span><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> — Justin<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><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>On Dec 13, 2015, at 11:10 PM, Aaron Seib <<a href="mailto:aaron.seib@nate-trust.org">aaron.seib@nate-trust.org</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal> <o:p></o:p></p><div><div><div><p class=MsoNormal><a name="_MailEndCompose"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I still don’t think I am 100% on what Discovery means in this context.</span></a><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Here is the def you provided:</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><p class=MsoNormal style='margin-left:.5in'>Discovery means: the user<sup>(1)</sup> doesn't know who will be on the list. That puts a lot of responsibility on the RS to <u>do the right thing</u><sup>(2)</sup>. In HIEs for example, they insist the user is a practicing physician because they want to reduce their liability if someone's name pops up on a list that the user should not have seen.<o:p></o:p></p><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l2 level1 lfo3'><![if !supportLists]><span style='mso-list:Ignore'>(1)<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Who is the user? I am still looking to the</span><a href="http://openid.bitbucket.org/HEART/openid-heart-fhir-oauth2.html#rfc.section.2.1"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> Permission Type</span></a><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> to see if I can get that set of terms to line up in my head. Patient was a permission type which in the health domain correlates to the patient who is the subject of the PHI that the Resource Server may be disclosing. The assumption being that we can match the identity of the person who is using a client application to connect to the resource server (owned by the institution that operates the Resource Server – in the API TF scope the typical example being a EMR used by the caregiver that the patient has had treatment) with the Medical Record Number (MRN) or equivalent in the Resource Servers enterprise context (I don’t see any reason why we can’t say that an HIE with an MPI might be able to simplify this by correlating the MPI values to the person who is using the client app to access data about themselves across Resource Servers that have data about that person “Patient”).</span><o:p></o:p></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l2 level1 lfo3'><![if !supportLists]><span style='mso-list:Ignore'>(2)<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Do the Right Thing - </span><o:p></o:p></p><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Sorry for all the verbiage – I want to get my meager understanding spelt out so it can be corrected. This may not be fruitful but it occurs to me that something that isn’t apparent that is becoming more apparent to me as I wrestle with this is that the idea of User may be better understood as a set of several or more sub-categories.</span><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:0in;margin-left:24.0pt;margin-bottom:.0001pt'><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>user</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:24.0pt;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt'><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>The scope is for a bulk set of records <i>(I am assuming that it is implied here that set of records is meant to convey data for more than one person – the notion of a record is not clear to me here I must admit)</i> or for aggregate data not representing a single patient <i>(is this meant to be a distinction or a reiteration of the bulk set of records? What is the difference?)</i>, based on what is available <u>to the current user</u> <i>(here is where the turn of phrase seems to be slipping. I am still struggling with the some notion being conveyed here</i>. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:24.0pt;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt'><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif"'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:24.0pt;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt'><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>The question that comes to mind is if we look at the set of records being made available ‘to the current user’ is that person’s record one of those found in the set of records? There seem to be a couple of distinctions that are probably implied but might help to make explicit. At a minimum there are two cases that come to mind:</span><o:p></o:p></p><p class=MsoListParagraph style='mso-margin-top-alt:0in;margin-right:24.0pt;margin-bottom:0in;margin-left:1.0in;margin-bottom:.0001pt;text-indent:-.25in;mso-list:l0 level1 lfo5'><![if !supportLists]><span style='mso-list:Ignore'>(1)<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>The case where the ‘Current User’ may have a record in the set being returned and any other person’s record being disclosed is permitted because that other person granted the User permission.</span><o:p></o:p></p><p class=MsoListParagraph style='mso-margin-top-alt:0in;margin-right:24.0pt;margin-bottom:0in;margin-left:1.0in;margin-bottom:.0001pt;text-indent:-.25in;mso-list:l0 level1 lfo5'><![if !supportLists]><span style='mso-list:Ignore'>(2)<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>The case where the ‘Current User’ does not have a record in the current set and is accessing them as a result of capacity being vested in them by the Record owner, because of their professional role.</span><o:p></o:p></p><p class=MsoNormal style='margin-right:24.0pt'><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif"'> </span><o:p></o:p></p><p class=MsoNormal style='margin-right:24.0pt'><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>I am not sure if there is a more precise way to look at it but it would seem to be that the root difference has something to do with how the User got the permission. It may not be evident I am seeing the difference being based on how the user got the permission. In case (1) I think of the person as a family care giver who has access to other ‘family’ members records because they granted that to him\her to have access and it is not in the role of providing treatment as traditionally defined by HIPAA. In the (2) case I see it being derived based on the fact that the person is in a Treatment role as defined by HIPAA and the Record Owner (i.e., the Hospital et al) gives them permission to access certain records.</span><o:p></o:p></p><p class=MsoNormal style='margin-right:24.0pt'><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif"'> </span><o:p></o:p></p><p class=MsoNormal style='margin-right:24.0pt'><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>I think the key to unraveling this not is to differentiate between users who are not acting in a professional capacity from those that are as the applicable authorization to disclose is derived from two separate authorities. In Case (1) the User is getting permission to access those other records because the patients whom the records are about gave him\her permision as they may given their right to share with whomever they please while under case (2) they are getting permission as an aspect of their professional requirements as warranted by the resource owner.</span><o:p></o:p></p><p class=MsoNormal style='margin-right:24.0pt'><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif"'> </span><o:p></o:p></p><p class=MsoNormal style='margin-right:24.0pt'><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>Not sure if this is half baked or not but there if there is a fly in the ointment it seems to me that it has to do with what John referred to as purpose of use earlier on. Assume that the User in case 2 has a purpose of use to be treatment and I think it is easier to digest. The word to use for the Consumer’s purpose of use alludes me right now. </span><o:p></o:p></p><p class=MsoNormal style='margin-right:24.0pt'><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif"'> </span><o:p></o:p></p><p class=MsoNormal style='margin-right:24.0pt'><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>I think the unifying issue is that the user’s purpose of use must be the same for all the records being retrieved. </span><o:p></o:p></p><p class=MsoNormal style='margin-right:24.0pt'><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif"'> </span><o:p></o:p></p><p class=MsoNormal style='margin-right:24.0pt'><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>I think that is the issue with Discovery that is hard to get a grasp on. </span><o:p></o:p></p><p class=MsoNormal style='margin-right:24.0pt'><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif"'> </span><o:p></o:p></p><p class=MsoNormal style='margin-right:24.0pt'><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>If an HIE is granting permission to a Requesting party (why do we use the word User rather then requeting party here?) for a set of records it should only be for one or the other purpose of use and the purpose of use must match the part being played for the transaction being responded to by the RS as known to the RO. </span><o:p></o:p></p><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Aaron Seib</span><o:p></o:p></p></div><div><p class=MsoNormal><a href="http://www.nate-trust.org/"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>NATE</span></a><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>, CEO</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>@CaptBlueButton</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>(o) 301-540-2311</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>(m) 301-326-6843</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><div><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"'> <a href="mailto:agropper@gmail.com">agropper@gmail.com</a> [<a href="mailto:agropper@gmail.com">mailto:agropper@gmail.com</a>] <b>On Behalf Of </b>Adrian Gropper<br><b>Sent:</b> Friday, December 11, 2015 5:29 PM<br><b>To:</b> Aaron Seib<br><b>Cc:</b> <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><br><b>Subject:</b> Re: [Openid-specs-heart] "Scope" of sharing and purpose of use</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Hi Aaron, Thanks for highlighting the important issue of discovery.<br><br>Discovery means: the user doesn't know who will be on the list. That puts a lot of responsibility on the RS to do the right thing. In HIEs for example, they insist the user is a practicing physician because they want to reduce their liability if someone's name pops up on a list that the user should not have seen.<br><br>I meant RO (resource owner), It makes no sense for the RS to send a notice to themselves.<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>Yes, RqP is the Requesting Party which is the party that controls the Client that is accessing the AS and the RS. The RqP might be the patient subject (the RO) themselves using an app or PHR but that case would be handled by OAuth. (We call that the Alice-to-Alice case). UMA is interesting because it allows the RqP user to be someone other than Alice therefore enabling true health information exchange. This is what makes HEART so useful and our HEART Profiles so important.<o:p></o:p></p></div><div><p class=MsoNormal>Adrian<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div><div><div><p class=MsoNormal>On Fri, Dec 11, 2015 at 4:53 PM, Aaron Seib <<a href="mailto:aaron.seib@nate-trust.org">aaron.seib@nate-trust.org</a>> wrote:<o:p></o:p></p></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi – I meant to ask you last week. When you say Discovery in the first bullet I am not sure I know what you mean. Can you expand on that for me? I think I get everything except that below.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I don’t know why we are trying to be so cryptic on the work group. This is unfortunate. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>You use RO below and I think it might be a typo but have to confirm. Is it meant to have been something else?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>What is RqP an abbreviation of? Requesting Party?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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"'> Openid-specs-heart [<a href="mailto:openid-specs-heart-bounces@lists.openid.net">mailto:openid-specs-heart-bounces@lists.openid.net</a>] <b>On Behalf Of </b>Adrian Gropper<br><b>Sent:</b> Friday, December 11, 2015 3:37 PM<br><b>To:</b> Moehrke, John (GE Healthcare)<br><b>Cc:</b> <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a><br><b>Subject:</b> Re: [Openid-specs-heart] "Scope" of sharing and purpose of use</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>Let me attempt at mediation :-)<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>- We're talking about resources that have a single subject (the patient) Resources with more than one subject, such as a patient list are a completely different matter <span style='background:yellow'>because they involve discovery</span><span style='color:#1F497D'> (I don’t get this? Discovery of what? The identity of each person in the list?)</span>. The special case of a mom with 2 kids can simply, if inelegantly, be handled by polling for each of the subjects. There's no discovery involved.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>- The major difference between OAuth and UMA is that in UMA the resource is under the control of a separate legal entity. Therefore, when a client (and the client's user) shows up to request the resource, the client may present claims or attributes to either or both the resource server (RS) and/or the authorization server (AS). To say this another way: In UMA there's some kind of legal agreement between the resource server and the authorization server. In OAuth there is none because they are the same.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>- The sharing of control between the RS and the AS is subject to institutional, local, and federal controls. All of the situations that John listed boil down to "good faith" and "notice" to the <span style='background:yellow'>RO</span> when the resource server acts on the instructions of the AS based on the actual attributes of the client (C)<i><span style='color:#1F497D'> by client attributes do you mean attributes of MSHV or of the User of MSHV, Aaron Seib?</span></i> and the client's user (RqP<span style='color:#1F497D'> – this is Aaron Seib, right? What does RqP stand for?</span>).<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Adrian<o:p></o:p></p></div></div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Fri, Dec 11, 2015 at 3:01 PM, Moehrke, John (GE Healthcare) <<a href="mailto:John.Moehrke@med.ge.com">John.Moehrke@med.ge.com</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi Eve,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>It is clear that there is a communications problem between those that are comfortable in the language of speaking about OAuth/UMA, and those that are comfortable in the language of speaking about Healthcare Access Control needs. I can read every word you have said, but I have no idea what you said.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I think one of our problems is that we keep skipping from use-cases where the “user” is the “patient” trying to access their own data; and use-cases where the “user” is a clinician trying to help the “patient”. There are many MORE use-cases including parents, children, guardians. There are many MORE use-cases around researchers, public-health, billing, payers. And there are a huge variety of all of these. There are authorization mechanisms that stem from direct authorization by the patient, to indirect because of context, and the ultimate for healthcare ‘because their life is in jeopardy and I am a licensed clinician that can save their life’. Followed by many medical-ethical traps like having a personal discussion about a particularly tragic test result before the lab fact is directly exposed.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>We need to solve all of these, however to solve any one would be helpful.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>John</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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"'> Eve Maler [mailto:<a href="mailto:eve.maler@forgerock.com">eve.maler@forgerock.com</a>] <br><b>Sent:</b> Friday, December 11, 2015 11:43 AM<br><b>To:</b> Moehrke, John (GE Healthcare)<br><b>Cc:</b> <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><br><b>Subject:</b> "Scope" of sharing and purpose of use</span><o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Hi John-- (I changed the subject line and deleted older parts of the thread.)<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>When you say "scope" here, I suspect you mean "scope" of the sharing use case, rather than something like an OAuth or UMA scope, so I'm just checking. So a "single-patient scope" means that the only human we're paying attention to in the use case is the patient, and "any application with users that are authorized to multiple patients" seems to mean a use case that involves party-to-party sharing, with multiple humans involved. However, you follow the latter with "would need to get multiple scopes", so I'm not sure. Note that "getting multiple scopes" as a technical construct doesn't have anything to do with sharing with an autonomous third party.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>FWIW, here is how I think, at a high level, about <b>configuring the delegation of rights to access resources</b>. It's all about <b>parts of speech</b>.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>OAuth lets a user (patient) do this configuration at run time while using a client app, by opting in to the authorization server's issuance of an access token to that app. By contrast, UMA lets a user (patient) do this configuration anytime, generally by instructing the authorization server to check whether some combination of the client app and the requesting party using the app meet various requirements (policy). So OAuth is kind of an attenuated version of UMA wrt the constraints on delegation of access rights.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-family:"Courier New","serif"'>system subject verb object adjective</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:7.5pt;font-family:"Courier New","serif"'>OAuth client ID OAuth scopes (implicitly some endpoints) n/a</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:7.5pt;font-family:"Courier New","serif"'> (and always Alice)</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:7.5pt;font-family:"Courier New","serif"'>UMA claims-based eg Bob, UMA scopes over... UMA resource sets claims-based e.g. TPO,</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:7.5pt;font-family:"Courier New","serif"'> client ID/type, etc. time limitations, etc.</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>It's possible to conflate purpose-of-use into the UMA scopes system, but it's as awkward as conflating (ordinarily implicit) resource sets into the OAuth scopes system (resource1.read, resource1.write, etc.), which is why OAuth has invented the audience parameter to try and solve the problem of a single authorization server protecting several APIs. This is why I suggest using a claims-based system above.<o:p></o:p></p></div><div><div><div><div><div><div><div><p class=MsoNormal><b>Eve Maler<br></b>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=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=PHeMeoVZ7WGQVkHh4j1pjEo3WjxiOtW0zWBvptezqXM&s=BWKe_zUfK7VyJCEdTSN-5cG7TelP0b1X-x3kyeaODmk&e=" target="_blank">ForgeRock.org OpenUMA</a> community!<o:p></o:p></p></div></div></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Mon, Dec 7, 2015 at 2:00 PM, Moehrke, John (GE Healthcare) <<a href="mailto:John.Moehrke@med.ge.com">John.Moehrke@med.ge.com</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The discussion on the call today was too hard to break into. Even for a big mouth like me.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I am okay with limiting our next couple of profiles to single patient scopes. As much of the email discussion has pointed out patient controlled access is our primary scope, and logically (if not technically) this is easy to understand with scopes that are single patient. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Yes this means that any application with users that are authorized to multiple patients would need to get multiple scopes; so be it. For now… For Enterprise use, this is troubling; but for most uses that happen from outside of an enterprise or between enterprises this limitation is not unreasonable. The most common APIs in healthcare for this are already patient centric. So it is not a big problem.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The user experience does not need to be impacted by this profiled limitation</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The future does not need to be impacted by this profiled limitation.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Which means that one viewpoint for scope can be the identity of the patient that one is asking for access to. This is not the only scope we will ever support; but is one method that would satisfy some use-cases today.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Another view on scope, that I have been involved with in other groups, is to use a high-level vocabulary that is used often in the Access Control policy – PurposeOfUse. This vocabulary is items like: Treatment, Payment, Research, Emergency, etc…</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>To go deeper than these two vectors through scopes in a general purpose healthcare access control infrastructure is futile.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Next level deeper in scopes would come from workflow centric implementation guides. That is a specification that is defining a workflow, could define a scope(s) for that workflow.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>John</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>_______________________________________________<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">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;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="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 style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br><br clear=all><br>-- <o:p></o:p></p><div><div><div><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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/">http://patientprivacyrights.org/donate-2/</a></span> <o:p></o:p></p></div></div></div></div></div></div></div></div></div></div></div><div class=MsoNormal align=center style='text-align:center'><hr size=1 width="100%" noshade style='color:#A0A0A0' align=center></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>No virus found in this message.<br>Checked by AVG - <a href="http://www.avg.com">www.avg.com</a><br>Version: 2016.0.7294 / Virus Database: 4483/11158 - Release Date: 12/11/15<o:p></o:p></p></div></div></div><div><p class=MsoNormal><br><br clear=all><br>-- <o:p></o:p></p></div><div><div><div><div><div><div><div><div><p class=MsoNormal> <o:p></o:p></p></div><div><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/">http://patientprivacyrights.org/donate-2/</a></span> <o:p></o:p></p></div></div></div></div></div></div></div></div></div></div></div><p class=MsoNormal>_______________________________________________<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">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></p></div></blockquote></div><p class=MsoNormal> <o:p></o:p></p></div><div class=MsoNormal align=center style='text-align:center'><hr size=1 width="100%" noshade style='color:#A0A0A0' align=center></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>No virus found in this message.<br>Checked by AVG - <a href="http://www.avg.com">www.avg.com</a><br>Version: 2016.0.7294 / Virus Database: 4483/11177 - Release Date: 12/14/15<o:p></o:p></p><p class=MsoNormal><br><br><br><o:p></o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>Openid-specs-heart mailing list<o:p></o:p></pre><pre><a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><o:p></o:p></pre><pre><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></pre></blockquote><p class=MsoNormal><o:p> </o:p></p></blockquote><p class=MsoNormal><o:p> </o:p></p><div class=MsoNormal align=center style='text-align:center'><hr size=1 width="100%" noshade style='color:#A0A0A0' align=center></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>No virus found in this message.<br>Checked by AVG - <a href="http://www.avg.com">www.avg.com</a><br>Version: 2016.0.7294 / Virus Database: 4483/11177 - Release Date: 12/14/15<o:p></o:p></p></div></body></html>