<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Adrian,</div>
<div><br>
</div>
<div>Thank you for the opportunity to weigh in. I think some of the nomenclature may be creating some confusion. As Sarah noted, NIST has put out three privacy engineering objectives for consideration. We’ll be putting out a refined set later this year for
more comment. The privacy engineering objectives function as general system properties. That is, they are useful in thinking about the types of properties you want your system to have in order to enable the kinds of privacy protections you want your system
to manifest. I think what you have created are specific privacy-based requirements for HEART. They look as if they are derived from the Fair Information Practice Principles, in part. I’m not sure if you might have drawn on other sources as well.</div>
<div><br>
</div>
<div>Hopefully, I’ve been able to clarify some of the distinctions between principles, objectives and requirements. Please let me know if there are other contributions I can make.</div>
<div><br>
</div>
<div>Naomi</div>
<div><br>
</div>
<div>
<div>
<div>— </div>
<div>Naomi Lefkovitz</div>
<div>Senior Privacy Policy Advisor</div>
<div>National Institute of Standards and Technology</div>
<div>U.S. Department of Commerce</div>
<div>301-975-2924</div>
<div>naomi.lefkovitz@nist.gov</div>
<div><br>
</div>
</div>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Sarah Squire <<a href="mailto:sarah@engageidentity.com">sarah@engageidentity.com</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, May 5, 2015 at 1:37 PM<br>
<span style="font-weight:bold">To: </span>Adrian Gropper <<a href="mailto:agropper@healthurl.com">agropper@healthurl.com</a>><br>
<span style="font-weight:bold">Cc: </span>"Moehrke, John (GE Healthcare)" <<a href="mailto:John.Moehrke@med.ge.com">John.Moehrke@med.ge.com</a>>, Microsoft Office User <<a href="mailto:naomi.lefkovitz@nist.gov">naomi.lefkovitz@nist.gov</a>>, "<a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a>"
<<a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a>>, Mike Garcia <<a href="mailto:michael.garcia@nist.gov">michael.garcia@nist.gov</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Openid-specs-heart] Taking Privacy engineering to HEART<br>
</div>
<div><br>
</div>
<div>
<div>
<div dir="ltr">The NIST privacy engineering objectives, as outlined on slide 8 of this deck:
<div><a href="http://csrc.nist.gov/projects/privacy_engineering/nist_privacy_engr_objectives_risk_model_discussion_deck.pdf">http://csrc.nist.gov/projects/privacy_engineering/nist_privacy_engr_objectives_risk_model_discussion_deck.pdf</a> </div>
<div>are predictability, manageability, and confidentiality. Those three objectives are exactly the point of the work that has already been done, so I think we are firmly in line with the work of the NIST privacy engineering group already.</div>
<div><br>
</div>
<div>Adrian, I don't see any reference to the eight principles you have contextualized here. However, your outline of them provides value, and they are certainly within the spirit of the HEART project. I don't have enough familiarity with the format of these
profiles to say whether or how they should actually be codified. As far as your overarching concern, I don't think that anyone here would disagree that privacy policy decisions should not be hard-coded into the profiles at any layer.</div>
<div><br>
</div>
<div>Sarah</div>
<div><br>
</div>
<div>Sarah Squire</div>
<div>Engage Identity</div>
<div><br>
</div>
<div>PS Hi! I'm new here. I've met a few of you at IIW and elsewhere. Justin gushed enough about the great work that's being done by this group that I had to join in the fun. I look forward to working with you all.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, May 5, 2015 at 5:51 AM, Adrian Gropper <span dir="ltr">
<<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
</font></span>
<div><span class="HOEnZb"><font color="#888888">Adrian</font></span>
<div>
<div class="h5"><br>
<br>
On Tuesday, May 5, 2015, Moehrke, John (GE Healthcare) <<a href="mailto:John.Moehrke@med.ge.com" target="_blank">John.Moehrke@med.ge.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
NIST is improving but are not as complete as other standards. See my article. <a href="http://healthcaresecprivacy.blogspot.com/2015/04/privacy-principles.html?m=1" target="_blank">
http://healthcaresecprivacy.blogspot.com/2015/04/privacy-principles.html?m=1</a><br>
<br>
Privacy by design is great when doing design. But it assumes you are doing all layers of design.<br>
<br>
John<br>
<br>
Sent from my iPhone<br>
<br>
On May 4, 2015, at 11:15 PM, Debbie Bucci <<a>debbucci@gmail.com</a><mailto:<a>debbucci@gmail.com</a>>> wrote:<br>
<br>
Adrian<br>
<br>
Your description sounds like a redux mix of FIPP, Privacy by Design sprinkled with HIPPA.<br>
<br>
I see reference to the workshop and objectives. <a href="http://csrc.nist.gov/projects/privacy_engineering/index.html" target="_blank">
http://csrc.nist.gov/projects/privacy_engineering/index.html</a><br>
<br>
Do you have a link reference that lays out the principles you listed?<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On Mon, May 4, 2015 at 9:55 PM, Adrian Gropper <<a>agropper@healthurl.com</a><mailto:<a>agropper@healthurl.com</a>>> wrote:<br>
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.<br>
<br>
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.<br>
<br>
0 - Open Source - HEART MUST allow for implementation by open source Clients and open source authorization servers as built by the Subject.<br>
<br>
1 - Anonymity - HEART MUST allow for anonymous access when policy allows.<br>
<br>
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.<br>
<br>
3 - Transparency - HEART MUST allow for the Subject to get an on-line Accounting for Disclosures while preserving a pairwise pseudonymous identity.<br>
<br>
4 - Notice - HEART MUST allow for notice to Subjects that are willing to share a voluntary and possibly insecure notification address.<br>
<br>
5 - Data Minimization - HEART MUST not impose minimum information disclosure requirements by design.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I've copied two NIST folks involved in privacy engineering and the NSTIC principles in order to make sure I'm interpreting these correctly.<br>
<br>
Adrian<br>
<br>
--<br>
Adrian Gropper MD<br>
Ensure Health Information Privacy. Support Patient Privacy Rights.<br>
<a href="http://patientprivacyrights.org/donate-2/" target="_blank">http://patientprivacyrights.org/donate-2/</a><br>
<br>
<br>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a>Openid-specs-heart@lists.openid.net</a><mailto:<a>Openid-specs-heart@lists.openid.net</a>><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br>
<br>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a>Openid-specs-heart@lists.openid.net</a><mailto:<a>Openid-specs-heart@lists.openid.net</a>><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
</blockquote>
</div>
</div>
</div>
<div class="HOEnZb">
<div class="h5"><br>
<br>
-- <br>
<div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><font size="1"><br>
<font size="2">Ensure Health Information Privacy. Support Patient Privacy Rights.<br>
</font></font><span style="font-size:11pt"><font size="1"></font></span><font size="2"><a href="http://patientprivacyrights.org/donate-2/" target="_blank"><font color="blue"><u>http://patientprivacyrights.org/donate-2/</u></font></a><font color="blue"><u>
</u></font></font><span style="font-size:11pt"></span><span style="font-size:11pt"></span><span style="font-size:11pt"><font size="1"><br>
</font>
<div></div>
</span><br>
</div>
<br>
</div>
</div>
<br>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</span>
</body>
</html>