[Openid-specs-heart] Comments on the UMA+FHIR profile (and one additional profile comment)
Ioana Singureanu
ioana.singureanu at gmail.com
Wed Mar 1 05:43:48 UTC 2017
Indeed...We already have a policy that mandates that we auditing all
"disclosure" events regardless of purpose (aka "accounting for
disclosure"). If an initiator asserts "emergency", "treatment", or
"research"... we have to record who, when, and what information was shared.
Cheers,
Ioana
On Tue, Feb 28, 2017 at 11:08 PM, Eve Maler <eve.maler at forgerock.com> wrote:
> Okay. But it could be accounted for by making it visible in the same
> system the patient uses for the policies they do set. As I say,
> accountability would increase if it's auditable in the same way as
> everything else. I'm familiar with an emergency first-responder system
> (firefighters and the like) put in place by a telco, where they're using
> identity claims that need to be part of a trust framework. The same could
> be used here, with policies set by the AS and agreed to through the Ts & Cs.
>
>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter:
> @xmlgrrl
>
> On Tue, Feb 28, 2017 at 6:42 PM, Ioana Singureanu <
> ioana.singureanu at gmail.com> wrote:
>
>> Hi Eve:
>>
>> Just a clarification: emergency access (aka "break the glass") is not an
>> exception but rather type authorization policy but that that cannot be
>> modulated by patient through a consent. HIEs implement the "break the
>> glass" policy *explicitly *along with other policies.
>> It's not an exception, but just another policy. From an UMA stand-point
>> it's not a very interesting policy because the patient has no input.
>>
>> Kind regards,
>> Ioana
>>
>> On Tue, Feb 28, 2017 at 2:38 PM, Eve Maler <eve.maler at forgerock.com>
>> wrote:
>>
>>> The interesting thing about having the HEART profile(s) cover this use
>>> case is that the sharing of the data goes from an exception basis to an
>>> in-band, auditable, patient-involved (yet still lightweight) basis, where
>>> the other parties know they're responsible for proving (later) that there
>>> was a legitimate reason for the access based on their trust of the
>>> requesting party's claims. Accountability can go way up, and access
>>> involves using the "same technology stack as usual".
>>>
>>> This is as opposed to current practice; a study I saw a few years ago
>>> for a European country showed that ~70% of hospital record access in one
>>> case was exception-based vs. rule-based -- and that's in a
>>> provider-to-provider scenario. I bet no one is surprised.
>>>
>>> Eve (from my iPad)
>>>
>>> On Feb 28, 2017, at 8:05 AM, Ioana Singureanu <
>>> ioana.singureanu at gmail.com> wrote:
>>>
>>> HI Nancy et al;
>>>
>>>
>>> For patient safety, theUMA policy would not be invoked in cases when the
>>> user/initiator asserts the purpose of the request is "emergency" (rather
>>> "treatment" or "research"). For simplicity, we could assume that any
>>> consent or UMA policy will never refer to"emergency treatment" or "ER"
>>> because it simply does not matter in those cases.
>>>
>>> As a use cases, it may be a useful to address "emergency" but from an
>>> information flow it's trivial, the UMA would be disregarded. If the client
>>> is authorized, they will get *all *the data requested even if it's
>>> restricted.
>>>
>>> Cheers,
>>> Ioana Singureanu
>>>
>>>
>>> On Mon, Feb 27, 2017 at 7:36 PM, Nancy Lush <nlush at lgisoftware.com>
>>> wrote:
>>>
>>>> Re: But I also wonder if, in practice, there will be other true
>>>> role-based claims that would supplant the er/btg claim in practice.
>>>>
>>>> Good thought. I had a problem using er for Emergency Responder as I
>>>> always think of the ER as Emergency Room. Granted, they may both need to
>>>> BTG, but the Emergency Room role is typically within a hospital setting and
>>>> the Emergency Responder may be a deputized citizen. I do believe that
>>>> Emergency Responders represent a hole in our interoperability use cases
>>>> that need attention. Will be good to see Glen’s whitepaper and understand
>>>> the issue more holistically.
>>>>
>>>>
>>>>
>>>> Thanks Justin.
>>>>
>>>>
>>>>
>>>> -Nancy
>>>>
>>>>
>>>>
>>>> *From:* Openid-specs-heart [mailto:openid-specs-heart-bou
>>>> nces at lists.openid.net] *On Behalf Of *Eve Maler
>>>> *Sent:* Monday, February 27, 2017 5:28 PM
>>>> *To:* openid-specs-heart at lists.openid.net
>>>> *Subject:* [Openid-specs-heart] Comments on the UMA+FHIR profile (and
>>>> one additional profile comment)
>>>>
>>>>
>>>>
>>>> Great stuff!
>>>>
>>>>
>>>>
>>>> UMA+FHIR profile:
>>>>
>>>> - User-Managed Access should have a hyphen throughout.
>>>> - As you already noted, the "openid-heart-fhir-oauth2" needs to be
>>>> changed.
>>>> - Claim semantics: Make this their own section (keeping the
>>>> positioning at Sec 3 is fine), and make sure to register them in the OIDC
>>>> JWT claims registry. We could have a separate section (what is currently
>>>> the introduction to Sec 3) discussing Claims Presentation, but I'm not sure
>>>> this is warranted. Instead, the intro to discussing claim semantics could
>>>> make clear that claims MAY be pushed or interactively gathered. (We haven't
>>>> yet defined any claim profiles for pushed claims, but we should probably
>>>> consider this: OIDC, I assume?)
>>>> - src claim: I wasn't sure if this would keep the same name, but it
>>>> should probably be "licensing" (or "accreditation") "*authority*"
>>>> (rather than "board") to be a bit more generic.
>>>> - Food for thought: For the same reason that "airplane mode" is an
>>>> awkward name for turning off cell signal reception on your mobile device --
>>>> it's too specific -- maybe the "er" claim should be called "btg" to match
>>>> the scope name. But I also wonder if, in practice, there will be other true
>>>> role-based claims that would supplant the er/btg claim in practice. In
>>>> which case, Sec 4.1 could simply have a SHOULD or MUST around enabling the
>>>> resource owner to audit the specific "btg"-related policies in place along
>>>> with making any access ultimately granted auditable and available to the
>>>> resource owner, etc.
>>>> - In UMA2, we've learned that the RS should document its pattern of
>>>> permission requests ("registrations"), and this may be relevant for
>>>> profiling UMA1 as well. It would help the client know what sort of stuff it
>>>> may be getting in its RPT.
>>>> - in Section 4: s/implementors/implementers/
>>>>
>>>>
>>>>
>>>> UMA profile:
>>>>
>>>> - TTL of the PAT: The advice given is generic, referring to the
>>>> OAuth profile. But the PAT specifically needs to be used in an "offline"
>>>> (asynchronous) way most of the time (on client access attempts) and for
>>>> most use cases (when the requesting party isn't the same as the resource
>>>> owner). Should we say something specific about this? The UMA Implementers'
>>>> Guide does
>>>> <http://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Guide?src=contextnavchildmode#UMAImplementer'sGuide-RO-offlineEnsuringAsynchronousResourceServerAccesstoanAuthorizationServer>
>>>> .
>>>>
>>>>
>>>> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
>>>> Technology
>>>> Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter:
>>>> @xmlgrrl
>>>>
>>>> _______________________________________________
>>>> Openid-specs-heart mailing list
>>>> Openid-specs-heart at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>>>
>>>>
>>>
>>>
>>> --
>>> Ioana Singureanu
>>> Eversolve, LLC
>>> T: 603 548 5640 <(603)%20548-5640>
>>>
>>>
>>
>>
>> --
>> Ioana Singureanu
>> Eversolve, LLC
>> T: 603 548 5640 <(603)%20548-5640>
>>
>
>
--
Ioana Singureanu
Eversolve, LLC
T: 603 548 5640
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20170301/c2739be6/attachment.html>
More information about the Openid-specs-heart
mailing list