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

Adrian Gropper agropper at healthurl.com
Fri Jul 22 04:39:03 UTC 2016


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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','gfm at securityrs.com');>
>>
>> www.SecurityRiskSolutions.com <http://www.securityrisksolutions.com/>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> <javascript:_e(%7B%7D,'cvml','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/35142895/attachment-0001.html>


More information about the Openid-specs-heart mailing list