<div dir="ltr">Adrian,<div><br></div><div>I understand what you are describing, and when I describe it to others this way they get really confused. The confusion comes from the fact that this model could be done today with a completely proprietary system. There is no need for standards.Well, the standards are very minimized and available today without need to define or constrain. </div><div><br></div><div>The reason for standards are when you have two systems (not people) that need to cooperate in a defined way. Specifically where each has a defined role and behavior and act upon the transaction details accordingly.</div><div><br></div><div>I agree that in the HEART scope we don't need to come up with a structured and coded consent. It is sufficient to say that the Patient has a UX with their AS. That it is a proprietary experience that the AS uses to determine what rules the patient wants to impose. There is no need to expose these rules, as the AS will be making the decisions. One only needs to expose the decisions.</div><div><br></div><div>Note this is different than HL7 CBCC scope in their work on Consent. In that case they are asked to come up with a structure to hold well formed structured and coded rules. <a href="http://healthcaresecprivacy.blogspot.com/2016/05/start-at-consent-as-fhir-resource.html">http://healthcaresecprivacy.blogspot.com/2016/05/start-at-consent-as-fhir-resource.html</a> In fact in FHIR Consent we are explicitly not including the rules and decision engine. Just how one would capture the ceremony and rules.</div><div><br></div><div>These two worlds are not mutually exclusive. The AS could use the FHIR Consent; but it is not necessary for success. </div><div><br></div><div>One way to make this more clear to everyone is to explicitly state this. One solution doesn't try to standardize the rules language as it uses UI and decision engine, the other is only focused on the rules encoding and doesn't impose UI or rules engine. The important part is that they must both be capable of handling a reasonable set of use-cases, (See FHIR Consenthttp://<a href="http://hl7-fhir.github.io/consent.html">hl7-fhir.github.io/consent.html</a> )</div><div><br></div><div>Where as in HEART we need to focus more on use of UMA and OAuth; as the decision engine and decision mechanism. We should only acknowledge this other world with encouraging but not requiring statements. UMA and OAuth can support the use-case.</div><div><br></div><div>That said, I like the way Debbie expressed it, and didn't see how you saw that as not correct. So again, I express that I am not sure I understand what you are defining as the "WHAT" needs to be solved; you continue to bring in the "HOW" to solve it. Each time you bring in the how, we get stuck on your how; and miss out on the 'what'.</div><div><br></div><div><br></div><div>John</div></div><div class="gmail_extra"><br clear="all"><div><div class="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 +1 920-564-2067<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, May 18, 2016 at 7:28 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">Debbie, you are not following my model. My model has no prior consent, no consent policy representation in FHIR or any other way, and no consent receipts. My model is purely based on the JASON model where the resource, and therefore FHIR, are under separate jurisdiction from the authorization policies. In my model, the Grantor's policies are never communicated on the wire. <div><br></div><div>Think of this as analogous to never communicating a private key of the wire. My model has no shared secrets and policies are secret. The policies associated with the FHIR resource are locked up in the UMA Authorization Server and never leave. The only thing that leaves the AS is authorization tokens.</div><div><br></div><div>Therefore, in my model (an instance of the JASON model) there is no prior consent because Bob gets his authorization, regardless of whether it's one-time or reusable, when he presents to the Authorization Server. (I will not use Authorization for Disclosure ever any more. It's to close and confusing with Authorization of Disclosure in HIPAA.)</div><div><br></div><div>Therefore, as far as the FHIR resource server is concerned, it only needs to generate an empty notification each time Bob actually accesses a resource and store the AuditEvent in case the Grantor wants to use FHIR to get an Accounting of Disclosures at a later time.</div><div><br></div><div>Adrian<br><br>On Wednesday, May 18, 2016, Debbie Bucci <<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Authorization for disclosure. Adrian if I follow you... Alice grants Dr Bob access her data (receipt generated here). Dr Bob later accesses data for the first time. Resource [authorization ??] server logs the disclosure event and optionally pushes a message via a subscription to alert Alice that her data was accessed. At some time later Alice could query for both her receipts and disclosures to verify she granted access and it was Bob who accessed her data. Seems to me these may be core to use case in a US context but peripheral to the profiles for its unclear if there would need to be any scopes or resources sets to define to support it. Defining the content of the subscription message,disclosure or receipt probably out of scope.</p>
<div class="gmail_quote">On May 17, 2016 10:55 PM, "Adrian Gropper" <<a>agropper@healthurl.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm glad to hear they're in scope. <div><br></div><div>Thing is, that notifications have two components: the endpoint and the message format. As I recall, MVCR consent receipts are more about the message format than the endpoint. I much prefer the FHIR Subscriptions approach because it doesn't trigger a standards project related to the format and therefore makes implementation much faster.</div><div><br></div><div>All three notification types are perfectly compatible with a human-readable format. In some cases, as the FHIR Subscription standard points out, having a message content at all is an unacceptable and unnecessary privacy liability. This applies to type (1) notifications where any contact with the notification endpoint triggers a query to the FHIR endpoint.</div><div><br></div><div>Type (2) notifications need to be human-formatted by definition to meet the intent of HIPAA and today's API Task Force recommendation. Nothing would be served by trying to standardize the format as each FHIR endpoint has a right to issue whatever warning it feels is appropriate to the particular client and situation. Although there was interest in the API discussion today in evolving a Model Privacy Notice related to this Type (2) notification, that work, if and when it's available, is also meant for human-readable format and it was deemed unlikely to cover all of the warning situations. There are no privacy issues with Type (2) messages because they need not contain any PHI. This makes them much more user-friendly since they can be delivered via SMS and other insecure channels.</div><div><br></div><div>Type (3) notifications - A4D - are the only ones that might benefit from a standard format. Even so, standard formatting is not expected - we are perfectly happy to receive activity messages from banks and merchants even though their format is all over the place. In addition, type (3) messages do have privacy implications if they contain any PHI or even indication of the metadata. Therefore, it would be preferable to make these opaque or content-free and allow the recipient to query the FHIR server for A4D if they choose. </div><div><br></div><div>@Grahame: Does FHIR already specify an A4D resource?</div><div><br></div><div>Is the discussion above an appropriate addition to the current use-case?</div><div><br></div><div>Adrian<br><br>On Tuesday, May 17, 2016, Debbie Bucci <<a>debbucci@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Notifications were always in scope. One type of notification was in the form of a consent receipt. You may recall Sarah doing some research and comparing to ...was it HL7? The receipt could be use to acknowledge a number of state changes. </p>
<p dir="ltr">I am very familiar with topics/queues and pub/sub from my SOA infrastructure days. A brief glance at subscriptions seem to be a similar pattern.</p>
<p dir="ltr">Dont think its a scope issue. It could be a implementation choice in use cases to use a subscription to deliver a message that either acknowledges a receipt or triggers another process in the work flow</p>
<p dir="ltr">I think that would cover your 3 examples listed below.<br>
<br>
</p>
<div class="gmail_quote">On May 17, 2016 8:45 PM, "Adrian Gropper" <<a>agropper@healthurl.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As mentioned in the other thread, there are three different kinds of notification under HIPAA (and probably in the general case):<div>(1) a resource has changed - this is p53 of the NZ doc</div><div>(2) a client is being registered that requires specific affirmation by the Grantor</div><div>(3) accounting for disclosures - the resource server has been accessed by a client</div><div><br></div><div>The FHIR spec lists 4 different standards for push notifications <a href="http://hl7.org/fhir/subscription.html" target="_blank">http://hl7.org/fhir/subscription.html</a> .</div><div><br></div><div>I believe all three of these kinds of notification are in-scope for HEART. The three endpoints do not all have to be the same, do not all have to be UMA, and we may want to restrict some of the 4 options offered in the FHIR spec.</div><div><br></div><div>Can we add these three kinds of notification to the current use case as proposed by Eve?</div><div><br></div><div>Adrian</div><div><br><br>On Tuesday, May 17, 2016, Eve Maler <<a>eve.maler@forgerock.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Supplementing with the link I referred to during the call:<div><br></div><div>The UMA case study "Users Managing Delegated Access to Online Government Services" conducted by the New Zealand government available on the UMA wiki:</div><div><br></div><div><a href="http://kantarainitiative.org/confluence/display/uma/Case+Study%3A+Users+Managing+Delegated+Access+to+Online+Government+Services" target="_blank">http://kantarainitiative.org/confluence/display/uma/Case+Study%3A+Users+Managing+Delegated+Access+to+Online+Government+Services</a><br></div><div>(PDF report downloadable <a href="http://kantarainitiative.org/confluence/download/attachments/76907066/NZ%20ProjectClosureReport_PoC%20Delegations-Final%20Version%20SIG%20redacted%20Rev1.pdf?api=v2" target="_blank">here</a>)</div><div><br></div><div>...documents in Sec 8.4.3.3.3 (p. 46) a desire for "notifications" that can be achieved by sending email or by other means, with a discussion in Sec 8.4.9 (p. 53) about sending push notifications to an UMA requesting party through a mobile app from a resource owner's smart device. The case study didn't, I believe, use FHIR.</div></div><div class="gmail_extra"><br clear="all"><div><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>Check out the <a href="https://summits.forgerock.com" target="_blank">2016 schedule</a> for <b>ForgeRock Summits and UnSummits</b>!</p></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, May 17, 2016 at 7:04 AM, Debbie Bucci <span dir="ltr"><<a>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"><font color="#000000" face="Times New Roman" size="3">
</font><div style="margin:0in 0in 10pt"><font color="#000000" face="Calibri" size="3">Adrian was given the floor to discuss his concerns that he has labeled for point of reference as “Independent
Decision Support at the Point of Care for Physicians and Patients"</font></div><font color="#000000" face="Times New Roman" size="3">
</font><p style="margin:0in 0in 10pt"><font face="Calibri"><font size="3"><font color="#000000">Adrian indicated there were 4 primary functions needed.<span> </span></font></font><font color="#000000" size="3">Many in the group translated it in different
ways but Debbie’s version was:</font></font></p><font color="#000000" face="Times New Roman" size="3">
</font><ul style="list-style-type:disc;direction:ltr"><li style="font-style:normal;font-weight:normal"><p style="font-style:normal;font-weight:normal;margin-top:0in;margin-bottom:0pt">Release of Information</p></li><li style="color:rgb(0,0,0);font-family:"Calibri","sans-serif";font-size:11pt;font-style:normal;font-weight:normal"><p style="color:rgb(0,0,0);font-family:"Calibri","sans-serif";font-size:11pt;font-style:normal;font-weight:normal;margin-top:0in;margin-bottom:0pt">Notification of Disclosures</p></li><li style="color:rgb(0,0,0);font-family:"Calibri","sans-serif";font-size:11pt;font-style:normal;font-weight:normal"><p style="color:rgb(0,0,0);font-family:"Calibri","sans-serif";font-size:11pt;font-style:normal;font-weight:normal;margin-top:0in;margin-bottom:0pt">Subscribe to changes</p></li><li style="color:rgb(0,0,0);font-family:"Calibri","sans-serif";font-size:11pt;font-style:normal;font-weight:normal"><p style="color:rgb(0,0,0);font-family:"Calibri","sans-serif";font-size:11pt;font-style:normal;font-weight:normal;margin-top:0in;margin-bottom:10pt">Automated patient right of access.</p></li></ul><font color="#000000" face="Times New Roman" size="3">
</font><p style="margin:0in 0in 10pt"><font color="#000000" face="Calibri" size="3">Eve translated the bullets to both technical and policy work
out of the UMA workgroup and pointed to relevant/related publication developed
in close coordination with NZ.</font></p><font color="#000000" face="Times New Roman" size="3">
</font><p style="margin:0in 0in 10pt"><font face="Calibri"><font size="3"><font color="#000000">Josh was concerned that Adrian perhaps was proposing an
entirely new standard.<span> </span></font></font><font color="#000000" size="3">John and others
were trying to get clarification around what Adrian was referring to as Data
Blocking. </font></font></p><font color="#000000" face="Times New Roman" size="3">
</font><p style="margin:0in 0in 10pt"><font face="Calibri"><font size="3"><font color="#000000">After an hour long of healthy discussion – Josh asked if there
were any procedure on how to document to handle such a discussion within the
group<span> </span><span> </span></font></font><font color="#000000" size="3">Adrian was concerned about HEART’s
functionality/relevance in relation to his concerns.</font><font size="3"><font color="#000000"><span> </span><span> </span></font></font><font color="#000000" size="3">Hope the following points brought up in the meeting addresses these
concerns:</font></font></p><font color="#000000" face="Times New Roman" size="3">
</font><ul><li style="font-style:normal;font-weight:normal"><p style="font-style:normal;font-weight:normal;margin-top:0in;margin-bottom:0pt">HEART’s function is not to create standards but
to create profiles of existing recognized standards to encourage interoperable
implementations of these standards.<span> </span>Please
see : <a href="http://openid.net/wg/heart/charter/" target="_blank"><font color="#0000ff">http://openid.net/wg/heart/charter/</font></a></p></li><li style="color:rgb(0,0,0);font-family:"Calibri","sans-serif";font-size:11pt;font-style:normal;font-weight:normal"><p style="color:rgb(0,0,0);font-family:"Calibri","sans-serif";font-size:11pt;font-style:normal;font-weight:normal;margin-top:0in;margin-bottom:0pt">All members are encouraged to bring use cases to
the group to consider.<span> </span>The functional
use case is broken down into technical functionalities that are flagged as core
or peripheral to the standards being considered under HEART.</p></li><li style="color:rgb(0,0,0);font-family:"Calibri","sans-serif";font-size:11pt;font-style:normal;font-weight:normal"><p style="color:rgb(0,0,0);font-family:"Calibri","sans-serif";font-size:11pt;font-style:normal;font-weight:normal;margin-top:0in;margin-bottom:10pt">We acknowledge that with both the Standards and
profiles, there may be implementation decisions made to bridge gaps where
existing functionality does not exist.<span>
</span>We strongly encourage those implementers to officially log the gaps and
solutions they made back with the relevant Standards Bodies in order to give
feedback to future iterations of the Standards.<span> </span></p></li></ul><div style="color:rgb(0,0,0);font-family:"Calibri","sans-serif";font-size:11pt;font-style:normal;font-weight:normal;margin-top:0in;margin-bottom:10pt"><span></span>Standards development is an iterative
process and versioning control of standards and specs are an implementation reality we have to deal with. Changes are made incrementally<span> </span></div><font color="#000000" face="Times New Roman" size="3">
</font><p style="margin:0in 0in 10pt"><font face="Calibri"><font size="3"><font color="#000000">We concluded the discussion by asking Adrian to develop a
functional use case to bring to the group for consideration. <span> </span></font></font><font color="#000000" size="3">Subsequently there has been a recap discussion
posted prior to the notes that we will append to these meeting notes to round
out context to the discussion</font></font></p><font color="#000000" face="Times New Roman" size="3">
</font><p style="margin:0in 0in 10pt"><font face="Calibri"><font color="#000000"><font size="3">Next week’s meeting (May 23</font><sup><font size="2">rd</font></sup></font><font color="#000000" size="3">) will focus on the
comment submitted by Mike Jones re:</font><span><font color="#000000" size="3">
</font></span><font color="#000000" size="3">suggested changes to the HEART profile.</font><span><font color="#000000" size="3">
</font></span><font color="#000000" size="3">Additionally, if permissible, we will revisit and consider the Argonaut
report and their recommendations as part of this review.</font><span><font color="#000000" size="3"> </font></span><font color="#000000" size="3">All members interested that may have input to the impending updates, please
make it a point to attend. </font></font></p><font color="#000000" face="Times New Roman" size="3">
</font><p style="margin:0in 0in 10pt"><font face="Calibri"><b><span><font color="#000000" size="3"> </font></span><font color="#000000" size="3">AI:</font></b><font color="#000000" size="3"> Justin is developing a step by step
analysis for us to consider.</font></font></p><font color="#000000" face="Times New Roman" size="3">
</font><p style="margin:0in 0in 10pt"><font face="Calibri"><font size="3"><font color="#000000">Will cancel the next two meetings due to conflicts: <span> </span></font></font><font color="#000000" size="3">May 30</font><sup><font color="#000000" size="2">th</font></sup><font color="#000000" size="3"> (US holiday) and June 5</font><sup><font color="#000000" size="2">th</font></sup><font color="#000000" size="3">
(Cloud Identity Summit )</font></font></p><font color="#000000" face="Times New Roman" size="3">
</font><div style="margin:0in 0in 10pt"><font face="Calibri"><font color="#000000"><font size="3">On June 12</font><sup><font size="2">th</font></sup></font><font color="#000000" size="3"> We should be prepared to go back to
the current use case </font></font><a href="https://bitbucket.org/openid/heart/wiki/Alice_Shares_with_Physicians_and_Others_UMA_FHIR" target="_blank"><font color="#0000ff" face="Calibri" size="3">https://bitbucket.org/openid/heart/wiki/Alice_Shares_with_Physicians_and_Others_UMA_FHIR</font></a><font face="Calibri"><span><font color="#000000" size="3"> </font></span><font color="#000000" size="3">and stay with that use case until we complete
our final draft semantic profile.</font></font></div><div style="margin:0in 0in 10pt"><font color="#000000" face="Calibri" size="3">Adrian's new use case is the next in the queue and welcome any others that folk may want to submit.</font></div><div style="margin:0in 0in 10pt"><font color="#000000" face="Calibri" size="3"><br></font></div><font color="#000000" face="Times New Roman" size="3">
</font></div>
<br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a>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>
</blockquote></div>
<br><br>-- <br><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><br>
</blockquote></div>
</blockquote></div><br><span class="HOEnZb"><font color="#888888"><br>-- <br><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><br>
</font></span></blockquote></div><span class="HOEnZb"><font color="#888888">
</font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br>-- <br><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><br>
</font></span><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></div>