[Openid-specs-heart] Dissecting the Release of information form

Debbie Bucci debbucci at gmail.com
Fri Jul 22 12:11:44 UTC 2016


Adrian

I mostly agree with ( or at least understand !) your POV

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)

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.

On Jul 22, 2016 12:39 AM, "Adrian Gropper" <agropper at healthurl.com> wrote:
>
> Debbie's comment suggests two things:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Adrian
>
>
>
>
>
> On Wednesday, July 20, 2016, John Moehrke <johnmoehrke at gmail.com> wrote:
>>
>> Yeah
>>
>>
>> On Jul 20, 2016 5:23 PM, "Debbie Bucci" <debbucci at gmail.com> wrote:
>>>
>>> Glen
>>>
>>> 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.
>>>
>>> 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?
>>>
>>>
>>>
>>> On July 19, 2016, at 12:34 PM, "Glen Marshall [SRS]" <gfm at securityrs.com>
wrote:
>>>
>>>
>>> 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:
>>>
>>> ·         The form itself is just an instance.
>>>
>>> o   Has it been vetted for peer review at the policy level, i.e., can
it be easily adapted for more general use?
>>>
>>> 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.
>>>
>>> o   Is there some general user experience design guidance – paper or
on-screen – for collecting Release of Information from patients or their
authorized representatives?
>>>
>>> o   How can we minimize the cognitive challenges that sick people have
when presented with a sheaf of forms to sign when seeking treatment?
>>>
>>> o   Is this work in-scope for HEART?
>>>
>>> ·         Are we going to propose a standardized API for such mapping?
>>>
>>> o   Is this work in-scope for HEART?
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> Glen
>>>
>>>
>>>
>>> Glen F. Marshall
>>>
>>> Consultant
>>>
>>> Security Risk Solutions, Inc.
>>>
>>> 698 Fishermans Bend
>>>
>>> Mount Pleasant, SC 29464
>>>
>>> Tel: (610) 644-2452
>>>
>>> Mobile: (610) 613-3084
>>>
>>> gfm at securityrs.com
>>>
>>> www.SecurityRiskSolutions.com
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-heart mailing list
>>> Openid-specs-heart at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160722/d87e58a7/attachment.html>


More information about the Openid-specs-heart mailing list