Exactly John. Toys or not, patient mediated transactions and restricted use-cases like PHRs are not enough to sustain HEART. We need to accommodate the full range of patient-directed HIE including, non-HIPAA, wearables, and 42 CFR from the outset.<div><br></div><div>Adrian<br><div><br>On Wednesday, July 27, 2016, John Moehrke <<a href="mailto:johnmoehrke@gmail.com">johnmoehrke@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Adrian, this is why I am pushing for HEART progress, because SMART is now powerful to take us beyond toys. </p>
<p dir="ltr">John</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Jul 27, 2016 6:32 PM, "Adrian Gropper" <<a href="javascript:_e(%7B%7D,'cvml','agropper@healthurl.com');" target="_blank">agropper@healthurl.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1 Eve. <div><br></div><div>Partly because of the Precision Medicine Initiative and partly because non-patient directed exchange is collapsing under its own weight, most of the attention is on increasing the responsibility and therefore transferring risk onto the patient. </div><div><br></div><div>I was at the HL7 FHIR applications conference today and it's interesting to see how OpenID Connect and patient-directed apps are slowly gaining traction. UMA and HEART need to look forward to picking up where FHIR loses steam. We need to be clear about how we handle scopes relative to whatever FHIR does and how that responsibility is partitioned between UMA.next and HEART.</div><div><br></div><div>Adrian</div><div><br>On Wednesday, July 27, 2016, Eve Maler <<a href="javascript:_e(%7B%7D,'cvml','eve.maler@forgerock.com');" target="_blank">eve.maler@forgerock.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">We're all trying to figure out how to square "risk/reward" challenge -- and hey, both patients and providers have 'em. :-) (That was actually the subject of my recent <a href="https://www.youtube.com/watch?v=BiRr5Uk9PNI&feature=youtu.be" target="_blank">keynote</a> at the European Identity and Cloud conference, where I used HEART as a centerpiece...) Thought it might be interesting to share this quote:<div><br></div><div><div style="font-size:12.8px"><i>"The value of keeping some personal information protected, and the value of it being known, are almost entirely context-dependent and contingent on essentially uncertain combinations of states of the world. Privacy sensitivities and attitudes are subjective and idiosyncratic, because what constitutes sensitive information differs across individuals."</i></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">-- <a href="http://people.duke.edu/~crtaylor/Privacy_Survey.pdf" target="_blank">The Economics of Privacy, Alessandro Acquisti et al., March 2016</a></div></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Confidentiality codes are just a bureaucratic best guess at what some patient will consider sensitive. We're entering a realm of directed sharing that lets the patient override the RS's risk management strategy through confidentiality codes because the patient has more say than they used to.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">We're at a technical cusp because we need to figure out whether the override mechanism is implicit ("I don't care how you, RS, classified this data -- I want it shared anyway by virtue of my 'consent power'") or explicit ("I want you, RS, to <b>reclassify</b> this data in some fashion").</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I strongly suspect it's the former.</div></div><div class="gmail_extra"><br clear="all"><div><div 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 <a href="tel:%2B1%20425.345.6756" value="+14253456756" target="_blank">+1 425.345.6756</a> | 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 4:04 PM, Adrian Gropper <span dir="ltr"><<a>agropper@healthurl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Go Aaron!<div><div><br><br>On Wednesday, July 27, 2016, Aaron Seib <<a>aaron.seib@nate-trust.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<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><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 <<a>eve.maler@forgerock.com</a>> <br>Date: 7/27/16 4:54 PM (GMT-05:00) <br>To: "Glen Marshall [SRS]" <<a>gfm@securityrs.com</a>> <br>Cc: HEART List <<a>openid-specs-heart@lists.openid.net</a>> <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 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 <a href="tel:%2B1%20425.345.6756" value="+14253456756" target="_blank">+1 425.345.6756</a> | 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>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>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>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>agropper@healthurl.com</a>>; Salyards, Kenneth (SAMHSA/OPPI) <<a>Kenneth.Salyards@samhsa.hhs.gov</a>><span><br>
<b>Cc:</b> HEART List <<a>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>
<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>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>
</div></blockquote>
</div></div></blockquote></div><br></div>
</blockquote></div>
<br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="javascript:_e(%7B%7D,'cvml','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" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br></blockquote></div></div>
</blockquote></div></div>