Notice of Proposed Rulemaking (NPRM) Comments

Privacy and Security Workgroup

Deven McGraw, chairStan Crosley, co-chair

April 27, 2015

2

Agenda

• Meaningful Use Stage 3 Notice of Proposed Rulemaking (NPRM) Discussion

3

PSWG NPRM Workplan - Detail

Meetings Task

April 20, 2015 2:30-4:30pm ETCertification NPRM

• Data Segmentation for Privacy (DS4P)• Pharmacogenomics

April 27, 2015 12:00-1:30pm ETMU3 NPRM

• Objective 1: Protect Patient Health Information• Ramifications of increased patient access to data

May 1, 201510:00-11:30am ETNPRM Finalization

• Finalize outstanding comments

May 12, 2015 HITPC Meeting • Present NPRM Comments

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

4

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)

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

7

Alignment with Previous PSTT Recommendations

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-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

9

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

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)10

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

11

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

12

• 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)

Source: Fed. Reg. Vol 78, No. 17, January 25, 2013: http://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”)

Source: Fed. Reg. Vol 78, No. 17, January 25, 2013: http://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”

Source: Fed. Reg. Vol 78, No. 17, January 25, 2013: http://www.gpo.gov/fdsys/pkg/FR-2013-01-25/pdf/2013-01073.pdf

16

Previous Recommendations on View and Download

• 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.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

Source: 8/16/2011 HITPC Transmittal Letter. http://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

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

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.

21

Backup Slides

22

Objective 1 Comparison with HIPAA Security Rule

Proposed Objective 1 HIPAA 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

Source: Fed. Reg. Vol 78, No. 17, January 25, 2013: http://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-mailSource: Fed. Reg. Vol 78, No. 17, January 25, 2013: http://www.gpo.gov/fdsys/pkg/FR-2013-01-25/pdf/2013-01073.pdf

25

Previous P&S Tiger Team Recommendations

• 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.pdf** 6/24/2014 HITPC Transmittal Letter. http://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

• HITPC 1/8/2013 HITPC Meeting: “Recommendations on Patient Identity Proofing and Authentication” http://www.healthit.gov/facas/sites/faca/files/tigerteam_patient_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_PersonalRepresentativeUpdate_2014-04-08.pdf