<div dir="ltr"><div><div><div><div>It might be helpful for us to stipulate that the _confidentiality codes, when available as metadata, can and SHOULD be offered to the grantor as part of the resource registration process (aka UMA Phase 1). The Authorization Server could then define its (internal / local) policies in terms of the _confidentiality codes and factor _confidentiality along with a specific Client's assertion on how it deals with _confidentiality codes (deletes, ignores, passes on the metadata) in UMA Phase 2. <br><br></div>If we make this stipulation, then our profile work can branch based on whether the _confidentiality codes are:<br>(a) available (in which case the RS might also inherit the responsibility to allow the grantor to set or modify the codes associated with particular resources as mentioned in the FHIR spec), or<br></div>(b) allow the grantor to define its (internal / local) policies based on the RSs published resource set descriptions (basically all of patient-level FHIR). This option also gives the grantor the option of hiding what it considers sensitive from the resource server behind the shield of the authorization server's Phase 2 scope authorization logic and may be useful even if _confidentiality codes are available at the RS.<br><br></div>Simply put, _confidentiality codes make our quest for a pleasant and effective user experience MUCH easier but they don't completely solve the problem. We can stipulate this and move on to the other dimensions of what patients want from HEART.<br><br></div>Adrian<br><div><div><div> <br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 12, 2016 at 4:54 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">that is the whole set of securityLabels, inclusive of the _confidentiality codes... I am recommending we start small and deterministic with just the _confidentiality value-set.<div> <a href="http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html" target="_blank">http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html</a></div><span class="HOEnZb"><font color="#888888"><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 Tue, Jul 12, 2016 at 3:46 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"><div dir="ltr"><div><br></div><div>To the standards purist .. my apologies in advance - not very good at abstract thinking. I need to *see* an implementation to *get* how things work. I get the content of the profiles will be a few levels removed and the need to not tightly constrain anything. Ok that said ...</div><div><br></div><div>Kenneth - thanks so much for sending to the list. After yesterday's conversation, I do agree with John's suggestion that the consent process is separate from the token transaction (RPT right?). It may happen at the same time but very separate functions. Was beginning to wonder how something like C2S or other PDP/PEP implementations would integrate - coexist with and UMA AS.</div><div><br></div><div>Wanted to revisit Adrian's discussion around release of information. For an initial visit -that some how seems important.<br></div><div><br></div><div><br></div><div>Is this the correct reference for FHIR confidentiality codes? <a href="https://www.hl7.org/fhir/v3/Confidentiality/index.html" target="_blank">https://www.hl7.org/fhir/v3/Confidentiality/index.html</a> ?</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 12, 2016 at 4:00 PM, Salyards, Kenneth (SAMHSA/OPPI) <span dir="ltr"><<a href="mailto:Kenneth.Salyards@samhsa.hhs.gov" target="_blank">Kenneth.Salyards@samhsa.hhs.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div vlink="purple" link="blue" lang="EN-US">
<div>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">Hi John, sorry if I quoted you wrongly. The bottom line is if you are tagging something or redacting something you still have to have something that can facilitate
that process; i.e., a segmentation engine or a tagging engine. Without this capability, tagging or segmenting cannot work. Ken<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-family:"Tahoma","sans-serif";font-size:10pt">From:</span></b><span style="font-family:"Tahoma","sans-serif";font-size:10pt"> John Moehrke [mailto:<a href="mailto:johnmoehrke@gmail.com" target="_blank">johnmoehrke@gmail.com</a>]
<br>
<b>Sent:</b> Tuesday, July 12, 2016 3:55 PM<br>
<b>To:</b> Salyards, Kenneth (SAMHSA/OPPI)<br>
<b>Cc:</b> Debbie Bucci; <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a><span><br>
<b>Subject:</b> Re: [Openid-specs-heart] Patient Consent<u></u><u></u></span></span></p><span>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Ken, <u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I didn't say that... I said that the FHIR 'resources' structure is not appropriate as a segmentation boundary. That is, in normal REST models one puts sensitive data into different kind of Resources. Where in FHIR resources contain a wide
mixture of sensitive data.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The mechanism that is built into FHIR to enable privacy/security segmentation is the securityLabel. One can absolutely use this meta tag system to segment data. This is indeed what I am recommending through the suggestion that we use the
_confidentiality valueset.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">John<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">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?")<u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Tue, Jul 12, 2016 at 2:12 PM, Salyards, Kenneth (SAMHSA/OPPI) <<a href="mailto:Kenneth.Salyards@samhsa.hhs.gov" target="_blank">Kenneth.Salyards@samhsa.hhs.gov</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">Hello Debbie, here is a high-level view of the Consent 2 Share (C2S) architecture. For the RS to
be able to do what you are proposing, it would need to have a segmentation engine to enforce fined grain consent directives. Enforcing these consent directives is based on (for C2S at least) value sets based on diagnosis, medications, tests/labs and procedures
associated with the sensitive conditions. We have defined these types of value sets which are used in C2S for data segmentation. I can send them to you if you would like to see the content. Also, segmentation can only be accomplished currently on structured
clinical content. We are exploring ways in which to use the value set content to redact textual information related to sensitive conditions, however currently we redact all text in a segmented document.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">With the current state-of-art in EHR technology, the content of exchanged records is highly variable
from simple text documents (all CDA really requires) to documents with text and actual clinical entries. In the future FHIR may improve this pitiful condition.
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">As John has said before, there is no inherent capability within FHIR that can define a resource set
that provides data segmentation at any level.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt">Hope this helps, Ken.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri","sans-serif";font-size:11pt"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-family:"Tahoma","sans-serif";font-size:10pt">From:</span></b><span style="font-family:"Tahoma","sans-serif";font-size:10pt"> 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>Debbie Bucci<br>
<b>Sent:</b> Monday, July 11, 2016 3:31 PM<br>
<b>To:</b> John Moehrke<br>
<b>Cc:</b> <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] Patient Consent</span><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal">So ... the RS *should* have an idea of what medications aligns with each diagnosis. Wouldn't a patient request to not reveal /release HIV for some purpose of use info be enough
info to provide to the RS to use (but note the RS may not comply due to various reasons - but should record for audit purposes)
<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</span></div>
</div>
</blockquote></div><br></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>