<div dir="ltr"><div>Thread update:</div><div><br></div><div><br></div><div>I am late in posting meeting notes but I want to address this specific issue.</div><div><br></div><div>The HEART WG met on May 14th. </div><div><br></div><div>We discussed the pros and cons of adding the de-identification scope. Part of the discussion focused on needs for US Healthcare (not sure it would gain traction ) to potentially being helpful to support areas of interest such as Health IOT devices and noting that adding the scope is consistent with the approach we have taken thus far. We believe this requires additional discussion.</div><div><br></div><div>The group decided it was best to move ahead with the current updates to the HEART profiles - as originally agreed to ( briefly: Smart alignment with use of aud to note resource server to retrieve data from , support for public clients and UMA 2.0 spec) and to continue the discussion of the de-identification scope and perhap further clarification - guidance in future releases.</div><div><br></div><div>No real discussion on BTG beyond acknowledgement it was already in the approved prior specs.</div><div><br></div><div>I hope this generally aligns with the discussion.</div><div><br></div><div>Wanted to be sure to post this before I move to ask the OpenID Foundation to move our updated drafts to broader review & vote.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 13, 2018 at 9:55 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">Debbie, I don’t understand your explanation. Who is evaluating the requesting party’s claims and generating an access token when Alice is unconscious? Is it the RS (as in the Adrian Clause) or the AS (as in delegation using UMA)?</div></div><div dir="auto"><br></div><div dir="auto">If it’s the RS and OAuth then the AS and RS are operated by the same entity and the Adrian’s Clause distinction is moot.</div><div dir="auto"><br></div><div dir="auto">If it’s a delegated AS, a separate operator from the RS, then it’s an UMA AS that is evaluating the Requesting Party claims. </div><div dir="auto"><br></div><div dir="auto">Which of these two scenarios are we discussing when Alice is unconscious?</div><span class="HOEnZb"><font color="#888888"><div dir="auto"><br></div><div dir="auto">Adrian</div></font></span><div class="HOEnZb"><div class="h5"><div><br><div class="gmail_quote"><div>On Sun, May 13, 2018 at 7:30 AM Debbie Bucci <<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Adrian<div dir="auto"><br></div><div dir="auto">This conversation is focused specifically on scopes. I'd prefer we stick to the subject. That said...</div><div dir="auto"><br></div><div dir="auto">HEART is a set of layered constrained profiles that are layered on top of/extend OAUTH functionality. Implementing the HEART compliant profiles does not require UMA or Openid connect for every single use case. </div><div dir="auto"><br></div><div dir="auto">Our phr virtual clipboard use case has been profiled both ways. With and without uma (though believe we used openid for both)</div><div dir="auto"><br></div><div dir="auto">The example I used ...( agree may be ignored by an highly regulated US EHR system) Alice has proactively set up her delegations to allow her family access to information she has DIRECT control over. </div><div dir="auto"><br></div><div dir="auto">If Alice is unconscious, that access is not going to happen real time. She is not *present* on line to assist in the generation of that access token. Straight up OAUTh does not support. That does imply the use of UMA.</div></div><div dir="auto"><br><br><div class="gmail_quote" dir="auto"><div>On Sun, May 13, 2018, 2:06 AM Adrian Gropper <<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">Before continuing this conversation about scopes let’s see if we all understand what HEART is.</div><div dir="auto"><br></div><div dir="auto">Quoting Debbie, “heart use cases have assumed a phr... “ is very very confusing to me. A phr does not need HEART. It’s a patient-controlled OAuth client and can be connected via FHIR / OAauth without UMA at all. </div><div dir="auto"><br></div><div dir="auto">What am I missing?</div><div dir="auto"><br></div><div dir="auto">Adrian</div><div dir="auto"><br></div><div dir="auto"><br></div><br><div class="gmail_quote"><div>On Sun, May 13, 2018 at 1:23 AM John Moehrke <<a href="mailto:johnmoehrke@gmail.com" rel="noreferrer" target="_blank">johnmoehrke@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Hi all<div dir="auto"><br></div><div dir="auto">I am not indicating there is no place for HEART in these. </div><div dir="auto"><br></div><div dir="auto">Btg as an indicator of patient willingness to authorize appropriate btg override, or not... This seems within the scope of HEART. It is however not the medical decision, just the patient allowance or forbiddance. As such, it is not likely to considered. Which might be Adrian's point. I am not against this meaning of btg in HEART.</div><div dir="auto"><br></div><div dir="auto">As to deid, I'm also encouraging this. I just want it to be realistic. An indicator in the token about a level-of-anonimity would be useful and practical. This can be used when the patient has engaged with an app/recipient that can accept deid data. But most deid requires data analysis driven deid that is done on the population of data and is aware of usecases data needs and tolerance. So it is unlikely that a patient selected deid algorithm will fit. Thus what the useful meaning and value is not clear. Binary yes/no doesn't seem useful. More specific has no vocabulary available. Eventually there needs to be a deid LOA vocabulary, like nist 800-63 has for Auth.</div><div dir="auto"><br></div><div dir="auto">Both of these are exciting buzzwords, so it is understandable why they might be consideration, but the role HEART can play is limited. Limited but useful is the question. So to be clear, I am not discouraging it, just being realistic. It is possible that adding this complexity to HEART is not helpful to overall acceptance.</div></div><div dir="auto"><div dir="auto"><br></div><div dir="auto">John</div></div><br><div class="gmail_quote"><div>On Sat, May 12, 2018, 8:32 PM Debbie Bucci <<a href="mailto:debbucci@gmail.com" rel="noreferrer" target="_blank">debbucci@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>All</div><div dir="auto"><br></div><div dir="auto">I am confused. If you take a good look at the specs, heart is referencing HL7 standards for confidentiality and sensitivity codes. </div><div dir="auto"><br></div><div dir="auto"> Heart use cases have assumed a phr /health app is part of the patient portfolio. In an emergency today, a loved one or caregiver is typically drilled for the info as a place to start. Wouldn't it be handy if family could request what is known/owned by patient to assist in an emergency? <br></div><div dir="auto"><div dir="auto"><br></div><div dir="auto">I know resources can be tagged for security in the <meta> section but how does a client signal to a resource server thats its authorized to recieve confidential information? How the authorization server makes those decisions [consent or access control methods] are out of scope for HEART but the representation of that decision - I thought was in scope.</div><div dir="auto"><br></div><div dir="auto">Even if the header had a btg flag, wouldn't there also be a token as part of the request as well?</div><div dir="auto"><br></div><div dir="auto">I have not read the deidentified data blog yet. Will do before Mondays call.</div><div dir="auto"><br></div><div dir="auto">I know we would like to update the specs to align with SMART and recognize UMA 2.0. SMART Auth guide is silent on these issues. With the exception of the deidentification scope the other scopes were agreed upon in the last round of specs. </div><div dir="auto"><br></div><div dir="auto">Deb</div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-5133249243731048523m_6343824430955084218m_2607270094893240647m_-8853989802727179259m_-2727781905898592474m_2121699905031834253m_-9098484486977907449h5" dir="auto"><div><div><div class="m_-5133249243731048523m_6343824430955084218m_2607270094893240647m_-8853989802727179259m_-2727781905898592474m_2121699905031834253m_-9098484486977907449m_8671655064342060934m_4121745543241250012gmail_signature"><div><div><div><div><div><div><div><div><div><div><div><div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote></div></div></blockquote></div></div>
</blockquote></div></div></div>
</blockquote></div>
</blockquote></div></div>-- <br><div class="m_-5133249243731048523m_6343824430955084218m_2607270094893240647gmail_signature" data-smartmail="gmail_signature"><div><div><div><div><div><div><div><br><div>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></div><div><span style="color:rgb(31,73,125);font-family:Arial,sans-serif;font-size:10pt">DONATE: </span><span style="font-family:Arial,sans-serif;font-size:10pt;color:blue"><a href="https://patientprivacyrights.org/donate-3/" style="color:rgb(17,85,204)" rel="noreferrer" target="_blank">https://<wbr>patientprivacyrights.org/<wbr>donate-3/<br></a></span></div></div></div></div></div></div></div></div></div>
</blockquote></div></div></blockquote></div></div>-- <br><div dir="ltr" class="m_-5133249243731048523gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><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></div><div dir="ltr"><span style="color:rgb(31,73,125);font-family:Arial,sans-serif;font-size:10pt">DONATE: </span><span style="font-family:Arial,sans-serif;font-size:10pt;color:blue"><a href="https://patientprivacyrights.org/donate-3/" style="color:rgb(17,85,204)" target="_blank">https://<wbr>patientprivacyrights.org/<wbr>donate-3/</a></span></div></div></div></div></div></div></div></div></div>
</div></div></blockquote></div><br></div>