<div dir="ltr"><br><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><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>New <a href="https://www.forgerock.com" target="_blank">ForgeRock Identity Platform</a> with <a href="https://www.forgerock.com/platform/user-managed-access/" target="_blank">UMA support</a> and an <a href="https://forgerock.org/openuma/" target="_blank">OpenUMA community</a>!</p></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Mon, Feb 1, 2016 at 1:33 PM, Moehrke, John (GE Healthcare) <span dir="ltr"><<a href="mailto:John.Moehrke@med.ge.com" target="_blank">John.Moehrke@med.ge.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-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi Eve,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>1.<span style="font:7.0pt "Times New Roman"">       </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">This  would simply be an ‘authorization’ that the patient would have needed to record prior to her death. It could have clauses of ‘upon-death’, but that clause would need to be understood and actionable. How would the UMA server learn of death? Some systems today are based on absence of life. Meaning active use by the Patient tells the UMA service that the patient is alive. Learning of death is not something that is well understood today.</span></p></div></div></blockquote><div>Totally agree with you. In fact, it's pretty upsetting when Facebook and LinkedIn recommend that I connect with existing real-life friends who have passed away. Nonetheless, as you may be well aware, the notion of "<a href="https://www.google.com/#q=digital+death">digital death</a>" is actually the subject of quite a lot of identity research and even some interesting online services.</div><div><br></div><div>Specifically in the case of OAuth and UMA, there is a potential technical challenge in keeping the permissions of all of Alice's requesting parties going, having to do with (I'm not making this up :-) how the "time-to-live" (TTL) strategy is managed for the various on-the-wire artifacts such as tokens. If, say, something goes wrong and Alice's long-term tokens expire, or if the system decides to require more-frequent authorization of the basic tokens that keep the RS/AS relationship and suchlike alive, then if Alice dies, her son and everyone else might lose access pretty quick. The alternative would be to detect failure and to try and arrange for timely transfer of Alice's digital assets to a designed proxy. These "digital death" projects can be helpful in this regard, as can emergency features of services like LastPass and such.</div><div> </div><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><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p><p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>2.<span style="font:7.0pt "Times New Roman"">       </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">FHIR is a data-model and an interaction-model; it is not a definition of a system. There are ways that a FHIR service could be told to pseudonymize the data, I prefer an access control (authorization) method.</span></p></div></div></blockquote><div>I mention this because if we want Alice to be able to constrain authorization ("consent to release of x but not y") along such lines, then we should think about scopes that let her do so. Scopes are properties of APIs. That is in the scope (ahem) of our charter.<br></div><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><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> <u></u><u></u></span></p><p style="margin-left:1.0in"><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>a.<span style="font:7.0pt "Times New Roman"">       </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The “Privacy on FHIR” work that the VHA did, did show infrastructure that could be told to de-identify with a specific algorithm. Thus there are obligations embedded in the authorization given to access that indicate what modification would be needed to the data. <u></u><u></u></span></p><p style="margin-left:1.0in"><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>b.<span style="font:7.0pt "Times New Roman"">      </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I addressed this in June <a href="http://healthcaresecprivacy.blogspot.com/2015/06/fhir-does-not-need-deidentifytrue.html" target="_blank">http://healthcaresecprivacy.blogspot.com/2015/06/fhir-does-not-need-deidentifytrue.html</a> When someone asked for a deidentify query parameter.<u></u><u></u></span></p><p style="margin-left:1.0in"><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>c.<span style="font:7.0pt "Times New Roman"">       </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I would be remised in my duty if I didn’t point out that de-identification is simply a method used to lower the risk of identification/re-identification. And as a method that reduces risk, risk is never brought to zero. The algorithm used for any specific use-case is specific to that use-case. De-identification algorithms are tuned to the intended use, while lowering the risk as much  as possible while still satisfying the intended use. The only generic de-identification algorithm that works for all use-cases is the one that passes zero data, thus resulting in the null-set.</span></p></div></div></blockquote><div><br></div><div>Understood. No such query parameter in an API could be made to <a href="http://www.xmlgrrl.com/blog/2008/06/29/the-privacy-imperative/">bear the entire burden of deidentification for all time</a>. :-)</div><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 style="margin-left:1.0in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">John<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> 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>Eve Maler<br><b>Sent:</b> Monday, February 01, 2016 3:06 PM<br><b>To:</b> <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a><br><b>Subject:</b> [Openid-specs-heart] A few comments on Alice Consents to Clinical Research [UMA]<u></u><u></u></span></p><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">Apologies for the delay in sending these! I'm commenting just on the problem statement for now, and really just sending these additional problems/issues for consideration just for posterity since today's meeting has begun already.<u></u><u></u></p><div><ul type="disc"><li class="MsoNormal">Access to data controlled by a resource owner after she has died: We need to consider "digital death" scenarios. Should we consider whether it's in scope to reassign a resource's resource owner or something?<u></u><u></u></li><li class="MsoNormal">Capability of the health API in question to enable pseudonymity of release data. Does/should FHIR handle this?<u></u><u></u></li><li class="MsoNormal">Control over the purpose of use by the CDRN.<u></u><u></u></li><li class="MsoNormal">At "BL" if not "T" control over consent of the CDRN-to-research transfer of data. (Is this out of scope?)<u></u><u></u></li></ul><div><p class="MsoNormal">I'd love to see the first diagram moved to the Problem Statement section, since it's such a good summary, and a key supplied for the arrow colors.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Thanks!<u></u><u></u></p></div><div><div><div><div><div><div><div><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>New <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.forgerock.com&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=GiKCNl6aNE6hJZJAYFSxk2w2sJEqoxY469CZ56Wr5ao&s=zlOSUbG4ybuA5f8AdTdHRWuSxB80Dd6QOIWZB4korE8&e=" target="_blank">ForgeRock Identity Platform</a> with <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.forgerock.com_platform_user-2Dmanaged-2Daccess_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=GiKCNl6aNE6hJZJAYFSxk2w2sJEqoxY469CZ56Wr5ao&s=-fLr-RuqjcWQtP_CwI3H7OFALdEPyB3XLRrYgpOSNOA&e=" target="_blank">UMA support</a> and an <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__forgerock.org_openuma_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=GiKCNl6aNE6hJZJAYFSxk2w2sJEqoxY469CZ56Wr5ao&s=4VJdX6mqTfHXviqqxnx4wnguF1CQv71oaqzsTG_6eRA&e=" target="_blank">OpenUMA community</a>!<u></u><u></u></p></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote></div><br></div></div>