<div dir="ltr"><div><div><div><div>Speaking for myself, the only confusion I have is why there was such a heated debate around FHIR Consent long before I showed-up on that scene.<br><br></div>I understand that John is trying to tell us that what's happening in FHIR Consent has practically nothing to do with HEART. He could be right but I'm still worried.<br><br></div>The reason I'm worried has to do with our discussion in HEART about FHIR "Resource Types" and OAuth or UMA "Scopes". As far as I'm concerned both FHIR and UMA are equally immature in the sense that neither one is in clinical use AFAIK. My fear is that FHIR, by focusing its resource type design on FHIR Consent will unwittingly do something that makes Scopes and User Managed Access a lot uglier.<br><br>The reason is that there is obvious interplay between the resource types FHIR defines and the way policies and scopes are understood by the patient. In one design we might be making the institution's life easier and in the other design the patient's life easier. I'm not saying that anyone is doing that on purpose or that it will even happen, but I am saying that we are not explicitly designing for patient-centered health records and this could come back and bite us all really badly.<br><br></div>My claim in the other thread about not trying to profile "privacy", is that designing the FHIR patient-level resource types around UMA is the first thing to do. Then, we would have a clearer understanding of FHIR "consent" as it relates to FHIR institutional resource-types (not patient-level) as well as directories and relationship locator services, and all sorts of other critical privacy issues in an institutional context that FHIR Consent may be trying to address.<br><br></div>Adrian<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 22, 2016 at 10:33 PM, John Moehrke <span dir="ltr"><<a href="mailto:johnmoehrke@gmail.com" target="_blank">johnmoehrke@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Debbie,<div><br></div><div>I do think that somehow I gave you the wrong impression. There is no reason why the two systems can't work together. Indeed this multi-layer of access control is what think Adrian is revering to with his Adrian rule. (Not the only use of this multi-layer). </div><div><br></div><div>Most 'apps', if we are thinking mobile-applications, or even old-style fat-clints, won't be the ones using the FHIR Consent rules. These FHIR Consent rules would be more likely enforced infront of the departmental server. But, this is just one possibility.</div><div><br></div><div>I tried very hard to express that even with the FHIR Consent can be used in a patient centric architecture...</div><div><br></div><div>I was simply trying to in as short of space as possible draw distinction between FHIR Consent and HEART/UMA; while also showing they are not in conflict; and that they both must be developed for different reasons.</div><div><br></div><div>So, what other confusion have I caused?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div><br></div><div>John</div></font></span></div><div class="gmail_extra"><span class=""><br clear="all"><div><div data-smartmail="gmail_signature"><div dir="ltr">John Moehrke<br>Principal Engineering Architect: Standards - Interoperability, Privacy, and Security<br>CyberPrivacy – Enabling authorized communications while respecting Privacy<br>M <a href="tel:%2B1%20920-564-2067" value="+19205642067" target="_blank">+1 920-564-2067</a><br><a href="mailto:JohnMoehrke@gmail.com" target="_blank">JohnMoehrke@gmail.com</a><br><a href="https://www.linkedin.com/in/johnmoehrke" target="_blank">https://www.linkedin.com/in/johnmoehrke</a><br><a href="https://healthcaresecprivacy.blogspot.com" target="_blank">https://healthcaresecprivacy.blogspot.com</a><br>"Quis custodiet ipsos custodes?" ("Who watches the watchers?")</div></div></div>
<br></span><div><div class="h5"><div class="gmail_quote">On Wed, Jun 22, 2016 at 7:02 PM, Debbie Bucci <span dir="ltr"><<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Correction...Patient input (not info) needed</p><div><div>
<div class="gmail_quote">On Jun 22, 2016 7:56 PM, "Debbie Bucci" <<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="Calibri"><p dir="ltr"><br>
<span style="color:#1f497d">>>>>I expect that using the </span><span style="color:#1f497d">UMA</span><span style="color:#1f497d"> mechanism is equivalent to what the </span><span style="color:#1f497d">FHIR</span><span style="color:#1f497d"> Consent is attempting to do regarding encoding the rules of data disclosure. Equivalence is a very loose term. -- VERY LOOSE.. (Adrian will surely rant here)</span><br></p>
<p dir="ltr"><span style="color:#1f497d">Where in the </span><span style="color:#1f497d">UMA</span><span style="color:#1f497d"> case it is focused on the technical means of making a decision and enforcing that decision. In </span><span style="color:#1f497d">UMA</span><span style="color:#1f497d"> it is the AS responsibility to deal with the </span><span style="color:#1f497d">UX</span><span style="color:#1f497d"> and persistence of the rules that it is enforcing. Meaning in </span><span style="color:#1f497d">UMA</span><span style="color:#1f497d"> there is no requirement to expose the rules. This is one architectural model, and one I agree with with "User" "Managed" "Access". </span></p>
<p dir="ltr"><span style="color:#1f497d">Where as in </span><span style="color:#1f497d">FHIR</span><span style="color:#1f497d"> Consent the goal is to persist the rules in an open format. Where in </span><span style="color:#1f497d">FHIR</span><span style="color:#1f497d"> Consent it puts the capturing of the rules out-of-scope, expecting that the way that the consent is captured will be the focus of application developers. This is similar as with </span><span style="color:#1f497d">UMA</span><span style="color:#1f497d">, but more explicitly putting the separation at the rule encoding. In </span><span style="color:#1f497d">FHIR</span><span style="color:#1f497d"> Consent it also does not indicate how the rules will be processed (decision and enforcement). The focus in </span><span style="color:#1f497d">FHIR</span><span style="color:#1f497d"> on capturing the rules, is that it is trying to address the needs of healthcare that has highly distributed systems. That is to say that it is very unusual for one healthcare organization to have all their data under one service </span><span style="color:#1f497d">API</span><span style="color:#1f497d">, thus controllable by one access control system. Each department within an organization likely has one server for their specific data, it is only conceptually understood as being all related to the 'one patient'. <<<<</span><br></p>
<p dir="ltr"><span style="color:#1f497d">Huh? I'm lost ...</span></p>
<p dir="ltr"><span style="color:#1f497d">I get that app developers will need to deal with consent up front and healthcare orgs must deliver consent as part of the payload . </span></p>
<p dir="ltr"><span style="color:#1f497d"> From my casual observance , primarily from pending European privacy requirement (those in the know correct me if I am wrong) I am aware of a couple of efforts working to create " privacy managers" to simplify consent across many sectors for data that is deemed sensitive by the state/country</span></p>
<p dir="ltr"><span style="color:#1f497d">A service that may contain my "default" preferences to ease the data gathering burden on the app developer or data entry by patient does not seem far fetch to me. They seem complimentary. Neither actually process/interpret the policies. Adrian will remind us it's ultimately the </span><span style="color:#1f497d">RS</span><span style="color:#1f497d"> decision. Why couldn't </span><span style="color:#1f497d">UMA</span><span style="color:#1f497d"> (like) workflows exist (perhaps be beneficial in that environment - where patient info is needed? </span></p>
<p dir="ltr"><span style="color:#1f497d">I do believe it was you that urged the group to only focus on patient perspective. </span></p>
<p dir="ltr"><span style="color:#1f497d">I must be missing something.</span><br></p>
</font></blockquote></div>
</div></div></blockquote></div><br></div></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" data-smartmail="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>