YOU ARE DOWNLOADING DOCUMENT

Please tick the box to continue:

Transcript
Page 1: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

Privacy and Security Tiger Team

Today’s Discussion:

MU3 RFC Comments

May 8, 2013

Page 2: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

2

Agenda

• Wrap up RFC Comments (backup slides)• Further discussion of MU Stage 3 Attestation of

Security• Tiger Team Next Steps

Page 3: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

3

MU3 RFC Comments

• The Tiger Team’s goal is to determine if there are relevant policy considerations to discuss, based on the feedback received from the MU3 Request for Comments period, and whether previous Tiger Team recommendations address the questions.

• In addition, it should determine whether particular questions assigned to the Tiger Team would be better served by a discussion and response by the HIT Standards Committee and its Privacy and Security Workgroup.

• Goal is to finalize recommendations for MU3.

Page 4: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

4

PSTT04 Summary

• What, if any, security risk issues (or Health Insurance Portability and Accountability Act (HIPAA) Security Rule provisions) should be subject to Meaningful Use attestation in Stage 3?

• Question: Should this be in lieu of, or added to, the existing attestation requirements (completion of security risk assessment and addressing encryption of data at rest)?

PSTT04 Summary: MU Attestation for Security Risks

Page 5: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

Overview of HIPAA Privacy & Security Rule Workforce Training Requirements

& Findings of the HITECH Audit Program

David Holtzman

U.S. Department of Health and Human Services

Office for Civil Rights

5

Page 6: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

Privacy Rule Workforce Training

• Covered entities must train all members of workforce on the organization’s policies and procedures implemented to comply with Privacy Rule

• Scope/breadth of training commensurate with workforce functions or role

• Document workforce member training• Additional training must be provided when material

changes to covered entity’s policies & procedures

U.S. Department of Health and Human Services, Office for Civil RightsMay 8, 2013 page 6

Page 7: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

Security Rule Training

• Security Awareness and Training Standard requires covered entities and business associates to train each individual with access to e-PHI of the organization’s security measures to reduce the risk of improper access, uses, and disclosures

• Addressable implementation specifications require CE/BA to put into place reasonable and appropriate measures to implement– Periodic updates or security reminders– Procedures for guarding against malicious software– Monitoring log-in attempts and reporting discrepancies– Procedures for creating, changing and safeguarding passwords

• Scope/breadth/refresher training commensurate with functions or role

U.S. Department of Health and Human Services, Office for Civil RightsMay 8, 2013 page 7

Page 8: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

Level 1 Entities• Large Provider / Payer• Extensive use of HIT - complicated

HIT enabled clinical /business work streams

• Revenues and or assets greater than $1 billion

Level 2 Entities• Large regional hospital system (3-10

hospitals/region) / Regional Insurance Company

• Paper and HIT enabled work flows• Revenues and or assets between

$300 million and $1 billion

U.S. Department of Health and Human Services, Office for Civil Rights May 8, 2013 | page 8

Level 3 Entities• Community hospitals, outpatient surgery, regional pharmacy / All Self-Insured entities that don’t adjudicate their claims• Some but not extensive use of HIT – mostly paper based workflows• Revenues between $50 million and $300 million

Level 4 Entities• Small Providers (10 to 50 Provider Practices, Community or rural pharmacy)• Little to no use of HIT – almost exclusively paper based workflows• Revenues less than $50 million

Summary of Entities Audited

Page 9: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

Size/Type of Entities Audited

U.S. Department of Health and Human Services, Office for Civil Rights May 8, 2013 | page 9

 Level 1 Level 2 Level

3Level 4 Total

Health Plans 13 12 11 11 47

Healthcare Providers 11 16 10 24 61

Healthcare Clearinghouses 2 3 1 1 7

Total 26 31 22 36 115

Data as of December 2012.

Page 10: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

Overall Findings & Observations

No findings or observations for 13 entities (11%) •2 Providers, 9 Health Plans, 2

ClearinghousesSecurity accounted for 60% of the findings and observations—although

only 28% of potential total

Providers had a greater proportion of findings & observations (65%) than reflected by their proportion of the total

set (53%)

Smaller, Level 4 entities struggle with all three

areas

NIST / OCR May 22, 2013 10

Page 11: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

Types of Privacy Rule Audit Findings

0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

50%

20%

2%

16% 18%

44%

U.S. Department of Health and Human Services, Office for Civil Rights May 8, 2013 | page 11

Data as of December 2012.

Page 12: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

Privacy Administrative Elements

12

Page 13: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

Security Results

58 of 59 providers had at least one Security finding or observation

No complete & accurate risk assessment in two thirds of entities•47 of 59 providers, •20 out of 35 health plans and •2 out of 7 clearinghouses

Security addressable implementation specifications: Almost every entity

without a finding or observation met by fully implementing the addressable

specification.

13

Page 14: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

Types of Security Rule Audit Findings

Risk Analysis

Access

Management

Securit

y Incid

ent Pro

cedures

Contingency Planning

Audit Contro

ls and M

onitorin

g

Movement and Destr

uction of M

edia0%

4%

8%

12%

16%

20%

12%14%

9%

18%14% 14%

U.S. Department of Health and Human Services, Office for Civil Rights May 8, 2013 | page 14

Data as of December 2012.

Page 15: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

15

Tiger Team Next Steps

• Privacy and Security Re: Cloud Computing

• Right of Access in an Electronic Environment

Page 16: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

16

BACK-UPQuery/Response

Page 17: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

17

PSTT01 Summary

• How can the HITPC’s recommendation be reconciled with the National Strategy for Trusted Identities in Cyberspace (NSTIC) approach to identification which strongly encourages the re-use of third party credentials? Straw Response: The Tiger Team’s September 2012 recommendations on provider user identity management apply. These were adopted by the Policy Committee in September 2012 and expressly referenced NSTIC. The recommendations urged multi-factor authentication at NIST Level of Assurance (LoA) 3 for remote access to PHI; entities covered by HIPAA should also, as part of their security risk assessment, identify other access environments that may require multiple factors to authenticate an asserted identity. Provider users should continue to be identity proofed in compliance with HIPAA. Work being as part of NSTIC to establish trusted, third-party credentials is ongoing but such solutions are not yet widely available, and may not be by Stage 3. Consequently, as recommended by the Policy Committee, ONC's efforts on this issue should continue to be informed by NSTIC developments, including (but not limited to) the work being done in the NSTIC pilots.**

PSTT01 Summary: Re-use of 3rd Party Credentials

**Source: Sept 2012 HITPC Recommendations to ONC http://www.healthit.gov/sites/default/files/transmittal_092512_pstt_recommendations_provider_authentication.pdf

Page 18: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

18

• How would ONC test the HITPC’s recommendation (for two-factor authentication) in certification criteria?

• Straw Response: As the question does not request a policy-based response, the Tiger Team believes this question would be best answered by the HITSC Privacy and Security Workgroup.

PSTT02 Summary: Certification Criteria for Testing Authentication

Page 19: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

19

• Should ONC permit certification of an EHR as stand-alone and/or an EHR along with a third-party authentication service provider?

• Straw Response: Yes

PSTT03 Summary: EHR Certification - Standalone or

Page 20: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

20

• Is it feasible to certify the compliance of EHRs based on the prescribed [ASTM] standard for [audit logs]?

• Straw Response: The Tiger Team suggests that the HITSC Privacy and Security Workgroup address whether it is feasible to certify compliance of EHRs with the prescribed ASTM audit log standard. Some Tiger Team members also questioned the adequacy of the standard.

PSTT05 Summary: Certification Standard for Audit Logs

Page 21: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

21

• Is it appropriate to require attestation by meaningful users that such logs are created and maintained for a specific period of time?

• Straw Response: The HIPAA Security Rule does not require that audit logs are maintained for a specific period of time. Consequently, the Tiger Team does not see a reason to require additional policy specifying a timeframe. Covered entities will make their own decisions on audit trail maintenance periods based on their internal policies.

PSTT06 Summary: Attestation for Length of Time Logs

Page 22: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

22

• Is there a requirement for a standard format for the log files of EHRs to support analysis of access to health information access multiple EHRs or other clinical systems in a healthcare enterprise?

• Straw Response: Although there are arguments in favor of standardizing formats for log files, this is a lower priority discussion in the context of Meaningful Use. The Tiger Team recommends following the guidance of the HIPAA Security Rule, which does not require any particular audit trail format.

PSTT07 Summary: Standard Format for Log Files

Page 23: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

23

• Are there any specifications for audit log file formats that are currently in widespread use to support such applications?

• Straw Response: The Tiger Team recommends following the guidance of the HIPAA Security Rule, which does not require any particular format. The HITSC Privacy and Security Workgroup can determine whether particular specifications should be required for EHR certification.

PSTT08 Summary: Audit Log File Specifications

Page 24: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

24

• Some federal and state health information privacy and confidentiality laws, including but not limited to 42 CFR Part 2 (for substance abuse), establish detailed requirements for obtaining patient consent for sharing certain sensitive health information, including restricting the recipient’s further disclosure  of such information. Three questions were put forth.

MU4 Summary: Patient Consent

Page 25: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

25

1) How can EHRs and HIEs manage information that requires patient consent to disclose so that populations receiving care covered by these laws are not excluded from health information exchange?

2) How can MU help improve the capacity of EHR infrastructure to record consent, limit the disclosure of this information to those providers and organizations specified on a consent form, manage consent expiration and consent revocation, and communicate the limitations on use and restrictions on re-disclosure to receiving providers?

3) Are there existing standards, such as those identified by the Data Segmentation for Privacy Initiative Implementation Guide, that are mature enough to facilitate the exchange of this type of consent information in today’s EHRs and HIEs?

MU4 Summary: Patient Consent

Page 26: Privacy and Security Tiger Team Today’s Discussion: MU3 RFC Comments May 8, 2013.

26

• Straw Response: The Tiger Team refers to its recent recommendations (adopted by the Policy Committee) on Query/Response re: technical mechanisms to support communication of patient consent requirements.– Data holders and requesters should comply with applicable

law and policy and should have a technical way to communicate applicable consent or authorization needs and requirements. They should also have a means to maintain a record of such transactions. The HITSC should further consider technical methods for giving providers the capacity to comply with applicable patient authorization requirements or policies.

• The Tiger Team has deferred further discussion on data segmentation** until it has received an update on the DS4P Initiative pilot projects.

MU4 Summary: Patient Consent

**Source: Sept 2010 HITPC Recommendations to ONC http://www.healthit.gov/sites/default/files/hitpc_transmittal_p_s_tt_9_1_10_0.pdf


Related Documents