Notice of Proposed Rulemaking (NRPM) Comments Privacy and Security Workgroup Deven McGraw, Chair Stanley Crosley, Co-chair May 18, 2015

Agenda 1.Meaningful Use Stage 3 NPRM – Privacy and Security Issues Related to Increasing Patient Access to Data through either VDT or APIs 2.Return to Health Big Data 1

Privacy and security issues related to increasing patient access to data Risks/Provider Responsibility: – Heightened security risks from increasing numbers of APIs connecting to EHRs. – Vendors’ unclear or incorrect understanding and implementation of privacy and security legal requirements. – Vendors’ inadequate or incorrect implementation of entity’s privacy and security policies. 2 Risks/Patient Responsibility: – Use of app/device with weak security controls. – Use of app/device without privacy policy, or with unclear policy, or with policy that shares data liberally with third parties or allows broad uses.

Summary of Discussion The Workgroup supports the proposal to increase the opportunities for patient access to information through the use of VDT technologies as well as open APIs. However, the Workgroup has concerns about potential privacy and security risks associated with increasing patient access to health information electronically. The Workgroup recommends a mixture of timely, meaningful guidance for consumers, health care providers, and vendors, as well as a “certification” effort that facilitates differentiation of mobile tools that meet stakeholder needs with respect to privacy, security and usability. 3

1.ONC is already working with FTC and OCR to develop mobile health best practice guidance for developers which will eventually promote protection of user data. We urge the agencies to work quickly to widely disseminate this guidance so it can be useful for Stages 2 and 3 of MU. Such guidance should include: – Guidance for application developers on best practices for protecting privacy and security of information collected by the app and connecting with EHRs covered by HIPAA. 2.Additionally, we recommend development of guidance for patients/consumers and providers. Guidance should include: – Checklists for consumers on what to look for in a privacy/data use policy; – Mechanisms for consumers to compare privacy policies across apps (similar to ONC's model PHR notice)* 4 Recommendations * Personal Health Record (PHR) Model Privacy Notice. record-phr-model-privacy-noticehttp:// record-phr-model-privacy-notice

3.ONC and OCR should issue guidance addressing the intersection between the MU patient engagement objectives, the certification requirements, and HIPAA’s patient access rights. Such guidance also is needed to help providers in Stages 2 and 3 of MU. Issues include: – how to do a security risk assessment on patient app/device connections (such as through the API) and the extent to which a provider may reject a patient’s request for electronic access due to a perceived security risk for the provider; – the extent to which a provider may reject a patient’s request for electronic access in the absence of a security risk; – the ability of provider’s to charge fees for meaningful use access. 5 Recommendations (cont.)

3.The Health IT Policy Committee previously issued recommendations urging ONC and CMS to provide specific guidance to health care providers participating in MU and vendors of CEHRT to help them manage the risks of “view and download.’’* (see back-up slides) This guidance should be updated to also address risks of transmit and issued in time to assist providers (and CEHRT vendors) in responsibly making VDT and APIs available to patients as part of MU. Such guidance should address; –When liability for data shifts from provider to patient, and the extent to which patients are aware when they take responsibility for protecting data. –Best practices for counseling patients on assessing and managing privacy and security risks. –Responsibilities of vendors to include the CEHRT security safeguards in VDT and API modules. –Technical approaches vendors may take to further protect patients and providers (for example, ‘just in time’ notices before download and transmit that should be able to be turned off by the patient after the first notice and non-caching of data). –ONC also should act on prior recommendations on for guidance on identity proofing and authentication of patients, family members, friends and personal representatives. * 8/16/2011 HITPC Transmittal Letter. 6

4.Timely guidance is needed – but is not enough. We call for further exploration of a multistakeholder (including industry and patients) developed, voluntary certification program for patient-facing health apps. –The effort should address both privacy and security protections, as well as usability for consumers/patients. –The effort should leverage the guidance developed by federal government entities (see above). –Although the effort is voluntary, the FTC – under its existing FTCA authority, can enforce voluntary best practices for those who adopt. –The Consumer Empowerment Task Force (with assistance from the P&S Workgroup) should continue work to flesh out the details on this certification program, considering such issues as: –Whether it should include testing (similar to the CEHRT program). –What should be the role of ONC and other federal entities –Costs and potential impact on innovation 7 Recommendations (cont.)

PSWG Big Data Work plan 8 MeetingsTask  May 18, 2015 Recap: Presentation to the HITPC Review draft big data workplan Review draft big data report June 2, 2015 Begin reviewing draft strawman recommendations June 22, 2015 Continue reviewing strawman recommendations Finalize recommendations HITPC Meeting July 14, 2015 Goal: Present Health Big Data Findings

Big Data Recommendations 9 Submit recommendations to HITPC on July 14, 2015 Draft Table of Contents I.Executive Summary (Section 1) II.Background (Section 2) III.Scope (Section 3) IV.Expert Testimony (Section 4) V.Detailed Problem Statements (Section 5) VI.Solutions and Recommendations (Section 6) VII.Bibliography (Section 7)

Section V – Summary of the Problem Statements 10 § V. Problem Statement 1: Discriminatory Practices Describes the challenges of ensuring responsible use of data and the increasing risk of potential harms (e.g., discriminating against housing and employment, harms to dignity and harms to trust). Also it describes the issues in the lack of algorithmic transparency in how algorithms are used to make conclusions about individuals. § V. Problem Statement 2: Different Domains of Regulation (HIPAA vs. non-HIPAA) Yields Contradictions and Unpredictability Describes the challenges of having the two regulatory domains with their numerous requirements. Stakeholders are confused about what is required and what is not. Also it describes the challenges of having the limited HIPAA applicability and a growing number of NCEs which are collecting and using health-related data that are not required to comply with the HIPAA requirements. The issues of lack of education by individuals around how their data are used, as well as lack of control in accessing, using and sharing data are also described.

Section V – Summary of the Problem Statements 11 § V. Problem Statement 3: De-Identification and Re- Identification Describes the challenges of not having standards around de- identification methodologies. Also, describes the potential risk of re-identification while no enforcement exists to minimize/eliminate privacy risks. § V. Problem Statement 4: Security Threats and Gaps Describes the challenges of the inadequate security mechanisms in place within technology and the environment. Also, HIPAA is limited and NCEs are not required to meet the HIPAA security requirements.

Section VI – Draft Solutions and Recommendations 12 § VI. Solutions for Discriminatory Practices Call on effort that explores the following: Perform analysis of existing protections to identify gaps in law and regulation; identify areas for further inquiry; suggest further research to determine whether applicable legal models exist. Define harmful uses and identify controls on appropriate uses of health information. Identify approaches to dis-incentivize/punish malevolent behavior and incent benevolent uses of data. Improve trust through algorithmic transparency; disclose any use of open source algorithms; if an algorithm is proprietary, disclose a summary that identifies the creator, purpose, and general methodology.

Section VI – Draft Solutions and Recommendations 13 § VI. Solutions for Rebalancing Privacy Laws Rebalance laws in the following ways: – Congressional action: FIPPs-based protections for data outside of HIPAA. – Fix research rules for HIPAA and federally-funded research to make them more risk-based and do not create disincentives to research uses of data. – Improve patient access to data (both within HIPAA and as part of any legislation covering the non-HIPAA space).

Section VI – Draft Solutions and Recommendations 14 § VI. Solutions for Transparency Aim for greater transparency regarding actual uses of data for both identifiable and de-identified data. Update HIPAA and make part of comprehensive protections introduced for the non-HIPAA space. Develop and disseminate education to consumers about how data is used.

Section VI – Draft Solutions and Recommendations 15 § VI. Solutions for De-Identification and Re-Identification Risk Develop federally-approved standards for expert determination method for de-identification. Develop certification program to credential experts. Recommend change in law to prohibit re-identification or partial re-identification without objective oversight. ONC and OCR provide guidance on the following: Require re-assessment of re-identification risk upon certain events: e.g., data combined, expired, or other change in circumstances. Consider the use of Safe Harbor for low risk re-identification. Utilize contractual commitments to achieve greater accountability.

Section VI – Draft Solutions and Recommendations 16 § VI. Solutions for Security Threats Re-endorse prior Tiger Team recommendations* – Security policy for entities collecting, storing and sharing electronic health information needs to be responsive to innovation and changes in the marketplace. – Security policy needs to be flexible and scalable. – Providers need education and guidance on how to comply with security policy requirements. – HHS should have a consistent and dynamic process for updating security policies and rapid dissemination of new rules and guidance to all affected. Call on Congress for comprehensive legislation that includes security requirements. * 12/14/2011 HITPC Transmittal Letter.

17

Backup Slides 18

19 Offered flexibility of “best practices” for providers instead of a certification requirement or a “standard” Recommended that ONC share the guidance through REC and the entities certifying EHR technology Best Practices for Providers: Providers participating in the MU program should offer patients clear and simple guidance regarding use of the view and download in functionality in Stage 2. With respect to the “view” functionality, such guidance should address the potential risks of viewing information on a public computer, or viewing sensitive information on a screen that may be visible to others, or failing to properly log out after viewing. 8/16/2011 HITPC Transmittal Letter. Previous Recommendations on View and Download (Source: 8/16/2011 HITPC Transmittal Letter)

With respect to the “download” functionality, such guidance should be offered at the time the patient indicates a desire to download electronic health information and, at a minimum, address the following three items: 1.Remind patients that they will be in control of the copy of their medical information that they have downloaded and should take steps to protect this information in the same way that they protect other types of sensitive information. 2.Include a link or links to resources with more information on such topics as the download process and how the patient can best protect information after download. 3.Obtain independent confirmation that the patient wants to complete the download transaction or transactions. 20 Previous Recommendations on View and Download (Source: 8/16/2011 HITPC Transmittal Letter)

Providers should utilize techniques, if appropriate, that avoid or minimize the need for patients to receive repeat notices of the guidance on view and/or download risks. Providers should request vendors and software developers to configure the view and download functionality in a way that no cache copies are retained after the view session is terminated. Providers should request that their view and download functionality include the capability to automatically terminate the session after a period of inactivity. 21 Previous Recommendations on View and Download (Source: 8/16/2011 HITPC Transmittal Letter)

ONC should also provide the above guidance to vendors and software developers, such as through entities conducting EHR certification. Providers can review the Markle Foundation policy brief, and the guidance provided to patients as part of the MyHealtheVet Blue Button and Medicare Blue Button, for examples of guidance provided to patients using view and download capabilities. 22