[Openid-specs-heart] Updated Use Case: Patient Authorizes Clinical Research

Glen Marshall [SRS] gfm at securityrs.com
Wed Mar 9 21:10:23 UTC 2016


Thanks, John.  Good response!

The portions of the use case that refer to pseudonymization and re-identification are only there for the narrative’s completeness.  They are marked “[peripheral]” in the text.  That means they are not core to the use case and will not appear in profiles or implementation guides built to support the UMA data flows.

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
www.SecurityRiskSolutions.com<http://www.securityrisksolutions.com/>

From: Moehrke, John (GE Healthcare) [mailto:John.Moehrke at med.ge.com]
Sent: Wednesday, March 9, 2016 15:54
To: Scott Shorter <sshorter at kimbleassociates.com>; Glen Marshall [SRS] <gfm at securityrs.com>
Cc: HEART List (openid-specs-heart at lists.openid.net) <openid-specs-heart at lists.openid.net>
Subject: RE: [Openid-specs-heart] Updated Use Case: Patient Authorizes Clinical Research

Hi Scott,

The NIST IR 8053 is based on ISO 25237; so you have mostly the right concept.

You will also find IHE has written handbooks derived from ISO 25237 that explain how to apply the ‘process’ to a specific ‘intended use-case’ so that you get a specific set of algorithms that you would use for your intended use-case.
    http://www.ihe.net/User_Handbooks/

I am one of the co-editors of the ISO 25237 (and the IHE handbook); The new version of ISO 25237 will be referencing the IHE Handbook.

Glen’s diagram should be clear where the De-Identification happens, and that it needs to be Pseudonymization so that it can be Re-Identified… If that re-identification is needed.

The only de-identification algorithm that brings risk to zero is the one that passes ZERO data. Thus as long as some data passes there is some risk. The De-Identification process is use to design a set of algorithms that reduce the risk while still allowing the intended use-case to succeed. Sometimes this reduction is not sufficient, so the resulting data still needs to be protected. Sometimes it is…

I would be glad to help the team understand further, but I suspect that this is a diversion that is not in the scope of the HEART group.
  blog articles on the topic at http://healthcaresecprivacy.blogspot.com/p/topics.html#DEID

John

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Scott Shorter
Sent: Wednesday, March 09, 2016 12:54 PM
To: Glen Marshall [SRS]
Cc: HEART List (openid-specs-heart at lists.openid.net)
Subject: Re: [Openid-specs-heart] Updated Use Case: Patient Authorizes Clinical Research

Hello Glen,

Looks good, but I am confused about the de-identification and re-identification process.  The diagram shows a “reidentification engine” - what’s the concept of operations for that?  Does the de-identification process include registering with one of these engines to enable re-identification?  Or is the de-identification assumed to be reversible?

Is this explained in the ISO/TS 25237 document referenced in footnote 2?  I’m not familiar with that, I will confess that most of what I know about de-identification I learned from NISTIR 8053 (http://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.8053.pdf<https://urldefense.proofpoint.com/v2/url?u=http-3A__nvlpubs.nist.gov_nistpubs_ir_2015_NIST.IR.8053.pdf&d=CwMGaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=lgQeHAC9BYIMFiJChnZp-GjxEcwB2BNnqEmWtC5aISA&s=vTybC7ZevWRZHQl0AX6iinZDKeFV-5jeQJFeYcP--Gk&e=>).

Thanks,
Scott

On Mar 4, 2016, at 12:12 PM, Glen Marshall [SRS] <gfm at securityrs.com<mailto:gfm at securityrs.com>> wrote:

HEART Team,

An updated draft for the use case is attached.  It reflects our discussions in February, excluding any tangential issues.  I appreciate your collective help in advancing this work.

Thanks,
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<mailto:gfm at securityrs.com>
www.SecurityRiskSolutions.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.securityrisksolutions.com_&d=CwMGaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=lgQeHAC9BYIMFiJChnZp-GjxEcwB2BNnqEmWtC5aISA&s=g35khr8CnAKqYhcQf6SGn5pi-reQCmaUPl7mdnYrm7Y&e=>

<UseCase - Patient Authorizes Clinical Research - DRAFT - GFM 2016-03-04.pdf>_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net<mailto:Openid-specs-heart at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-heart<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=CwMGaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=lgQeHAC9BYIMFiJChnZp-GjxEcwB2BNnqEmWtC5aISA&s=HxCUfNOGH7-RMsxcl-9Cyp-x3JDBlfpCNBU0MYIPeNg&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160309/bf5c4f52/attachment.html>


More information about the Openid-specs-heart mailing list