<div dir="ltr">On Mon, Jun 27, 2016 at 12:05 PM, Eve Maler <span dir="ltr"><<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>If we don't choose to give any guidance at all about resource set and scope boundaries, we could do that, but I'm pretty confident that it would be difficult to satisfy a minimal set of "sharing scenario 1" expectations on the part of the doctor's office, and Alice's experience would be extra-confusing too.</div></div></blockquote><div><br>If I'm understanding Eve's point, HEART is to profile "expectations" on the part of the client in order to improve Alice's experience in setting policy. I can work with that. <br><br></div><div>This perspective does not restrict the RS ability to offer any and all resource-types to Alice's AS along with the HEART suggested expectations. If Alice chooses policies based on the full FHIR capability instead of the HEART suggestions she risks inadvertently blocking a client or making a privacy choice she did not intend to make.<br><br></div><div>I think this clarifies my (a) vs. (b) vs (c) argument and informs the scope arithmetic discussion folks are having in the UMA list.<br><br></div><div>If the RS registers "Fine-grained FHIR" and all of the "HEART Expectations" with the AS, then Alice would presumably get some kind of warning when her AS actually maps her actual policies into something other than HEART Expectations. Alice could accept the warning or not. I'm cool with that.<br><br></div><div>Now the Client comes along and has some subset of the HEART Expectations. If these match one of the registered policies exactly, then no scope arithmetic needs to be done by the AS. If however, Alice did not deal with the client's expectations, maybe because she took advantage of "Fine-grained FHIR" or maybe because she picked a different HEART Expectation than the client. In this case, the client's request fails and the client can ether re-submit for different scopes or escalate trust somehow. I'm cool with that too.<br><br></div><div>Are we then on the path to consensus, as follows:<br></div><div>- HEART resource servers MUST offer fine-grained FHIR to all authorization servers, AND<br></div><div>- HEART resource servers MAY (or is it SHOULD or MUST) also offer some or all of the HEART server / client expectations for various use-cases. <br><br>These HEART expectations will be expected to evolve significantly over time as John's points and the Clemson paper clearly teach us just how complex the situation is.<br><br></div><div>Adrian<br></div><div><br><br></div><div class="gmail_extra"> <span class=""><br></span><div><div class="h5"><div class="gmail_quote">On Mon, Jun 27, 2016 at 6:58 AM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Adrian,<div><br></div><div>I would agree HEART shouldn't be 'profiling', as in defining formal constraints, on FHIR resources available nor scopes available... I agree with you that these things are discoverable in FHIR using the FHIR conformance mechanisms, there is no need to constrain by HEART rules.</div><div><br></div><div>Were we really profiling these? I thought we were looking for an instructive set to use in explanations, examples, and test-bench.</div><div><br></div><div>so, what we might have here is a different understanding of the word profiling. Formal profiling is to place constraints that can't be violated. I think this is what Adrian is pointing out and rightfully getting worried about. Where as some people will use the word profiling in a more informal way, more as a sample use-case. We should use the word profiling only in the formal sense. This formal meaning does cause future trouble when life changes, but then you just define a new profile... However that doesn't mean we should formally constrain something that is not necessary to formally constrain, when we really only want to put out a useful subset.</div><span><font color="#888888"><div><br></div><div>John</div></font></span></div><div class="gmail_extra"><span><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><div class="gmail_quote">On Mon, Jun 27, 2016 at 8:47 AM, Adrian Gropper <span dir="ltr"><<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi John and Debbie,<br><br></div>Let's stipulate the universality of the confidentiality classifications. My question remains: What are we profiling and why?<br><br></div>To put this in specific FHIR and OAuth terms: <br><br>-
Would a FHIR resource server offer different patient-level resource
types to an authorization server controlled by a patient vs. one
controlled by a licensed practitioner?<br><br></div>- Is there an
objection to offering the full set of FHIR patient-level resource types
for an AS to apply policy to whether or not a particular RS chooses to
also bundle resource-types based on confidentiality classifications or
any other business logic they choose?<span><font color="#888888"><br><br></font></span></div><span><font color="#888888">Adrian</font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 27, 2016 at 9:45 AM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><p dir="ltr">I agree with something useful.<br></p>
<p dir="ltr">Aren't we profiling common resource sets and scopes for a FHIR RS; Something that could be use generically by all but perhaps extended if need be?</p>
<p dir="ltr">I think FHIR RS shares resource sets/scopes it supports to UMA AS. Period. No hints further (c on Adrians list) User sets preferences for sharing on those resource sets. If a release seems like a logical RS set - then let's add to the list.</p>
<p dir="ltr"> <br></p>
</span><div><div><div class="gmail_quote">On Jun 27, 2016 8:49 AM, "John Moehrke" <<a href="mailto:johnmoehrke@gmail.com" target="_blank">johnmoehrke@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Adrian,<div><br></div><div>Small but important clarification. The confidentiality classifications I gave are universal in healthcare. They are used in all forms of HL7, including FHIR and CDA. They are used in DICOM. They are used in IHE XDS/XCA and Direct. There is even a mapping to 13606 equivalent risk scale. So by starting with this group you are not picking something special for FHIR, but you are picking something that works with FHIR and other exchanges. In all of these cases this value-set is built right into the core of each of these standards. We could use a smaller subset, like older CDA did. Note this set also supports when data has been de-identified and thus moved to a lower risk, where lower risk is an assessment and an appropriate movement down the scale. So it even works where differential-privacy might move the data down to "M" or "L".</div><div><br></div><div>Are we tying to determine the FINAL list of scopes? Or just a starter set that seems to be useful? I was hoping we were just looking for something useful. I understand that our need is to enable interoperability, as the scopes do need to be agreed to by all parties. Thus this starter set just gets us back to focusing on the HEART specifics. Scopes are infinitely expandable so the starter set can be enhanced or even replaced (deprecated) later.</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 Sun, Jun 26, 2016 at 11:03 PM, Adrian Gropper <span dir="ltr"><<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thank you John for making things clear. Changing the subject line of my "Is HEART Profiling Privacy?" thread does not solve the problem but I do appreciate and respect Eve's intent.<br><br></div><div>I'm not sure the OpenID Connect analogy is useful for HEART or for UMA in general.<br><br></div><div>I claim that building on FHIR Confidentiality Classification is beyond HEART's charter. Patient Privacy Rights would love to participate in that discussion with whomever in HL7 wants to join in but it's not easy to see who else would be at that table and I don't see anyone clamoring to charter that group. For reference, I've attache a nice study of what might be involved in such an exercise.<br><br></div><div>I hope UMA does not force HEART to profile privacy. As John makes clear, FHIR resource types are not being designed to make privacy classifications or patient understanding of privacy issues particularly easy or hard. I suspect the same thing is true outside of healthcare.<br><br></div><div>My suggestion does not require that HEART profiles privacy or make use of confidentiality classification. A HEART resource server (a) can publish the list of resource types it supports, and<br></div><div>(b) can post to a specific HEART AS which resource types are or are not available for a particular resource registration, and maybe<br></div><div>(c) can optionally post explanations, hints, resource type groupings, or examples to the specific HEART AS. This would enable a RS to send the equivalent of their current Release of Information form to the AS.<br><br></div><div>Note that (c) is optional. Whether (c) is there or not, FHIR supports whatever granularity it supports and there's no reason an AS should not choose to take advantage of that.<br></div><div><br></div><div>Therefore (a) and (b) together allow any RS to register with any AS and it's up to the AS to map the resource types into policy choices for the resource owner. Rather than HEART profiling privacy, i suggest we allow ASs to compete on how to present the privacy issues to the resource owner.<br><br></div><div>Adrian<br></div><div><br></div><div><br><br></div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Sun, Jun 26, 2016 at 9:21 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Eve,<div><br></div><div>It would seem that we would indeed have this figured out. But reality is that we never quite talk about it so bluntly, mostly because classifying healthcare data is so very hard. Further the various ways that would be logical don't fall nicely upon the logical ways that data can be segmented. That is the way that people would like to segment their data is according to how sensitive it is; yet this doesn't align with FHIR resources, or departments, or function, etc... Plus data changes sensitivity based on current medical knowledge (HIV was very sensitive a few years ago, today it tends to trend closer to normal data).</div><div><br></div><div>So the best I have to offer is the _confidentiality classifications we have in the security-tags: It is a scale that centers around Normal - that group of data that everyone agrees is the typical healthcare data (mathematically normal). Think of it as a risk scale of 6 different risk quantum. All data MUST have one of these values assigned to it.</div><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><div><br></div><div>so U, L, M, N, R, V --- definitions are on the page above.<br></div><div><br></div><div>Is this a good solution? NO! but it does exist today.</div><div><br></div><div>More on my blog article</div><div> <a href="https://healthcaresecprivacy.blogspot.com/2015/07/how-to-set-confidentialitycode.html" target="_blank">https://healthcaresecprivacy.blogspot.com/2015/07/how-to-set-confidentialitycode.html</a></div><div>or </div><div> <a href="https://healthcaresecprivacy.blogspot.com/2016/01/fhir-oauth-scope.html" target="_blank">https://healthcaresecprivacy.blogspot.com/2016/01/fhir-oauth-scope.html</a></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"><div><div>On Sun, Jun 26, 2016 at 11:18 AM, Eve Maler <span dir="ltr"><<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div dir="ltr"><div>This message is intended to give shape to our profiling efforts. I apologize in advance if I "step in it" due to my lack of HL7 or FHIR knowledge. :-)</div><div><br></div>Given our <a href="https://bitbucket.org/openid/heart/wiki/Alice_Shares_with_Physicians_and_Others_UMA_FHIR" target="_blank">first sharing scenario</a> (in the latest use case) of providing basic data before a first visit, are there various subsets or supersets of such data, e.g., in different jurisdictions, that Alice would be expected to provide, or one obvious and universally understood data set? I'm guessing that payment data is one subset of data that doesn't apply in some jurisdictions, whereas quite a lot of "medically related data" would generally be considered desirable to share if available.<div><br></div><div>What I'm going for here is: If you could have a system of "keywords" representing virtual clipboard-type data sets and how you want them shared, what's the smallest arrangement of keywords that would do the trick?</div><div><br></div><div>By (very rough) analogy, look at how <a href="http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims" target="_blank">OpenID Connect standardizes client requests for claims using scope values</a>. It rolls up multiple identity claims under single scope names, so that "openid" gives the client full access at the UserInfo endpoint, "profile" gets access to 14 specific claims, "email" gets access to two claims, etc.</div><div><br></div><div>UMA gives us two dimensions to play with, so it could be like this:</div><div><br></div><div>Potential resource sets to access (I'm totally making this up! for all I know, HL7 figured this out 10 years ago and it doesn't look anything like this...):</div><div><ul><li>BasicVirtualClipboardData<br></li><li>FinancialVirtualClipboardData (or a unique version per jurisdiction?)</li><li>AllVirtualClipboardData (an aggregation of the two of them)</li></ul><div>Potential scopes of action across them (same for each one? it doesn't have to be that way, and other resource sets might have deidentified-read options or something...):</div></div><div><ul><li>read</li><li>write</li></ul></div><div>Note that the scope work already begun in our OAuth FHIR profile, coming from the SMART on FHIR work, gives us ideas for things like a "read" verb and a "write" verb, but for right now, we can think outside the box if that's the right thing to do.</div><span><font color="#888888"><div><div><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><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 <a href="tel:%2B1%20425.345.6756" value="+14253456756" target="_blank">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br><b>ForgeRock Summits and UnSummits</b> <a href="http://summits.forgerock.com/" target="_blank">are coming to</a> <b>Sydney, London, and Paris!</b></p></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div></font></span></div>
<br></div></div>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">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></div>
<br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">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></div></div><span><font color="#888888">-- <br><div 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:rgb(31,73,125)">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"></span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:rgb(5,99,193)">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:rgb(31,73,125)"></span>
</div></div></div></div></div></div></div></div>
</font></span></div>
</blockquote></div><br></div>
<br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">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>
</div></div><br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">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 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:rgb(31,73,125)">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"></span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:rgb(5,99,193)">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:rgb(31,73,125)"></span>
</div></div></div></div></div></div></div></div>
</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" target="_blank">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></div></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</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:rgb(31,73,125)">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"></span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:rgb(5,99,193)">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:rgb(31,73,125)"></span>
</div></div></div></div></div></div></div></div>
</div></div>