<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body>
<div>The consumer always has the right to have access to data about them. </div><div><br></div><div>They have the right to direct you to share it with the third party of their choosing regardless of what bright lines have been burned into the brains of security and privacy professionals who have been relied upon to exchange data in compliance with the law when the scope of exchange was entirely about sharing with another covered entity.</div><div><br></div><div>I urge anyone who hasn't gotten the message to look at OCR's guidance from this year. </div><div><br></div><div>It frightens me to think there are folks who work in this space and feel they have the paternalistic power to tell someone what they are allowed to do with their rights.</div><div><br></div><div>If HEART isn't about embracing the promise of consumer directives it is a waste of time.</div><div><br></div><div id="composer_signature"><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><div style="font-size:85%;color:#575757">Aaron Seib</div><div style="font-size:85%;color:#575757"><br></div><div style="font-size:85%;color:#575757">The trick to establishing trust is to avoid all tricks. Especially tricks on yourself.</div></div><br><br>-------- Original message --------<br>From: Eve Maler <eve.maler@forgerock.com> <br>Date: 7/27/16 4:54 PM (GMT-05:00) <br>To: "Glen Marshall [SRS]" <gfm@securityrs.com> <br>Cc: HEART List <openid-specs-heart@lists.openid.net> <br>Subject: Re: [Openid-specs-heart] Resources vs Resource sets <br><br><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>
</body></html>