<div dir="ltr"><div><div>I appreciate Aaron's deliberate efforts at defining our terms and the drift of this conversation into considering the patient experience.<br><br></div>As a minor issue, Aaron is using the term Resource Owner (RO) differently than we do in UMA and this could confuse folks looking at various sequence diagrams. As was said elsewhere, the term resource "owner" is overloaded and vague. Is it the entity that has ultimate power to delete a resource (UMA calls this the RS) or is it the subject of the resource (the patient Alice)?<br><br>I suggest we use the terms "resource subject", separately from "resource custodian", and separately from "resource owner". Obviously, these three categories overlap significantly. For example, a person with an Apple HealthKit PHR is both the resource subject and the resource owner (Apple cannot see your data in HealthKit or ResearchKit at all. It's a simple privacy policy.) When Alice is not a minor or disabled, she is typically both the resource subject and the resource custodian. When Alice is the mom, as in the Elderly Mom with Family Caregiver use-case, then Alice is just the resource subject and the resource custodian is dealing with everyone that presents a technical interface. This terminology issue doesn't change much about the discussion on this thread about AS-es but it is worth keeping in mind.<br><br></div>HEART is not operating in a vacuum. We are informed by some important parallel efforts:<br><ul><li>UMA which provides the security protocols for operating an AS independent (in the legal entity and liability sense) of the RS.</li><li>OpenID Connect which provides the security protocols to manage access to the AS and the keys it controls and has core implications for privacy, security, and user experience of our work.<br></li><li>The JASON expert panels conclusions that include: " <i>- Separate key management from data management</i>" as a means to promote security, privacy, and interoperability.</li><li>The Stage 3 Meaningful Use regulations that go out of their way to be clear about the limits of Covered Entities (RS) control such as <i>“Providers may not prohibit patients from using any application, 
including third-party applications, which meet the technical 
specifications of the API, including the security requirements of the 
API.”</i> </li><li>The Stage 3 Guidance documents that say things like: "<i>- Our intention is to encourage dynamic registration (e.g., OAuth 2.0 Connect Dynamic Client Registration Protocol) and strongly believe that registration 
should not be used as a means to block information sharing via APIs. 
That is, applications should not be required to pre-register (or be 
approved in advance) with the provider or their Health IT Module 
developer before being allowed to access the API</i>."</li><li>The API Task Force that is meant to provide guidance to downstream regulations.</li></ul><p>HEART is at the interface of technology and policy. If we succeed, we will provide a set of profiles that do not force ANY COMPROMISE BETWEEN PRIVACY and SECURITY. <br></p><p>The value and very core of HEART, as I see it, is the limitation of liability of the HIPAA Covered Entity (RS) when they are implementing the HEART technical profiles and acting in good faith with adequate notice to the other parties to the various transactions. This limitation of liability includes, not just liability for blocking apps and data, but also liability for state and federal laws that apply to the personal information of the resource subject anywhere in the world.</p><p>Without introducing any policy issue, this AS discussion boils down to a binary label on any Resource Server (RS) - Type A or Type B. <br></p><p>Type A - The Resource Server allows the resource subject or the resource subject custodian to "build" their AS (as defined by Eve, above) as long as it adheres to the HEART profiles.<br></p><p>Type B - The Resource Server places additional constraints on the choice of AS beyond adherence to the HEART profiles.</p><p>The nature of the additional constraints imposed by Type B RS resources are typically out-of-scope for HEART but are probably very relevant to the API Task Force. Some of these will likely become the subject of future memos from the Office for Civil Rights.</p><p>I don't think HEART needs to wait for more guidance from regulators. As long as we take the Type A definition of an AS, we can move on and develop the profiles according to the three Use-Cases we already have.<br></p><p>Adrian<br></p><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 15, 2015 at 3:45 PM, Aaron Seib <span dir="ltr"><<a href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Just like I have only one true identity – my privacy preferences (represented in a computational form at Time T as a set of standard configured rules) have one and only one accurate representation.  The more times that representation is modeled and stored the more opportunities for error.  I don’t think the representation for one person should be distributed.  There will likely be several AS containing multiple persons representations of their privacy preference distributing the processing requirements broadly but I fear the notion of a user being required to go to multiple places to make sure their preferences are updated.<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">I don’t hate the idea of there being multiple instances of my AS existing across the network but as a user I need to have one place to go to record my current preferences and update them as they change.  <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">If your replication process makes an error in duplicating those preference it should be on you and not me and if I am harmed as a result you should own the liability for my demonstrable damages.  I (or the husband of an active duty fighter pilot) should not be held holding the bag because your replication place didn’t take place and the disclosure happened before you got the update.  <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">That said it seems reasonable and in good faith for me to agree to use the Schleps safeguards if I am concerned about it but it should not get him off the hook if he gets it wrong – at least that is what I would think a person would likely perceive as a privacy concern.<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">To the Schleps of the world! Excelsior!  </span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d">J</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p><span class=""><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">Aaron Seib, CEO<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">@CaptBlueButton <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> (o) <a href="tel:301-540-2311" value="+13015402311" target="_blank">301-540-2311</a><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">(m) <a href="tel:301-326-6843" value="+13013266843" target="_blank">301-326-6843</a><u></u><u></u></span></p><p class="MsoNormal"><a href="http://nate-trust.org" target="_blank"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d;text-decoration:none"><img src="cid:image001.jpg@01D1374F.90A6CE50" height="48" border="0" width="205"></span></a><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></span><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""> Debbie Bucci [mailto:<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.com</a>] <br><b>Sent:</b> Tuesday, December 15, 2015 3:10 PM<span class=""><br><b>To:</b> Aaron Seib<br><b>Cc:</b> Eve Maler; <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] The Number and Ownership of Authorization Servers.<u></u><u></u></span></span></p><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">Yes I believe ...<span style="font-family:"Calibri","sans-serif";color:#1f497d">some poor schlep is going to be on the hook for keeping his AS replicated with the one I designated because of  “Policy”</span><u></u><u></u></p></div><div><div class="h5"><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#1f497d">AND  (ideally) </span><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#1f497d">The trusted  application that you are familiar designate (Bill's source of truth) would/should trigger/drive the updates.   </span><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#1f497d">Perhaps a schlep provide UI to verify update and changes (and trigger receipts of those update)  -  would be considered a safeguard.</span><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#1f497d">Given your experience with PHRs - you know best - there maybe one source of truth for Healthcare data today but with IOT and other yet to be determined innovations -  I still believe (under the covers) it will be distributed in nature.</span><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#1f497d">Understanding that going in may impact some of our decisions.   </span><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></div><div class="MsoNormal" style="text-align:center" align="center"><hr style="color:#a0a0a0" align="center" size="1" noshade width="100%"></div><span class=""><p class="MsoNormal">No virus found in this message.<br>Checked by AVG - <a href="http://www.avg.com" target="_blank">www.avg.com</a><br>Version: 2016.0.7294 / Virus Database: 4483/11177 - Release Date: 12/14/15<u></u><u></u></p></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><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div>