<p dir="ltr">Adrian</p>
<p dir="ltr">I mostly agree with ( or at least understand !) your POV</p>
<p dir="ltr">In the short term - if UMA is used I believe it's because of a some value add to the resource servers - we have yet to clearly articulate what that is. (Separate thread/discussion)</p>
<p dir="ltr">What I do not agree with is delaying the use of a Confidentiality Code. I think it should be a scope that is understood for all HEART authorizations and dealt with by the RS (not ignored!) for all ( UMA and OAUTH) authorizations. Populating FHIR meta is one way for a FHIR RS could handle but the HOW is out of scope for HEART.<br></p>
<p dir="ltr">On Jul 22, 2016 12:39 AM, "Adrian Gropper" <<a href="mailto:agropper@healthurl.com">agropper@healthurl.com</a>> wrote:<br>
><br>
> Debbie's comment suggests two things:<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Adrian<br>
><br>
><br>
><br>
><br>
><br>
> On Wednesday, July 20, 2016, John Moehrke <<a href="mailto:johnmoehrke@gmail.com">johnmoehrke@gmail.com</a>> wrote:<br>
>><br>
>> Yeah<br>
>><br>
>><br>
>> On Jul 20, 2016 5:23 PM, "Debbie Bucci" <<a href="mailto:debbucci@gmail.com">debbucci@gmail.com</a>> wrote:<br>
>>><br>
>>> Glen<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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?<br>
>>><br>
>>><br>
>>><br>
>>> On July 19, 2016, at 12:34 PM, "Glen Marshall [SRS]" <<a href="mailto:gfm@securityrs.com">gfm@securityrs.com</a>> wrote:<br>
>>><br>
>>><br>
>>> 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:<br>
>>><br>
>>> · The form itself is just an instance.<br>
>>><br>
>>> o Has it been vetted for peer review at the policy level, i.e., can it be easily adapted for more general use?<br>
>>><br>
>>> o 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. <br>
>>><br>
>>> o Is there some general user experience design guidance – paper or on-screen – for collecting Release of Information from patients or their authorized representatives?<br>
>>><br>
>>> o How can we minimize the cognitive challenges that sick people have when presented with a sheaf of forms to sign when seeking treatment?<br>
>>><br>
>>> o Is this work in-scope for HEART? <br>
>>><br>
>>> · Are we going to propose a standardized API for such mapping? <br>
>>><br>
>>> o Is this work in-scope for HEART? <br>
>>><br>
>>> <br>
>>><br>
>>> 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.<br>
>>><br>
>>> <br>
>>><br>
>>> Glen<br>
>>><br>
>>> <br>
>>><br>
>>> Glen F. Marshall<br>
>>><br>
>>> Consultant<br>
>>><br>
>>> Security Risk Solutions, Inc.<br>
>>><br>
>>> 698 Fishermans Bend<br>
>>><br>
>>> Mount Pleasant, SC 29464<br>
>>><br>
>>> Tel: (610) 644-2452<br>
>>><br>
>>> Mobile: (610) 613-3084<br>
>>><br>
>>> <a href="mailto:gfm@securityrs.com">gfm@securityrs.com</a><br>
>>><br>
>>> <a href="http://www.SecurityRiskSolutions.com">www.SecurityRiskSolutions.com</a><br>
>>><br>
>>> <br>
>>><br>
>>> <br>
>>><br>
>>><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">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
>>><br>
</p>