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

[Moehrke, John (GE Healthcare)]

Hi Eve,

 

1.       This  would simply be an ‘authorization’ that the patient would have needed to record prior to her death. It could have clauses of ‘upon-death’, but that clause would need to be understood and actionable. How would the UMA server learn of death? Some systems today are based on absence of life. Meaning active use by the Patient tells the UMA service that the patient is alive. Learning of death is not something that is well understood today.

2.       FHIR is a data-model and an interaction-model; it is not a definition of a system. There are ways that a FHIR service could be told to pseudonymize the data, I prefer an access control (authorization) method. 

a.       The “Privacy on FHIR” work that the VHA did, did show infrastructure that could be told to de-identify with a specific algorithm. Thus there are obligations embedded in the authorization given to access that indicate what modification would be needed to the data. 

b.      I addressed this in June http://healthcaresecprivacy.blogspot.com/2015/06/fhir-does-not-need-deidentifytrue.html When someone asked for a deidentify query parameter.

c.       I would be remised in my duty if I didn’t point out that de-identification is simply a method used to lower the risk of identification/re-identification. And as a method that reduces risk, risk is never brought to zero. The algorithm used for any specific use-case is specific to that use-case. De-identification algorithms are tuned to the intended use, while lowering the risk as much  as possible while still satisfying the intended use. The only generic de-identification algorithm that works for all use-cases is the one that passes zero data, thus resulting in the null-set.

 

John

 

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Eve Maler
Sent: Monday, February 01, 2016 3:06 PM
To: openid-specs-heart at lists.openid.net
Subject: [Openid-specs-heart] A few comments on Alice Consents to Clinical Research [UMA]

 

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://urldefense.proofpoint.com/v2/url?u=https-3A__www.forgerock.com&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=GiKCNl6aNE6hJZJAYFSxk2w2sJEqoxY469CZ56Wr5ao&s=zlOSUbG4ybuA5f8AdTdHRWuSxB80Dd6QOIWZB4korE8&e=>  with UMA support <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.forgerock.com_platform_user-2Dmanaged-2Daccess_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=GiKCNl6aNE6hJZJAYFSxk2w2sJEqoxY469CZ56Wr5ao&s=-fLr-RuqjcWQtP_CwI3H7OFALdEPyB3XLRrYgpOSNOA&e=>  and an OpenUMA community <https://urldefense.proofpoint.com/v2/url?u=https-3A__forgerock.org_openuma_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=GiKCNl6aNE6hJZJAYFSxk2w2sJEqoxY469CZ56Wr5ao&s=4VJdX6mqTfHXviqqxnx4wnguF1CQv71oaqzsTG_6eRA&e=> !

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160201/5b36cb61/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6966 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160201/5b36cb61/attachment.p7s>