Debbie's comment suggests two things:<div><br></div><div>First, whatever the HEART protocols are, the UMA AS (wherever it is) must be able to display a form that's functionally equivalent to the NYP ROI authorization _before_ an actual requesting party or client are on the scene. The actual authorization, equivalent to signing the ROI form once the client is filled in, must be able to happen automatically otherwise we might as well skip the UMA pieces.</div><div><br></div><div>Second, the ROI form would be enhanced by adding a Confidentiality Code enabled feature. Let's put this enhancement aside for now because we can't count on all resources supporting the codes and we don't really know how to implement them to improve the user experience. Obviously support for the confidentiality codes would improve things for everyone but I don't think they solve any critical path problems.</div><div><br></div><div>Back to the HEART approach to ROI form. Let's get clear on what is "prior consent" and what is "authorization" in a patient-centered approach that allows for an AS separate from any particular FHIR resource server. Since the "authorization" step is effectively automated through the AS, the patient (grantor, to be exact) interfaced "consent" actually involves two sub-steps I will call C1 and C2. C1 is where the patient specifies, or at least agrees to, a particular UMA AS as their proxy. C1 is clearly a form hosted by the FHIR resource server, typically an EHR. C2 is where the patient makes whatever selections (with or without benefit of confidentiality codes) on something that looks like the NYP ROI form. C2 is clearly a form hosted by the authorization server defined in C1.</div><div><br></div><div>I believe this is the only way HEART can work. Whatever we do, prior consent will be split between an AS specification at the RS and a policy capture at the AS.</div><div><br></div><div>The HEART profiles need to make this split of the prior consent process palatable to the FHIR resource servers and friendly to the patient. This could create a tension between RSs wanting to customize and compete on their user experience and the patient's potential interest in having all prior consent forms presented in a consistent way regardless of the RS. This is a classic problem in standards design. We need to address this reality first and provide input to UMA and maybe to FHIR to make sure they enable this combination of competition by RS to improve ROI form usability and consistency across resource registration user experience regardless of RS or jurisdictional constraints such as HIPAA or 42CFR Part2.</div><div><br></div><div>Adrian</div><div><br></div><div><br></div><div><br></div><div><br><br>On Wednesday, July 20, 2016, John Moehrke <<a href="mailto:johnmoehrke@gmail.com">johnmoehrke@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">Yeah</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Jul 20, 2016 5:23 PM, "Debbie Bucci" <<a href="javascript:_e(%7B%7D,'cvml','debbucci@gmail.com');" target="_blank">debbucci@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="Calibri"><p dir="ltr">Glen </p>
<p dir="ltr">What struck me about the ROI is the potential to use as an example for general use. All along Adrian had been trying to point out the similarities and only until recently have I begun to understand the how parts of the UMA protocol could be used to effectively describe (and essentially is ) an authorization for release of info.</p>
<p dir="ltr">I'd also like to propose that although the confidentiality codes may not be used in FHIR the vocabulary has been accepted by HL7 so why couldn't that be used as a scope that all would consume and understand? How the value iRS chooses to process out of scope. Would f my that be a baby step in the right direction?</p>
<br><br>On July 19, 2016, at 12:34 PM, "Glen Marshall [SRS]" <<a href="javascript:_e(%7B%7D,'cvml','gfm@securityrs.com');" target="_blank">gfm@securityrs.com</a>> wrote:<br><br><br></font>
<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif">While I think that mapping a Release of Information form onto UMA protocol data would be useful as a proof of concept exercise, I am left wondering:<u></u><u></u></span></p>
<p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-family:"Helvetica",sans-serif">The form itself is just an instance.<u></u><u></u></span></p>
<p style="margin-left:1.0in">
<u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-family:"Helvetica",sans-serif">Has it been vetted for peer review at the policy level, i.e., can it be easily adapted for more general use?<u></u><u></u></span></p>
<p style="margin-left:1.0in">
<u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-family:"Helvetica",sans-serif">Is there a compendium of federal and state requirements we can reference, or can we use a reasonable guess to start the analysis without extensive debate? We need to avoid the
42CFR quicksand, and similar well-bounded cases. <u></u><u></u></span></p>
<p style="margin-left:1.0in">
<u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-family:"Helvetica",sans-serif">Is there some general user experience design guidance – paper or on-screen – for collecting Release of Information from patients or their authorized representatives?<u></u><u></u></span></p>
<p style="margin-left:1.0in">
<u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-family:"Helvetica",sans-serif">How can we minimize the cognitive challenges that sick people have when presented with a sheaf of forms to sign when seeking treatment?<u></u><u></u></span></p>
<p style="margin-left:1.0in">
<u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-family:"Helvetica",sans-serif">Is this work in-scope for HEART?
<u></u><u></u></span></p>
<p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-family:"Helvetica",sans-serif">Are we going to propose a standardized API for such mapping?
<u></u><u></u></span></p>
<p style="margin-left:1.0in">
<u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-family:"Helvetica",sans-serif">Is this work in-scope for HEART?
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif">I think the most useful outcome of this line if inquiry is proof that OAuth and UMA can be used for health care data access control, without extensions or with a small set of extensions.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif">Glen<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Helvetica",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Glen F. Marshall<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Consultant<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Security Risk Solutions, Inc.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">698 Fishermans Bend<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Mount Pleasant, SC 29464<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Tel: <a href="tel:%28610%29%20644-2452" value="+16106442452" target="_blank">(610) 644-2452</a>
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Mobile: <a href="tel:%28610%29%20613-3084" value="+16106133084" target="_blank">(610) 613-3084</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif"><a href="javascript:_e(%7B%7D,'cvml','gfm@securityrs.com');" target="_blank">gfm@securityrs.com</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif"><a href="http://www.securityrisksolutions.com/" target="_blank"><span style="color:#0563c1">www.SecurityRiskSolutions.com</span></a><u></u><u></u></span></p>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
<br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="javascript:_e(%7B%7D,'cvml','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>
</blockquote></div>