Difference between revisions of "HL7 SPIA Cookbook Project"

Revision as of 17:10, 1 February 2017

This document defines a Standards Privacy Assessment (SPA) process for Specifications Under Review (SURs) in HL7. The SPA process provides guidelines for creating a Privacy Considerations section, as well as a template of this section, within HL7 SURs.

The Need for a Standards Privacy Assessment

Often during the development of a SUR, privacy concerns will be brought up. These privacy concerns often can’t be addressed in the design of the SUR; however, they likely can be addressed in the software implementing the SUR, the operational environment deploying that software, or the policies in which the SUR is used. Thus, it is helpful to expose “Privacy Considerations.” Privacy considerations are residual (un-addressed) privacy risks for the next step to address or pass through.

Scope

SURs in HL7 may have privacy impacts, in which case they will need to be addressed to protect the Personally Identifiable Information (PII) of the consumers who trust in this technology. This Standards Privacy Assessment (SPA) provides editors of HL7 SURs with guidance on:

Why a Privacy Considerations section is needed in HL7 SURs,
When a SPA process should be used for a HL7 SUR,
How to conduct a SPA analysis on a HL7 SUR, and
What findings should be included in the Privacy Considerations section of a HL7 SUR.

The privacy impact of a SUR is directly related to either PII or technical mechanisms for identifying information that can be linked to the PII principal associated with that information.

A SPA is a methodology assessing the possible privacy impact(s) of a SUR. It takes into account applicable privacy principles and associated privacy safeguarding requirements in order to assess the potential threats arising from the SUR that require mitigation by introducing privacy safeguards or controls. In addition, the SPA process is intended to help create information that should be used in analyzing the potential harm towards an individual that could be caused by the technology defined by the SUR.

This SPA is meant to help the thought process of privacy analysis; it does not provide specific directions for how to write a Privacy Considerations section.

Guidance to Editors on When to Apply SPA

In order to determine whether to apply the SPA process, three questions need to be answered concerning the SUR:

Will the SUR involve technology that will process PII, or will it involve technology that could link information to an identifiable individual?
If the SUR will not process PII or involve technology that could link information to an identifiable individual, will it generate PII?
If the SUR will not generate PII, will it involve technology that will be used in a network device by an individual?

If the answer to any of these questions is affirmative, then the SPA process should be applied to the SUR.

In the event that a SPA process is not considered warranted, the editor should clearly articulate this using text such as the following:

“This specification does not define technology that will process Personally Identifiable Information (PII), nor will it create any link to PII. Furthermore, the specification does not define technology that will be deployed in a network device and used by an individual.”

SPA Process

See "Working Space" below to access the repository of all SPA-related resources and the latest version of the SPA document. Section 3 of this document describes each step of the SPA Process.

Privacy Considerations

Guidelines for creating a Privacy Considerations section, as well as a template of this section, are also available in the SPA document. See "Working Space" below to access the latest version of the SPA document. Section 4 of this document provides guidelines for creating the Privacy Considerations section and a template of how a Privacy Considerations section might look in an HL7 SUR.

@@ Line 1: / Line 1: @@
 [[CBCC|Back to CBCC Wiki: Meetings]]
-Healthcare today has some of the most diverse needs with regard to sharing of patient data and the need to protect and preserve the privacy of the data as it moves among systems. Increasingly, healthcare organizations and technology vendors are performing assessments (privacy impact assessments, threat risk assessments, business impact assessments, etc.) to ensure installed healthcare technology will have a positive impact on healthcare delivery. These assessments are even mandated for healthcare delivery organizations in some countries. Unfortunately, key decision makers often have difficulty understanding the relevance of the privacy impacts identified, and often overlook them when writing standards.
+This document defines a Standards Privacy Assessment (SPA) process for Specifications Under Review (SURs) in HL7. The SPA process provides guidelines for creating a Privacy Considerations section, as well as a template of this section, within HL7 SURs.
-== The Goal ==
+== The Need for a Standards Privacy Assessment ==
-This Standards Privacy Impact Assessment (SPIA) Cookbook is intended to enable HL7 standards developers to publish standards that have taken privacy considerations and impacts into account. This guide introduces a process to facilitate completing a privacy impact assessment for a specific standard. Using this process will facilitate the identification of gaps in a standard’s baseline privacy. This will lead to standards that include privacy as part of their base, reducing the need to “bolt” privacy on later. As a result, the HL7 standards will better protect and preserve patient privacy, which in turn will lead to improved patient outcomes.
+Often during the development of a SUR, privacy concerns will be brought up. These privacy concerns often can’t be addressed in the design of the SUR; however, they likely can be addressed in the software implementing the SUR, the operational environment deploying that software, or the policies in which the SUR is used. Thus, it is helpful to expose “Privacy Considerations.” Privacy considerations are residual (un-addressed) privacy risks for the next step to address or pass through.
 == Scope ==
-This SPIA Cookbook guides HL7 standards developers through a 10-step process that helps ensure they consider the privacy impacts that the implementation of their standard will have on individuals. It encourages all HL7 standards developers to add a “Privacy Considerations” section to their standard, a section which will address if actions involving PII are in scope of the standard. If so, HL7 standards developers are encouraged to recommend that implementers reference jurisdictional laws, regulations, and policies when performing actions involving PII.
+SURs in HL7 may have privacy impacts, in which case they will need to be addressed to protect the Personally Identifiable Information (PII) of the consumers who trust in this technology. This Standards Privacy Assessment (SPA) provides editors of HL7 SURs with guidance on:
-Specific instructions or guidelines for implementing standards involving PII are out of scope of this SPIA Cookbook. It is up to individual implementers to determine how they will handle and protect PII.
+* Why a Privacy Considerations section is needed in HL7 SURs,
+* When a SPA process should be used for a HL7 SUR,
+* How to conduct a SPA analysis on a HL7 SUR, and
+* What findings should be included in the Privacy Considerations section of a HL7 SUR.
-== The Need for a Privacy Impact Assessment ==
+The privacy impact of a SUR is directly related to either PII or technical mechanisms for identifying information that can be linked to the PII principal associated with that information.
-A '''privacy impact assessment''' is the “overall process of risk identification, risk analysis and risk evaluation with regard to the processing of personally identifiable information (PII).” (Source: ISO/IEC 29100 ''Information technology — Security techniques — Privacy framework'')
+A SPA is a methodology assessing the possible privacy impact(s) of a SUR. It takes into account applicable privacy principles and associated privacy safeguarding requirements in order to assess the potential threats arising from the SUR that require mitigation by introducing privacy safeguards or controls. In addition, the SPA process is intended to help create information that should be used in analyzing the potential harm towards an individual that could be caused by the technology defined by the SUR.
-Organizations strive to protect PII for many reasons, such as safeguarding an individual’s privacy, meeting legal and regulatory requirements, and increasing consumer trust. To determine the privacy implications of their systems which process PII, organizations regularly conduct a privacy risk management process. A privacy impact assessment is a common deliverable of this process. (Source: ISO/IEC 29100)
+This SPA is meant to help the thought process of privacy analysis; it does not provide specific directions for how to write a Privacy Considerations section.
-== Privacy Considerations Section ==
+== Guidance to Editors on When to Apply SPA ==
-See the "Working Space" area on this Wiki page to open the latest SPIA Cookbook draft document. Section 2 of this document provides questions that HL7 standards developers should address and provide responses to in the “Privacy Considerations” section of their standard. Following the questions in the document is a diagram that graphically illustrates the order and flow of questions and possible responses for standards developers as they fill out the Privacy Considerations section.
+In order to determine whether to apply the SPA process, three questions need to be answered concerning the SUR:
-== Privacy Risk Management Approach ==
+# Will the SUR involve technology that will process PII, or will it involve technology that could link information to an identifiable individual?
+# If the SUR will not process PII or involve technology that could link information to an identifiable individual, will it generate PII?
+# If the SUR will not generate PII, will it involve technology that will be used in a network device by an individual?
-For the final part of the Privacy Considerations section, HL7 standards developers are encouraged to write:
+If the answer to any of these questions is affirmative, then the SPA process should be applied to the SUR.
-"We recommend implementers refer to the privacy risk management approach for guidance on how to address and mitigate any privacy risks  associated with the collection, storage, use, processing, disclosure, dissemination, et. al. of PII before implementation of our standard."
+In the event that a SPA process is not considered warranted, the editor should clearly articulate this using text such as the following:
-The privacy risk management approach outlined in Appendix C of the SPIA Cookbook closely follows the “Methodology for Privacy Risk Management” produced by Commission Nationale de l’Informatique et des Libertés (CNIL).
+“'''This specification does not define technology that will process Personally Identifiable Information (PII), nor will it create any link to PII. Furthermore, the specification does not define technology that will be deployed in a network device and used by an individual.'''”
-* [https://www.cnil.fr/sites/default/files/typo/document/CNIL-ManagingPrivacyRisks-Methodology.pdf  CNIL's Methodology for Privacy Risk Management]
-* This methodology has been accepted and incorporated in the “Privacy- and Security-by-Design Methodology Handbook” published by PReparing Industry to Privacy-by-design by supporting its Application in Research (PRIPARE).
-** The PRIPARE Handbook harmonizes and integrates the existing standards, practices and research proposals on privacy engineering.
-** [http://pripareproject.eu/wp-content/uploads/2013/11/PRIPARE-Methodology-Handbook-Final-Feb-24-2016.pdf  PRIPARE Handbook]
-== Working Space ==
+== SPA Process ==
-* [http://gforge.hl7.org./gf/project/cbcc/docman/Privacy%20Impact%20Assessment%20Cookbook/ HL7 GForge folder with resources]
-* [http://gforge.hl7.org/gf/download/docmanfileversion/9287/14436/SPIA%20Cookbook_DRAFT_v0.8.docx Draft SPIA Cookbook document]
-== Mitigation Tools ==
+See "Working Space" below to access the repository of all SPA-related resources and the latest version of the SPA document. Section 3 of this document describes each step of the SPA Process.
-It is up to individual organizations to choose and follow a strategy that best suits their needs. However, HL7 implementers should mitigate risks as often as possible in order to decrease the risk to an acceptable level. Privacy by Design (PbD) principles should be referenced for this purpose.
+== Privacy Considerations ==
-ISO/IEC 29100 describes the following PbD principles:
+Guidelines for creating a Privacy Considerations section, as well as a template of this section, are also available in the SPA document. See "Working Space" below to access the latest version of the SPA document. Section 4 of this document provides guidelines for creating the Privacy Considerations section and a template of how a Privacy Considerations section might look in an HL7 SUR.
-# Consent and choice
-# Purpose legitimacy and specification
-# Collection limitation
-# Data minimization
-# Use, retention and disclosure limitation
-# Accuracy and quality
-# Openness, transparency and notice
-# Individual participation and access
-# Accountability
-# Information security
-# Privacy compliance
-'''Download the [http://standards.iso.org/ittf/PubliclyAvailableStandards/c045123_ISO_IEC_29100_2011.zip ISO/IEC 29100 standard] for guidance on how to meet each of the 11 principles above.'''
+== Working Space ==
-OASIS Privacy by Design Documentation for Software Engineers (PbD-SE) describes PbD principles as well:
+* [http://gforge.hl7.org/gf/project/cbcc/docman/Standards%20Privacy%20Assessment/ HL7 GForge folder with all SPA-related resources]
-# Proactive not Reactive; Preventative not Remedial
+* [http://gforge.hl7.org/gf/download/docmanfileversion/9488/14989/HL7_SPEC_SPA_R1_I1_2016SEP1_post%20ballot%20reconciliation.docx Latest, post-ballot reconciliation version of SPA document]
-# Privacy by Default
-# Privacy Embedded into Design
-# Full Functionality: Positive Sum, not Zero-Sum
-# End-to-End Lifecycle Protection
-# Visibility and Transparency
-# Respect for User Privacy
-'''Browse [https://www.oasis-open.org/committees/documents.php?wg_abbrev=pbd-se the OASIS Privacy by Design document repository] and the [https://www.oasis-open.org/committees/download.php/57290/pbd-se-v1_0-wd08.docx latest PbD-SE working draft specifically] for guidance on how to meet each of the 7 principles above.'''
-In addition, the Information and Privacy Commissioner of Ontario has a vast selection of PbD white papers and other PbD documents available on its website. '''Go [https://www.ipc.on.ca/english/resources/ here] and click on “Discussion Papers.”'''
-Finally, several “best practices” specifications for incorporating PbD principles are available on the Web, including:
-* [https://tools.ietf.org/html/rfc6973 IETF RFC 6973, “Privacy Considerations for Internet Protocols”]
-* [http://www.ietf.org/rfc/rfc3552.txt IETF RFC 3552, “Guidelines for Writing RFC Text on Security Considerations”]
-* [http://www.w3.org/TR/2010/NOTE-dap-privacy-reqs-20100629/ W3C Working Group Note, “Device API Privacy Requirements”]
-* [http://www.w3.org/TR/2012/NOTE-app-privacy-bp-20120703/ W3C Working Group Note, “Web Application Privacy Best Practices”]

Difference between revisions of "HL7 SPIA Cookbook Project"

Revision as of 17:10, 1 February 2017

Contents

The Need for a Standards Privacy Assessment

Scope

Guidance to Editors on When to Apply SPA

SPA Process

Privacy Considerations

Working Space

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

groups

meetings

general

Tools