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

Tue Jul 19 12:49:34 UTC 2016

I tried to figure out what ROI is... Clearly not classic use of ROI...
Right?

42cfr is an unusual case globally. Hence why it is troubling. It is a
dataset defined by the fact that the USA government funds a special case
clinic for some sensitive health topics, AND that the patient participated
in that funded project, AND the data in the set is the result.  So the
patient isn't special. The topics are not special. The data is not special.
It is the confluence that makes them special.   Yes I know I over
simplified and over normalized.

An important part is that those funded facilities Know what data was
created under this rule, and what data they have that wasn't. That is the
distinguishing characteristics. They could have exact same data with some
in and some out.

We use this one because in the USA it is the only case we get specifics
that look like Privacy and are Federal rather than State based.

Look too long at this and your eyes will permanently cross.

John

On Jul 19, 2016 6:25 AM, "Sarah Squire" <sarah at engageidentity.com> wrote:

> I definitely agree on auditing. Can you elaborate a little on what you're
> thinking in terms of defining a resource set? I imagine that the
> "clipboard" resource set would vary quite a bit based on the provider and
> their specialty. Are you suggesting that we attempt to define a universal
> set of fields that everyone would need as a baseline? Or are you thinking
> that we should just acknowledge the existence of something called a
> clipboard resource set, and let implementors decide for themselves what
> that means?
>
> I agree that RPT is essentially an authorization for release.
>
> Sarah
>
> Sarah Squire
> Engage Identity
> http://engageidentity.com
>
> On Tue, Jul 19, 2016 at 1:10 PM, Debbie Bucci <debbucci at gmail.com> wrote:
>
>> Well... when thinking about the virtual clipboard vs real world .. I am
>> usually presented with at least 3 or 4 documents ... the laundry list info
>> insurance meds allergies etc. Consent for treatment, Privacy Notice and if
>> referred with no info in hand the release of information.
>>
>> Seems to me that rpt is essentially an authorization for release.
>>
>> Adrian asked that we consider roi as part of the discussion....I think he
>> may be right.
>>
>> Eves doc was broad and I thought the next step was to drill down to
>> soecifics.  If we have agreed a virtual clipboard resource set makes sense
>> that needs to be added.
>>
>> Specifically from the ROI - John Moerke mentioned date range of treatment
>> - that's one and this form opts in  sensitive info.... so I think ... the
>> CFR 42 part 2 stuff ( +genomics) may need a specific scope for
>> authorization to release.
>>
>> Auditing needs to peripherally be considered as well imo
>> On Jul 19, 2016 6:56 AM, "Sarah Squire" <sarah at engageidentity.com> wrote:
>>
>>> Hi all,
>>>
>>> This is the use case that Eve has been hashing out on the call for a few
>>> weeks now:
>>> https://bitbucket.org/openid/heart/wiki/Alice_Shares_with_Physicians_and_Others_UMA_FHIR
>>>
>>> Is there anything specifically added by the NYP form that has not
>>> already been covered?
>>>
>>> Sarah
>>>
>>> Sarah Squire
>>> Engage Identity
>>> http://engageidentity.com
>>>
>>> On Tue, Jul 19, 2016 at 5:43 AM, Adrian Gropper <agropper at healthurl.com>
>>> wrote:
>>>
>>>> Debbie,
>>>>
>>>> In case it's not on the HEART servers, I've put a copy of the NYP
>>>> Authorization Form here:
>>>> https://dl.dropboxusercontent.com/u/8909568/NYP%20authorization.pdf
>>>>
>>>> Mapping the NYP Authorization Form to actual UMA protocol is way above
>>>> my pay grade. Here's as far as I get (inline):
>>>>
>>>> In the case of Alice authorizing  Dr. Bob:
>>>>
>>>>>
>>>>>
>>>>>
>>>>>    - Alice is the Resource Owner *[Yes. Notice that we have to handle
>>>>>    the case where Alice has a Representative sign for her as at the bottom of
>>>>>    the form]*
>>>>>
>>>>>
>>>>>    - The requested resource set  - is the protected resource. *[Someone
>>>>>    else needs to propose the mapping to standards]*
>>>>>    - The resource set would need to have date range.
>>>>>       - Form indicates that release of sensitive information is
>>>>>       explicitly OPT-IN so a confidentiality code of V (very sensitive) would not
>>>>>       release HIV-AIDS/Mental Health/Genetics/Substance Abuse unless explicitly
>>>>>       asked for (as a scope?).
>>>>>    - Can the Authorization server sign the RPT(ROI) on behalf of
>>>>>    Alice?* [Yes. That's the whole point of UMA and HEART as far as I
>>>>>    can tell.]*
>>>>>    - Probably good hygiene to recommend that claims re: Bob's medical
>>>>>    affiliation be recorded as part of the audit or consent receipt if unable
>>>>>    to include as part of RPT process. *[Maybe but it seems
>>>>>    peripheral.]*
>>>>>
>>>>> It's important to note that this form is labeled by NYP as an
>>>> "authorization" and represents UMA Phase 2 where Dr. Bob is on the scene.
>>>> Whoever proposes a mapping to standards needs to also deal with UMA Phase 1
>>>> where Alice or her representative tells NYP the address of her UMA
>>>> Authorization Server. This happens before Bob is on the scene and is what I
>>>> would call "consent".
>>>>
>>>> For the purpose of HEART, could we call UMA Phase 1 consent and UMA
>>>> Phase 2 authorization?
>>>>
>>>> Adrian
>>>>
>>>>
>>>> _______________________________________________
>>>> Openid-specs-heart mailing list
>>>> Openid-specs-heart at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>>>
>>>>
>>>
>
> _______________________________________________
> 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/20160719/f43f2ca8/attachment.html>