1. Notice of Proposed Rulemaking (NPRM) Comments Privacy and Security Workgroup Deven McGraw, chair Stan Crosley, co-chair April 27, 2015

2. Agenda Meaningful Use Stage 3 Notice of Proposed Rulemaking (NPRM) Discussion 1

3. PSWG NPRM Workplan - Detail 2 MeetingsTask April 20, 2015 2:30-4:30pm ET Certification NPRM Data Segmentation for Privacy (DS4P) Pharmacogenomics April 27, 2015 12:00-1:30pm ET MU3 NPRM Objective 1: Protect Patient Health Information Ramifications of increased patient access to data May 1, 2015 10:00-11:30am ET NPRM Finalization Finalize outstanding comments May 12, 2015 HITPC Meeting Present NPRM Comments

4. PSWG MU NPRM Assignments Meaningful Use (MU) Stage 3 NPRM Review proposed Objective 1 (Protect Patient Health Information), pp. 16745 – 16747; § 495.7, pp. 16798 Ramifications of increased patient access to data (Objective 5: Patient Electronic Assess to Health Information), pp. 16752 – 16755; Section 495.7, pp. 16799 3

5. Objective 1: Protect Patient Health Information Proposed objective: Protect ePHI created or maintained by the CEHRT through the implementation of appropriate technical, administrative, and physical safeguards New: adding Administrative safeguards (e.g., risk analysis, risk management, training, etc.) and Physical safeguards (e.g., facility access controls, workstation security) 4

6. Objective 1: Protect Patient Health Information Proposed Risk Analysis Requirements: – Must assess the risks and vulnerabilities to ePHI created or maintained by the CEHRT – Must be conducted or reviewed for each EHR reporting period (a full calendar year) – Include any security updates and deficiencies identified in the risk management process and implemented or corrected by the process Consistent with previous P&S Tiger Team (P&S TT) recommendations 5

7. Alignment with Previous PSTT Recommendations 6 Previous Recommendations*Proposed 2015 NPRM When an entity attests to conducting or reviewing a security risk analysis for CEHRT and MU requirements, such attestation supports compliance with the HIPAA Security Rule Consistent with past P&S TT recommendations. By adding administrative and physical safeguards, CEHRT risk assessments are aligned with the Security Rule Add an accountability measure; identify the individuals responsible for conducting and documenting the risk assessment Not addressed Link attestation to specific MU objectives, rather than present it as a single, stand-alone measure; risk assessment is an ongoing process Not tied to a specific MU objective Emphasize the importance of involving security professionals fully about how EHR system’s functionality is deployed States that it “may be necessary to involve security or health IT support team.” CMS and OCR should provide additional education to the providers References OCR’s Guidance on Risk Analysis Requirement Tool and ONC’s Security Risk Assessment Tool * 10/29/2013 HITPC Transmittal Letter: http://www.healthit.gov/facas/health-it-policy-committee/health-it-policy-committee- recommendations-national-coordinator-health-ithttp://www.healthit.gov/facas/health-it-policy-committee/health-it-policy-committee- recommendations-national-coordinator-health-it

8. Straw Comment for Discussion The Workgroup supports the proposed MU Stage 3 security requirements. By adding administrative and physical safeguards to the current requirements, the CEHRT risk assessments and attestations are now more closely aligned with the compliance requirements of the HIPAA Security Rule 7

9. Ramifications of Increasing Patient Access to Data either through VDT or APIs 8

10. Why discuss patient access? Paul Tang, Vice Chair, HITPC, asked us to investigate the ramifications of increasing patient access to data – We have taken on this topic before (Tiger Team). HITPC Consumer WG is addressing Objective 5 – Objective 5: Patient electronic access to health information (receive) – Objective 6: Coordination of care through patient engagement (use) Consumer WG raised questions about the level of privacy and security in non-HIPAA regulated apps – Once a patient pulls data through an API to an app, the data is largely unprotected (only FTC enforcement) 9

11. Objective 5: Patient Electronic Access to Health Information Proposed objective: Use communications functions of CEHRT to engage with patients or their authorized representatives about a patient’s care. Must report all 3 and meet thresholds for 2/3. Measures: – Measure 1: > 25% of unique patients “actively engage” with EHR either through “view/download/transmit” or through the use of an ONC-certified API that can be used by patient third party apps or devices. – Measure 2: secure message sent to >35% of unique patients – Measure 3: patient generated health data or data from nonclinical setting incorporated into CEHRT for >15% of unique patients Exclusion: EP with no office visits. EP/EH in area with insufficient broadband 10

12. Ramifications of increasing patient access to data either through VDT or APIs 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 11 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

13. HIPAA Privacy Rule – Patient Access (1) Privacy Rule – patient right of access regardless of format of PHI (§164.524) – 2013 Omnibus Rule made clear that patients have right to request electronic copy of information (in a designated record set) maintained electronically Covered Entity (CE) must provide information in the form and the format requested by an individual, if it is “readily producible – Individual can direct a CE to transmit directly to an individual's designee (third party) – No access to provider admin systems (not designated record set) – Applies only to information present at the time the request is fulfilled – CE may reject use of external portable media if unacceptable level of risk (Security Rule risk analysis) 12 Source: Fed. Reg. Vol 78, No. 17, January 25, 2013: http://www.gpo.gov/fdsys/pkg/FR-2013-01-25/pdf/2013-01073.pdfhttp://www.gpo.gov/fdsys/pkg/FR-2013-01-25/pdf/2013-01073.pdf

14. HIPAA Privacy Rule – Patient Access (2) Privacy Rule – patient right of access regardless of format of PHI (§164.524) CE can deny (non-reviewable) if: – PHI is not covered by right of access (e.g., psychotherapy notes) – CE is a correctional institution – PHI is collected as part of research – Information is covered by Privacy Act & exempt from disclosure – Information was obtained under commitment of confidentiality CE may reject use of external portable media if unacceptable level of risk (Security Rule risk analysis) (format is not “readily producible”) 13 Source: Fed. Reg. Vol 78, No. 17, January 25, 2013: http://www.gpo.gov/fdsys/pkg/FR-2013-01-25/pdf/2013-01073.pdfhttp://www.gpo.gov/fdsys/pkg/FR-2013-01-25/pdf/2013-01073.pdf

15. HIPAA Privacy Rule – Patient Access (3) Provider can deny (reviewable) if: – A licensed health care professional has determined that the access requested is reasonably likely to endanger the life or physical safety of the individual or another person; – The PHI makes reference to another person (not a provider) and a professional determines that the access is reasonably likely to cause substantial harm to the other person; and – The access is requested by a personal representative – and the professional determines that access by the personal representative is reasonably likely to cause substantial harm to the individual or another person. In all three cases, professional must be exercising “professional judgment” 14 Source: Fed. Reg. Vol 78, No. 17, January 25, 2013: http://www.gpo.gov/fdsys/pkg/FR-2013-01-25/pdf/2013-01073.pdfhttp://www.gpo.gov/fdsys/pkg/FR-2013-01-25/pdf/2013-01073.pdf

16. Previous Recommendations on View and Download 15 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 Source: 8/16/2011 HITPC Transmittal Letter. http://www.healthit.gov/sites/faca/files/HITPC_PSTT_Transmit_8162011.pdfhttp://www.healthit.gov/sites/faca/files/HITPC_PSTT_Transmit_8162011.pdf

17. Previous Recommendations on View and Download 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 16 Source: 8/16/2011 HITPC Transmittal Letter. http://www.healthit.gov/sites/faca/files/HITPC_PSTT_Transmit_8162011.pdfhttp://www.healthit.gov/sites/faca/files/HITPC_PSTT_Transmit_8162011.pdf

18. Previous Recommendations on View and Download 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 17

19. Previous Recommendations on View and Download 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 18

20. Straw Comment for Discussion Generally, the Workgroup supports the proposal to use open APIs to increase patient electronic access to health information, as this advances the principles of individual access and openness and transparency However, the Workgroup is concerned about potential privacy and security risks associated with patient’s access to health information electronically ONC should reference and adopt previous P&S TT recommendations regarding best practices for view and download ONC should specifically address the scope of a provider’s ability to deny a patient’s request to transmit electronic health information to a third party application or other entity where – based on a current security risk analysis – such a request may pose a security threat to a provider’s health IT systems ONC should also address the extent to which provider’s may reject the request on other grounds. 19

21. Backup Slides 20

22. Objective 1 Comparison with HIPAA Security Rule 21 Proposed Objective 1HIPAA Security Rule (45 CFR 164.308(a)(1)) Limited to annually conducting or reviewing a security risk analysis to assess whether the technical, administrative, and physical safeguards and risk management strategies are sufficient to reduce the potential risks and vulnerabilities to the confidentiality, availability, and integrity of ePHI created by or maintained in CEHRT. Must continually assess the potential risks and vulnerabilities to the confidentiality, availability, and integrity of all ePHI that an organization created, receives, maintains or transmits. Includes all electronic media, such as hard drives, floppy disks, disks, smart card or other storage devices, personal digital assistants.

23. HIPAA Privacy Rule – Patient Access Right of Access: P. 5631 – Comment: concern that rule would give access to provider admin systems – Final Rule: CE not required to provide direct access to CE systems; must only provide individuals with an electronic copy of their PHI 22 Source: Fed. Reg. Vol 78, No. 17, January 25, 2013: http://www.gpo.gov/fdsys/pkg/FR-2013-01-25/pdf/2013-01073.pdfhttp://www.gpo.gov/fdsys/pkg/FR-2013-01-25/pdf/2013-01073.pdf

24. HIPAA Privacy Rule – Patient Access Form and Format: P. 5632-5634 – Final Rule: electronic form and format requested by the individual, if it is readily producible, or, if not, in a readable electronic form and format as agreed to by the CE and the individual – Security Rule requires risk analysis; not required to accept external media if determine risk is unacceptable – Provide information CE possesses “at the time the request is fulfilled” – CE may require requests in writing (includes e-mail) – Duty to notify/warn (not educate) individuals of risks of unencrypted e-mail 23 Source: Fed. Reg. Vol 78, No. 17, January 25, 2013: http://www.gpo.gov/fdsys/pkg/FR-2013-01-25/pdf/2013-01073.pdfhttp://www.gpo.gov/fdsys/pkg/FR-2013-01-25/pdf/2013-01073.pdf

25. Previous P&S Tiger Team Recommendations 24 ONC should develop and disseminate best practices for identity proofing and authentication for patient access to portals * ONC should strongly encourage providers to use more than single factor authentication to permit patient access; ONC should encourage providers to protections analogous to those used in online banking * ONC should develop and disseminate best practices for assuring that access to adult patient VDT be extended to friends and family authorized by the patient, and, where appropriate, legal personal representatives** * 5/3/2013 HITPC Transmittal Letter. http://www.healthit.gov/sites/faca/files/hitpc_transmittal_050313_pstt_recommendations.pdfhttp://www.healthit.gov/sites/faca/files/hitpc_transmittal_050313_pstt_recommendations.pdf ** 6/24/2014 HITPC Transmittal Letter. http://www.healthit.gov/sites/faca/files/PSTT_personal_reps_VDT_Transmittal%20Letter_2014- 06-10_01.pdfhttp://www.healthit.gov/sites/faca/files/PSTT_personal_reps_VDT_Transmittal%20Letter_2014- 06-10_01.pdf

26. Previous P&S TT Recommendations to HITPC 25 HITPC 1/8/2013 HITPC Meeting: “Recommendations on Patient Identity Proofing and Authentication” http://www.healthit.gov/facas/sites/faca/files/tigerteam_pati ent_authentication_hitpc_010813_0.pdf http://www.healthit.gov/facas/sites/faca/files/tigerteam_pati ent_authentication_hitpc_010813_0.pdf HITPC 4/8/2014 HITPC Meeting: “Privacy & Security Tiger Team: Family, Friends & Personal Representative Access Recommendations” http://www.healthit.gov/facas/sites/faca/files/HITPC_Persona lRepresentativeUpdate_2014-04-08.pdf http://www.healthit.gov/facas/sites/faca/files/HITPC_Persona lRepresentativeUpdate_2014-04-08.pdf