<p dir="ltr">Don't look too closely at FHIR Consent right now. We need a few months before it is reviewable.  It will be in the fall ballot.</p>
<p dir="ltr">John</p>
<div class="gmail_quote">On Jun 23, 2016 5:05 AM, "Debbie Bucci" <<a href="mailto:debbucci@gmail.com">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"><p dir="ltr">Thanks John.</p>
<p dir="ltr">I understand services so when you say enforced in front of a departmental service - I see that as being generated going out the door and processed on delivery as part of the payload. </p>
<p dir="ltr">I would hope that personal data store apps that choose to include clinical data on behalf of their consumers would realize they must include FHIR as part of their suite of services .   A PDS generating a fhir consent resource based on patient preferences/policies managed by UMA seems like a viable option. </p>
<p dir="ltr">To go beyond one patient I have seen - suggested architectures that would aggregate consent to perform broader research on populations.  That sample architecture suggested using UMA to both replicate and keep policies in sync.</p>
<p dir="ltr">In HEART we keep dancing around consent and delegation  but have not made any progress to move it beyond discussion.  If generating/consuming  a consent fhir resource meets the clinical data use cases  we are most concerned with then we should probably take a closer look.   <br><br></p>
<p dir="ltr">Deb</p>
<div class="gmail_quote">On Jun 22, 2016 10:33 PM, "John Moehrke" <<a href="mailto:johnmoehrke@gmail.com" target="_blank">johnmoehrke@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"><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><div><br></div><div><br></div><div>John</div></div><div class="gmail_extra"><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><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>
</blockquote></div>
</blockquote></div>