<div dir="ltr"><div>This is a great discussion from my perspective. We've come to the nub here -- about what "patient centricity" means, risk appetite of the service operator/institution, and other matters.</div><div><br></div>I don't know how it works in health IT regulatory regimes and am eager to find out. But in some other existing and emerging regulatory regimes, gathering individual consent is a key consideration -- and fast becoming <i>the</i> key consideration -- in mitigating organizational risk for data transfer. That is, if the customer/consumer/end-user consents, that trumps other constraints.<div><br></div><div>UMA's proposition, of course, goes farther than enabling "reactive" consent, by enabling "proactive" consent as well -- what might be called, ahem, "consent directives" :-), or authorization policy, or sharing instructions, or delegation of access, etc.</div><div><br></div><div>In other words, it's now possible to ask people what they want shared, and then <i>do what they say</i> (within the law). The benefits go beyond compliance, all the way to demonstrating trustworthiness and "building trusted digital relationships".<br></div><div><br></div><div>It seems that confidentiality codes are first and foremost a tool of compliance, not of Alice's wishes. We have two humps to get over in leveraging them:</div><div><ul><li>Use cases: If the FHIR API server/UMA resource server were to transfer these codes to the UMA authorization server, what use are they to the AS and/or to the patient/UMA resource owner?</li><li>Logistical: Is this transfer even in scope for HEART?</li></ul></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">
<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br><b>ForgeRock Summits and UnSummits</b> <a href="http://summits.forgerock.com/" target="_blank">are coming to</a> <b>Sydney, London, and Paris!</b></p></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Jul 27, 2016 at 1:03 PM, Glen Marshall [SRS] <span dir="ltr"><<a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif">The boundary of existing regulatory mandates for privacy and security is a bright line. It defines the minimum we in health IT must achieve. Anything beyond that either anticipates regulatory
change or states an objective or some sort.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif">In the case of covered entities’ objectives, we can assume they have performed HIPAA-required risk analysis and set risk management policies accordingly. I believe that OAuth and UMA operate
most effectively in a such a businesslike risk-mitigation environment, where the semantics of the security and privacy metadata are unambiguous.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif">When we honor patient-specific privacy choices, we ignore covered entity risk assessment and in-common semantics. Patients are under no obligation to perform a formal business risk analysis
or articulate it in a commonly-understood way. Their choices may be realistic or not, articulate or not. We have no simple objective basis to assess, let alone enforce, them.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif">It is a philosophic ethical question as to how we honor patient privacy choices. It is not clear to me that the health IT marketplace is ready to answer it.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif"><u></u> <u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Helvetica",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Glen F. Marshall<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Consultant<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Security Risk Solutions, Inc.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">698 Fishermans Bend<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Mount Pleasant, SC 29464<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Tel: <a href="tel:%28610%29%20644-2452" value="+16106442452" target="_blank">(610) 644-2452</a>
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Mobile: <a href="tel:%28610%29%20613-3084" value="+16106133084" target="_blank">(610) 613-3084</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif"><a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif"><a href="http://www.securityrisksolutions.com/" target="_blank"><span style="color:#0563c1">www.SecurityRiskSolutions.com</span></a><u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif"><u></u> <u></u></span></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">openid-specs-heart-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>Aaron Seib<br>
<b>Sent:</b> Wednesday, July 27, 2016 14:25<br>
<b>To:</b> Adrian Gropper <<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>>; Salyards, Kenneth (SAMHSA/OPPI) <<a href="mailto:Kenneth.Salyards@samhsa.hhs.gov" target="_blank">Kenneth.Salyards@samhsa.hhs.gov</a>><span class=""><br>
<b>Cc:</b> HEART List <<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] Resources vs Resource sets<u></u><u></u></span></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">I don't understand why we would even ask the consumer what their preference is if they can't change a default used by a Covered Entity?<u></u><u></u></p>
</div><span class="">
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">That is the entire point.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;color:#575757">Aaron Seib<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;color:#575757"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;color:#575757">The trick to establishing trust is to avoid all tricks. Especially tricks on yourself.<u></u><u></u></span></p>
</div>
</div>
</span></div>
</div>
<br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><br></div>