<div dir="ltr"><div>@Eve - yes I know its client but I'm really hung up on the token generation/choices. Thanks for the tweaks.</div><div><br></div><div>I know we clarified that the release form is NOT consent in one of our earlier meetings but is this (release of information) what I have heard others refer to as simple consent? During this process would access to problems/meds/allergies be included in that authorization/consent flow? I visualized more than demographics in the conversation.</div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 5, 2015 at 9:21 PM, Justin Richer <span dir="ltr"><<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div text="#000000" bgcolor="#FFFFFF">
Thank you, Adrian, this is a great reference! I think your
annotations make sense as well, things should map pretty plainly to
the OAuth process. The tricky part (that we got a start on today) is
going to be the scopes bits and getting those right.<br>
<br>
For an UMA flow, it's also similar, except that the "who can see it"
is a set of claims instead of the client application.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- Justin</font></span><div><div class="h5"><br>
<br>
<div>On 8/5/2015 9:12 PM, Adrian Gropper
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>I've attached a very typical Release of Information
authorization. I've annotated the 5 elements common to all
such documents that I have ever seen. The stuff outside if
the rectangles is more or less optional. <br>
<br>
</div>
This form covers one direction of the EHR-PHR Use Case. It
is presented to the Custodian (the patient or their
designate ) and approved by them by the Resource Server and
pre-filled with information supplied by the Client, if
available. <br>
<br>
In some cases, the Client information is not available at
the time the Authorization form is signed. In that case, it
will be up to the Authorization Server to consider the
Client and User information and provide the authorization to
the Resource Server.<br>
<br>
</div>
The Resource Server has the final say in all cases and could
decide to ignore the authorization based on local or
jurisdictional policy. This is outside the control of the
Resource Owner and likely to be out of scope for HEART in all
use-cases.<br>
<br>
</div>
<div>This ROI Authorization Form is the only "consent" that I'm
aware of in clinical IT. Patients are asked to sign other
documents, including:<br>
</div>
<div>Registration Form, Notice of Privacy Practices, and
Treatment Consent but none of these has anything to do with
sharing of health data (except for HIPAA TPO which we will not
get into here.)<br>
</div>
<div><br>
</div>
Adrian<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Aug 5, 2015 at 8:27 PM, jim
kragh <span dir="ltr"><<a href="mailto:kragh65@gmail.com" target="_blank">kragh65@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div dir="ltr">Thanks for sharing,... informative and
constructive in reaching the patient end point.
<div><br>
</div>
<div>May all have a nice evening!</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">
<div>
<div>On Wed, Aug 5, 2015 at 3:26 PM, Debbie
Bucci <span dir="ltr"><<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.com</a>></span>
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div>
<div>
<div dir="ltr">
<div>Attendees:</div>
<div>Eve Maler</div>
<div>Justin Richer</div>
<div>Josh Mandel</div>
<div>Adrian Gropper</div>
<div>Thomas Sullivan </div>
<div>Debbie Bucci</div>
<div><br>
</div>
<div>We have decided to delineate between
mechanical and semantic scope docs.</div>
<div><br>
</div>
<div>For the PCP <-> PHR use case:</div>
<div><br>
</div>
<div>The pre determined choice token
confidential token choice and exactly what
information needs (example:
PHR's authorization endpoint) to be shared in
advance between the PCP's EHR and Alice's PCP
was left out of the discussion for now.</div>
<div><br>
</div>
<div>There is one basic mechanical Oauth
generic flow that occurs twice in the use
case.</div>
<div><br>
</div>
<div>Given the group has generally agreed that
the SMART specifications are a good place to <em><strong>start
</strong>... </em>for this particular use
case the only semantic FHIR scope that is
necessary is the patient/*.read scope that
grants permission to read any resource for the
current patient.</div>
<div><br>
</div>
<div>During the registration process Alice
should be able to select at a fine grain level
which resources she is willing to share with
the PHR. This mimic's a specific process
- Adrian please provide. This information
will be used to generate the access token.</div>
<div><br>
</div>
<div>The one thing left at the end of the
discussion is whether the patient record is
implicit or explicitly stated. This is a
design decision that may make a difference as
we move towards our next use case in
which delegation is a factor.</div>
<div><br>
</div>
<div>Corrections/updates appreciated. </div>
<div><br>
</div>
<div><br>
</div>
</div>
</div></div></blockquote></div></div></blockquote></div></div><pre><br></pre>
</blockquote>
<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" target="_blank" rel="noreferrer">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><br></div></div>