[Openid-specs-heart] A few comments on Alice Consents to Clinical Research [UMA]

Eve Maler eve.maler at forgerock.com
Mon Feb 1 21:43:38 UTC 2016


A few more comments: I believe the party-to-entity mappings need some
tweaking (and more explicitness), which will have some impact on the flows
and swimlanes. We have the following parties:

   - Alice
   - Son
   - A variety of EHRs
   - PHR
   - An operator of an authorization service
   - CDRN
   - Clinical researcher
   - IRB
   - An operator of a reidentification engine

Here's my best guess at mappings to UMA roles; note that these come out
differently, and are incomplete:

   - Alice: RO (same)
   - Son: RqP (new; will need new thought, as an RqP does not literally
   "act as" Alice in UMA, even if he is her "proxy", but is given delegated
   access)
   - A variety of EHRs: RS's as clinical data sources to Alice's PHR and to
   the CDRN, and client to Alice's PHR
   - PHR: possibly an RS as a consumer data source to Alice's EHR, and
   client to Alice's EHRs and to the CDRN
   - An operator of an authorization service: AS
   - CDRN: RqP? (is that what you meant by RP? could be RqP/client for our
   purposes, assuming a specialty client)
   - Clinical researcher: receipient of data from the CDRN out of band of
   UMA
   - IRB: out of band of UMA, I think
   - An operator of a reidentification engine: not sure if this wants to be
   in band of UMA -- it might be but we need to think about it

And here are some tentative mappings to a "legal layer" that seems like the
elephant in this room:

   - Alice: data subject that's a party to a data sharing agreement
   - IRB: committee that's another key party
   - Clinical researcher: third party that has a separate agreement with
   the IRB (researcher and Alice don't know about each other)




*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
New ForgeRock Identity Platform <https://www.forgerock.com> with UMA support
<https://www.forgerock.com/platform/user-managed-access/> and an OpenUMA
community <https://forgerock.org/openuma/>!

On Mon, Feb 1, 2016 at 1:06 PM, Eve Maler <eve.maler at forgerock.com> wrote:

> Apologies for the delay in sending these! I'm commenting just on the
> problem statement for now, and really just sending these additional
> problems/issues for consideration just for posterity since today's meeting
> has begun already.
>
>    - Access to data controlled by a resource owner after she has died: We
>    need to consider "digital death" scenarios. Should we consider whether it's
>    in scope to reassign a resource's resource owner or something?
>    - Capability of the health API in question to enable pseudonymity of
>    release data. Does/should FHIR handle this?
>    - Control over the purpose of use by the CDRN.
>    - At "BL" if not "T" control over consent of the CDRN-to-research
>    transfer of data. (Is this out of scope?)
>
> I'd love to see the first diagram moved to the Problem Statement section,
> since it's such a good summary, and a key supplied for the arrow colors.
>
> Thanks!
>
>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> New ForgeRock Identity Platform <https://www.forgerock.com> with UMA
> support <https://www.forgerock.com/platform/user-managed-access/> and an OpenUMA
> community <https://forgerock.org/openuma/>!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160201/9237e2ff/attachment.html>


More information about the Openid-specs-heart mailing list