<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 dir="auto"><br></div><div dir="auto">John</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, May 12, 2018, 8:32 PM Debbie Bucci <<a href="mailto:debbucci@gmail.com">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_-2727781905898592474m_2121699905031834253m_-9098484486977907449h5" dir="auto"><div dir="ltr"><div><div class="m_-2727781905898592474m_2121699905031834253m_-9098484486977907449m_8671655064342060934m_4121745543241250012gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"></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>