[Openid-specs-heart] Taking Privacy engineering to HEART

[Adrian Gropper]

The beauty of FHIR/OAuth is indeed that HEART can design all layers of
privacy. It's a unique opportunity. Identity, OpenID Connect, UMA, and
RESTful / OAuth resources are not domain-specific to healthcare. HEART can
enable the health industry and Argonaut to adopt privacy engineering in its
implementation of FHIR by keeping policy out of all layers of the stack.

Adrian

On Tuesday, May 5, 2015, Moehrke, John (GE Healthcare) <
John.Moehrke at med.ge.com> wrote:

> NIST is improving but are not as complete as other standards.  See my
> article.
> http://healthcaresecprivacy.blogspot.com/2015/04/privacy-principles.html?m=1
>
> Privacy by design is great when doing design. But it assumes you are doing
> all layers of design.
>
> John
>
> Sent from my iPhone
>
> On May 4, 2015, at 11:15 PM, Debbie Bucci <debbucci at gmail.com
> <javascript:;><mailto:debbucci at gmail.com <javascript:;>>> wrote:
>
> Adrian
>
> Your description sounds like a redux mix of FIPP, Privacy by Design
> sprinkled with HIPPA.
>
>  I see reference to the workshop and objectives.
> http://csrc.nist.gov/projects/privacy_engineering/index.html
>
> Do you have a link reference that lays out the principles you listed?
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, May 4, 2015 at 9:55 PM, Adrian Gropper <agropper at healthurl.com
> <javascript:;><mailto:agropper at healthurl.com <javascript:;>>> wrote:
> I propose we apply NIST Privacy Engineering principles to the HEART
> profiles. This would mean designing the profiles to allow policy to be
> introduced at the appropriate layer in the protocols and no sooner.
>
> The most important aspects of Privacy Engineering in the HEART context are
> (in rough order of importance) open source, anonymity, pairwise
> pseudonymous identity, transparency, notice, data minimization, persistence
> minimization, and subject-centrality.
>
> 0 - Open Source - HEART MUST allow for implementation by open source
> Clients and open source authorization servers as built by the Subject.
>
> 1 - Anonymity - HEART MUST allow for anonymous access when policy allows.
>
> 2 - Pairwise Pseudonymous Identity - HEART MUST support pairwise
> pseudonymous identity for longitudinal aggregation of data by a single
> Resource Server. For the purpose of the Privacy Engineering exercise, we
> need a definition of "known to the practice" as the in-person
> identification of the Subject without recourse to external verification or
> ID proofing. The requirement for verified identity or other
> policy-dependent attributes such as a discoverable pseudonym are to be
> separate from the core design of HEART profiles.
>
> 3 - Transparency - HEART MUST allow for the Subject to get an on-line
> Accounting for Disclosures while preserving a pairwise pseudonymous
> identity.
>
> 4 - Notice - HEART MUST allow for notice to Subjects that are willing to
> share a voluntary and possibly insecure notification address.
>
> 5 - Data Minimization - HEART MUST not impose minimum information
> disclosure requirements by design.
>
> 6 - Persistence Minimization - HEART SHOULD support automated, limited
> access to data by reference in order to reduce the incentive for Clients to
> persist unnecessary copies of the subject's data.
>
> 7 - Subject Centrality - aka the Multiple Portals Problem - HEART SHOULD
> allow for Subjects to specify their preferred Authorization Server in a
> domain-neutral (across legal, finance, health, education domains) unless
> expressly prohibited by law.
>
> I've copied two NIST folks involved in privacy engineering and the NSTIC
> principles in order to make sure I'm interpreting these correctly.
>
> Adrian
>
> --
> Adrian Gropper MD
> Ensure Health Information Privacy. Support Patient Privacy Rights.
> http://patientprivacyrights.org/donate-2/
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net <javascript:;><mailto:
> Openid-specs-heart at lists.openid.net <javascript:;>>
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net <javascript:;><mailto:
> Openid-specs-heart at lists.openid.net <javascript:;>>
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>


-- 
Adrian Gropper MD
Ensure Health Information Privacy. Support Patient Privacy Rights.
*http://patientprivacyrights.org/donate-2/*
<http://patientprivacyrights.org/donate-2/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150505/9959dac2/attachment.html>