Meaningful Use Stage 2 Security and Privacy Requirements

Kathleen Connor VA (ESC)HL7 Security WG

April 2012

2

Table of ContentsCertification Criteria Topic Certification Criteria

SectionSlides

TOC 2Purpose of Presentation 3Proposed Comment Table 4-7Overarching Collaboration Statement 8General Response to Privacy and Security Certification Criteria 9General Response to Privacy and Security Incentive NPRM 10

Authentication, Access Control, & Authorization § 170.314(d)(1) 11-20

Auditable events & tamper resistance § 170.314(d)(2) 21-30Audit report(s) § 170.314(d)(3) 31-36Amendments § 170.314(d)(4) 37-43Automatic log-off § 170.314(d)(5) 44-49Emergency access § 170.314(d)(6) 50-54Encryption of data at rest § 170.314(d)(7) 55-61Integrity § 170.314(d)(8) 62-68Accounting of disclosures (optional) § 170.314(d)(9) 69-75Secure Messaging § 170.314(e)(3) 76-81View, Download, and Transmit to 3rd party § 170.314 (C) 82-90Security & Privacy Measures Incentive NPRM 91-96Background 97-99

3

Presentation Purpose• HL7 Policy Committee requests that Security and CBCC Work

Group review and provide comment on the Meaningful Use Stage 2 Certification Criteria & Incentive NPRMs

• Each of the Security and Privacy related provisions are in the following table with Proposed HL7 Response for approval by the Work Groups

• Each relevant provision is listed (hyperlink to slides in TOC), and background from NPRM discussion and other sources are provided for background

• Please review citations, questions, and proposed responses for Work Group discussions

4

Meaningful Use State 2 OBJECTIVESHealth Outcomes Policy Priority

Stage 2 Objectives Stage 2 MeasuresEligible Professionals Eligible Hospitals and

CAHsEnsure adequate privacy and security protections for personal health information

§ 495.6(j)(16)PIP82-84FRP13716C3-13717C1,Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities

§ 495.6(l)(15)PIP82-84FRP13716C3-13717C1, FRP13821C2Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities

PIP82-84FRP13716C3-13717C1Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1), including addressing the encryption/security of data at rest in accordance with requirements under 45 CFR 164.312 (a)(2)(iv) and 45 CFR 164.306(d)(3), and implement security updates as necessary and correct identified security deficiencies as part of the provider's risk management process.

Stage 1:Conduct or review a security risk analysis per 45 CFR 164.308 (a)(1) and implement security updates as necessary and correct identified security deficiencies as part of its risk management process

5

STANDARDS & CERTIFICATION CRITERIA Proposed HL7 CommentsStage 1 / 2011 Edition 2014 Edition

Criterion Standards Criterion StandardsN/A N/A § 170.314(d)(4)

AmendmentsPage 25-26, Page 173Replace existing information in a way that preserves the original information

Append patient supplied information in both free text and scanned format

Enable a user to electronically append a response to patient supplied information in a patient’s health record

HL7 recommends that the Amendment certification criteria reference the need to include Amendment technology, such as inclusion of hyperlinked Amendments, in the HIPAA Security Risk Assessment conducted as part of the MU Stage 2 Incentive program.

§ 170.210(b) - FRP44650Record actions related to electronic health information

§ 170.210(b) - FRP44650The date, time, patient identification, and user identification must be recorded when electronic health information is created, modified, accessed, or deleted; and an indication of which action(s) occurred and by whom must also be recorded.

§ 170.314(d)(2)Auditable events and tamper-resistance

Page 77-79, Page 161-162, Page 172-173The audit log must be enabled by default (i.e., turned on), immutable (i.e., unable to be changed, overwritten, or deleted), and able to record not only which action(s) occurred, but more specifically the electronic health information to which the action applies.

The ability to enable and disable the recording of actions be limited to an identified set of users (e.g., system administrator).

When the audit log is enabled or disabled, the date and time (in accordance with the standard specified at § 170.210(g) (synchronized clocks)), user identification, and the action(s) that occurred must be recorded;

As applicable, when encryption for end-user devices managed by EHR technology is enabled or disabled, the date and time (in accordance with the standard specified at § 170.210(g) (synchronized clocks)), user identification, and the actions that occurred must be recorded.

Auditable Events are critical for enforcing all aspects of Security System, not just detecting alteration of Audit Log, and integral to Access Reports and Accounting for Disclosure. HL7 recommends that standard vocabularies be required for the Authentication, Access Control, and Authorization criteria be used for managing and recording Auditable Events including: (1) Clinical terminologies and HL7 Information Category codes to denote information objects; (2) HL7 Data Operations Codes to denote “actions”; and (3) ASTM E1986 Structural Role value set (constrained to meet the criteria requirements) ; HL7 Participation Function Codes associated with Security Permissions such as conveyed by the HL7 RBAC Permissions Catalog Codes to supplement User Identification where a User may play more than one role; HL7 EHR Functional Model; and HL7 Data Types to encode User Identification. Where there are gaps, ONC should work with relevant SDOs such as ISO, HL7, ASTM, OASIS XSPA, and IHE to develop standards needed to fully implement Auditable eventing capabilities in EHRs.

§ 170.302(r) - FRP44652Audit Log

§ 170.210(b) - FRP44650The date, time, patient identification, and user identification must be recorded when electronic health information is created, modified, accessed, or deleted; and an indication of which action(s) occurred and by whom must also be re

§ 170.314(d)(3)Audit Report(s)

Page 77-79, Page 161-162, Page 173 HL7 recommends that the Audit Report Synchronized Clock standard Date and Time be aligned with the Date and Time standards used for other Security Certification Criteria, e.g., Access Control and Authorization especially where these are governed by time and date sensitive context constraints; and Accounting of Disclosure standard data elements for time and date.

6

STANDARDS & CERTIFICATION CRITERIA Proposed HL7 CommentsStage 1 / 2011 Edition 2014 Edition

Criterion Standards Criterion Standards§ 170.302(u) - FRP44652General encryption

§ 170.210(a)(1) – FR Page 44650FIPS Publication 140-2 Annex A

§ 170.314(d)(7)Encryption of data at rest

Page 79-83, Page 161-162, Page 174Capability of EHR technology to encrypt and decrypt electronic health information managed by EHR technology on end-user devices if such electronic health information would remain stored on the devices after use of EHR technology on that device has stopped.

Support NIST Special Publication (SP) 800-111

HL7 supports the certification criteria for encryption of data at rest.

§ 170.302(o) - FRP44652Access control

§ 170.302(t) - FRP44652Authentication

N/A § 170.314(d)(1)Authentication, access control, and authorization

Page 95-96, Page 161-162, Page 172 The Authentication, Access Control, and Authorization Certification Criteria applies only to internal users while several other criteria involve secure messaging with external users. This criteria lacks interoperable vocabulary standards by which to: (1) consistently specify electronic health information as distinguishable security objects; (2) specify whether the access is at a coarse or fine grain level as would likely be required for data segmentation for privacy; (3) encode the "actions" in a consistent and meaningful manner using standard data operations vocabulary; and (4) specify an interoperable value set of standard structural and functional roles. These gaps impact the computability and human readable utility of the related audit reports and the accounting of disclosure certification criteria. HL7 recommends that the Final Rule: (1) require that this certification criteria apply to external users with which secure messaging is conducted; and (2) require adoption of the privacy and security standard vocabularies such as: HL7 Confidentiality Codes; HL7 Data Operations Codes; HL7 US Privacy Law, Information Sensitivity, Purpose of Use, Obligation, and Refrain Policy Act Codes; HL7 Information Category codes to denote information categories; clinical terminologies to denote information objects; to denote Security Roles, use ASTM E1986 Structural Role value set (constrained to meet the criteria requirements), and HL7 Participation Function codes associated with permissions, such as those encoded by the HL7 RBAC Permission Catalog to augment Unique User Identifiers, which may be associated with many roles; and HL7 Data Types to encode User Identification. Where there are gaps, ONC should work with relevant SDOs such as ISO, HL7, ASTM, OASIS XSPA, and IHE to develop standards needed to fully implement Authentication, Access Control, and Authorization capabilities in EHRs.

§ 170.302(q) - FRP44652Automatic Log-Off

N/A § 170.314(d)(5)Automatic Log-off

Page 96-97, Page 173 HL7 supports the certification criteria for Automatic Log-off.

§ 170.302(p) - FRP44652Emergency access

N/A § 170.314(d)(6)Emergency Access

Page 97, Page 173 HL7 recommends that the Final Rule specify standard vocabulary for Emergency Access that is consistent with the Authentication, Access Control, and Authorization criteria to support this criteria including: (1) User identifier using HL7 user identifier data types; (2) user role using ASTM E1986 value set and HL7 Participation Function codes related to Security Permissions such as HL7 RBAC Permission Catalog; (3) purpose of use using HL7 Purpose of Use codes, i.e., emergency treatment, public health surveillance, disaster, threat, etc.; and (4) actions using HL7 Data Operations code set.

7

STANDARDS & CERTIFICATION CRITERIA CommentsStage 1 / 2011 Edition 2014 Edition

Criterion Standards Criterion Standards§ 170.302(s) - FRP44652Integrity

§ 170.210(c) - FRP44650A hashing algorithm with a security strength equal to or greater than SHA–1 (Secure Hash Algorithm (SHA–1) as specified by theNational Institute of Standards and Technology (NIST) in FIPS PUB 180–3 (October, 2008))

§ 170.314(d)(8)Integrity

Page 97-98, Page 161-162, Page 174

HL7 recommends that ONC replace SHA-1 with more secure hash standard SHA-2 to verify that electronic health information has not been altered.

§ 170.302(w) - FRP44652Accounting of disclosures

§ 170.210(d) - FRP44652The date, time, patient identification, user identification, and a description of the disclosure must be recorded for disclosures for treatment, payment, and health care operations, as these terms are defined at 45 CFR 164.501

§ 170.314(d)(9)Accounting of Disclosures

Page 98-99, Page 174 Accounting of Disclosures is already required under HIPAA. However, there is no standard electronic format currently available by which to encode Accounting of Disclosures that is computably interoperable and human readable. ONC should support the development of Accounting of Disclosure standard format and vocabulary, including those we recommend for other Security Criteria be required such as: (1) HL7 Purpose of Use for HIPAA Treatment, Payment, Operations (TPO), and more granular variants included in their HIPAA definitions, e.g., Emergency Treatment, Quality Improvement and Underwriting; (2) ASTM E1986 Structural Roles – e.g., value set for interoperable roles associated with functional roles representing permissions associated with TPO; and (3) “Actions" should be encoded with HL7 Data Operations codes. We suggest that relevant SDOs such as HL7 and S&I Framework Consolidated CDA project be tasked to develop Accounting of Disclosure CDA Template and Implementation Guide. Once these standards are adopted, ONC should make computable, interoperable, and human readable Accounting of Disclosure standard a mandatory certification criterion for MU Stage 3.

§ 170.314(b)(2) PIP58-61, PIP169-170 FRP13848C1-13850C1 Create and transmit summary care record

HL7 recommends that the Final Rule require adoption of the privacy and security standards for XDR and XDM transport metadata as specified in the ONC Data Segmentation for Privacy Initiative such as HL7 Confidentiality Codes, and other Privacy and Security vocabulary we have recommended in our comments.

§ 170.314(e)(1)PIP26-35, PIP174-177FRP13839C1-13841C2

Ability to provide a patient accessible log to track the use of the view, download, and transmit capabilities

HL7 recommends that the Patient Accessible Log be recorded using the standards we recommend for Audit Records generally. We recommend that Patient Accessible Logs be captured and conveyed using a standard, computable, interoperable, and human-readable format such as a CCDA Template.

FRP13872C2Does the concept of a capability to batch export a single patient’s records (or a provider’s entire patient population) pose unintended consequences from a security perspective? What factors should be considered to mitigate any potential abuse of this capability, if it existed?

See General Comment on Incentive NPRM

8

Overarching Collaboration Statement

• HL7 notes several certification criteria that would likely benefit from and enhance the MU Stage 2 value proposition through cross-SDO development of semantically interoperable standards, e.g.,– Structured CDA templates and supporting clinical, administrative,

security, and privacy vocabularies for encoding:• Nationally recognized Advance Directive forms• Accounting of Disclosures and Access Reports• Privacy and Security encoded policies that receiving systems can

consistently consume and enforce• Privacy and Security codes that enable annotation of specially protected

information for purposes of data segmentation and restricting disclosure to authorized users for specified purposes

9

General HL7 Response to Privacy and Security Certification Criteria

• HL7 recommends that Privacy and Security Certification Criteria require the use of standard formats and vocabularies that align across related criteria such as:

• Authentication, Access Control, and Authorization• Auditable Events• Audit Reports• Emergency Access• Accounting of Disclosure

10

General HL7 Response to Privacy and SecurityIncentive NPRM

• HL7 recommends that the MU Stage 2 Measure: – Conduct a security risk analysis in accordance with the requirements under 45 CFR

164.308(a)(1)• Specifically include (in addition to Encryption of Data at Rest) a security risk

analysis of and risk mitigation for the technological approach each EP, EH, or CAH chooses to meet the following certification criteria:– Authentication, Access Control, Authorization– Auditable Events and Tamper Resistance– Audit Reports– Emergency Access– Integrity– Secure Messaging– Amendments– Batch Exports of Patient Records

11

AUTHENTICATION, ACCESS CONTROL, AND AUTHORIZATION

Certification Criteria § 170.314(d)(1)

12

Authentication, Access Control, and AuthorizationMU Objective (Pages 95 – 96)

MU Objective Protect electronic health information created or maintained by the Certified EHR Technology through theimplementation of appropriate technical capabilities.2014 Edition EHR Certification Criterion§ 170.314(d)(1) (Authentication, access control, and authorization)

13

Authentication, Access Control, and AuthorizationDiscussion on Approach (Pages 95-96)

• Merged Authentication and Access control criteria• Capability to authenticate human users would consist of the

assertion of an identity and presentation of at least one proof of that identity– Focus on users that would be able to access electronic

health information in EHR technology and – Does not include external users that may make requests for

access to health information contained in the EHR technology for the purpose of electronic health information exchange

14

Authentication, Access Control, and AuthorizationDiscussion about Standards (Pages 95-96)

Example standards and implementation specifications which could be followed in designing EHR technology to meet this certification criterion could include, but are notlimited to: • NIST Special Publication 800-63, Level 2 (single-factor

authentication) • ASTM, E1986-09 (Information Access Privileges to

Health Information)

15

Authentication, Access Control, and Authorization

Merged 2011 Edition Criteria Page 106

45 CFR § 170.302 General certification criteria for Complete EHRs or EHR Modules.• (o) Access control. Assign a unique name and/or number for identifying

and tracking user identity and establish controls that permit only authorized users to access electronic health information

• (t) Authentication. Verify that a person or entity seeking access to electronic health information is the one claimed and is authorized to access such information.

16

Authentication, Access Control, and AuthorizationCertification Criteria (Page 172)

(d) Privacy and security.(1) Authentication, access control, and authorization.

(i) Verify against a unique identifier(s) (e.g., username or number) that a person seeking access to electronic health information is the one claimed; and(ii) Establish the type of access to electronic health information a user is permitted based on – the unique identifier(s) provided in paragraph (d)(1)(i) of

this section, and – the actions the user is permitted to perform with the EHR

technology.

17

Authentication, Access Control, and Authorization Questions

• Do we support merged Authentication and Access Control criteria?

• Do we agree with no focus on authentication of external users? – What about authenticating patients per § 170.210 (3)

Ambulatory setting only—secure messaging. Enable a user to electronically send messages to, and receive messages from, a patient in a manner that ensures:• (i) Both the patient and EHR technology are authenticated; and• (ii) The message content is encrypted and integrity-protected

in accordance with the standard for encryption and hashing algorithms specified at § 170.210(f).

18

Authentication, Access Control, and AuthorizationQuestions

• Do we agree that verifying “against a unique identifier(s) (e.g., username or number) that a person seeking access to electronic health information is the one claimed” is sufficient for Authenticating the user?

• Do we agree with these example standards? – Are there others? ASTM, E1986-09 includes data objects and roles,

some of which are mapped so SNOMED; and a subset of which was adopted by HITSP C80 and NHIN. Without more specificity, difficult to ascertain the adequacy of this standard when tested for certification.

– Should Final Rule require adoption of the privacy and security standard vocabularies for Authentication, Access Control, and Authorization such as HL7 Confidentiality Codes, Data Operations Code System, RBAC Permissions Catalog Identifier Codes, Act Privacy Policy, Information Sensitivity, Purpose of Use, Obligation, and Refrain Policy?

19

Authentication, Access Control, and Authorization Proposed HL7 Comments/Recommendations

The Authentication, Access Control, and Authorization Certification Criteria

• Applies only to internal users while several other Criteria involve secure messaging with external users

• Lacks interoperable vocabulary standards by which to:– Consistently specify electronic health information as distinguishable security objects

– Specify whether the access is at a coarse or fine grain level as would like be required for data segmentation for privacy

– Encoding the actions in a consistent and meaningful manner

– Specify an interoperable value set of standard Structural and Functional Roles

• These gaps impact the computability and human readable utility of the related audit reports and the accounting of disclosure certification criteria

20

Authentication, Access Control, and Authorization Proposed HL7 Response

Recommend that the Final Rule:• Require that this Certification Criteria apply to external users with which Secure

Messaging is conducted• Require adoption of the privacy and security standard vocabularies such as:

– HL7 Confidentiality Codes– HL7 Data Operations Codes– HL7 RBAC Permissions Catalog Codes– HL7 US Privacy Law, Information Sensitivity, Purpose of Use, Obligation, and Refrain Policy Act

Codes– HL7 Information Category Codes to denote information categories– Clinical Terminologies to denote information objects– ASTM E1986 Structural Role value set (constrained to meet the criteria requirements), and HL7

Participation Function codes associated with permissions, such as those encoded by the HL7 RBAC Permission Catalog to denote Security Roles to augment Unique User Identifiers, which may be associated with many roles

– HL7 Data Types to encode User Identification• Where there are gaps, ONC should work with relevant SDOs such as ISO, HL7, ASTM,

OASIS XSPA, and IHE to develop standards needed to fully implement Authentication, Access Control, and Authorization capabilities in EHRs.

21

AUDITABLE EVENTS & TAMPER RESISTANCE

Revised Standard § 170.210(e)Certification Criteria § 170.314(d)(2)

22

170.314(d)(2)Auditable Events & Tamper Resistance

Discussion (Page 77-79)

MU Objective Protect electronic health information created or maintained by the Certified EHR Technology through theimplementation of appropriate technical capabilities.2014 Edition EHR Certification Criteria§ 170.314(d)(2) (Auditable events and tamper-resistance)§ 170.314(d)(3) (Audit report(s))Standard§ 170.210(e) (Record actions related to electronic health information, audit log status, and encryption of end user devices)

23

170.314(d)(2)Auditable Events & Tamper Resistance

Discussion (Page 77-79)

Recommend for clarity that we move the specific capability “detection” from the Integrity criterion to the proposed auditable events and tamper-resistance criterion• More stringent audit logs certification policy will assist with

better detection and investigation of breaches• Audit log must be:

– Enabled by default (i.e., turned on)– Immutable (i.e., unable to be changed, overwritten, or deleted), – Able to record not only which action(s) occurred, but more specifically

the electronic health information to which the action applies – Have ability to enable and disable the recording of actions be limited

to an identified set of users (e.g., system administrator)

24

Auditable Events & Tamper ResistanceDiscussion (Page 77-79)

To Accommodate 170.314 (d)(2) proposing • Revised standard at §170.210(e)• Requiring that:

1. When the audit log is enabled or disabled, must record• Date and Time (in accordance with the standard specified at § 170.210(g)

(synchronized clocks))• User identification• Action(s) that occurred

2. When encryption for end-user devices managed by EHR technology is enabled or disabled, must record• Date and Time (in accordance with the standard specified at § 170.210(g)

(synchronized clocks))• User identification• Action(s) that occurred

25

Auditable Events & Tamper ResistanceDiscussion (Page 77-79)

• Did not use “security-relevant events” because ambiguous

• Proposed minimum set of (testable) actions required to be captured

• Example implementation specification:– ASTM E2147-01, Standard Specification for Audit

and Disclosure Logs for Use in Health Information Systems

26

Auditable Events and Tamper-ResistanceRevised standard at § 170.210(e)

(Page 161-162)

(e) Record actions related to electronic health information, audit log status, and encryption of end-user devices. (1) When EHR technology is used to create, change, access, or delete electronic health information, the following information must be recorded:

(i) The electronic health information affected by the action(s);(ii) The date and time each action occurs in accordance with the standard specified at §170.210(g);(iii)The action(s) that occurred;(iv)Patient identification; and(v) User identification.

27

Auditable Events and Tamper-ResistanceRevised standard at § 170.210(e)

(Page 161-162)

(2) When the audit log is enabled or disabled, the following must be recorded:

(i) The date and time each action occurs in accordance with the standard specified at §170.210(g); and(ii) User identification.

(3) As applicable, when encryption of electronic health information managed by EHR technology on end-user devices is enabled or disabled, the following must be recorded:

(i) The date and time each action occurs in accordance with the standard specified at §170.210(g); and(ii) User identification.

28

Auditable Events and Tamper-Resistance Certification Criteria

(Page 172 – 173)(2) Auditable events and tamper-resistance.(i) Enabled by default. The capability specified in paragraph (d)(2)(ii) of this section must be enabled by default (i.e., turned on) and must only be permitted to be disabled (and re-enabled) by a limited set of identified users.

(ii) Record actions. Record actions related to electronic health information, audit log status and, as applicable, encryption of end-user devices in accordance with the standard specified in § 170.210(e).(iii) Audit log protection. Actions recorded in accordance with paragraph (d)(2)(ii) must not be capable of being changed, overwritten, or deleted.(iv) Detection. Detect the alteration of audit logs.

29

Auditable Events and Tamper-Resistance Questions

• Detection capabilities seems to be restricted to detecting alteration of audit logs – Is Integrity tamper resistance sufficient for detecting alterations of data?– What other security risks need detection capabilities?

• Is ASTM E2147-01, Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems the only and/or most relevant standard?

• Is the Synchronized Clock standard sufficient (see notes)• Should there be standardized methods for recording:

– Information Objects– User Identification and Roles– Date and Time– Actions (e.g., HL7 Data Operations code system)?

30

Auditable Events and Tamper-ResistanceProposed HL7 Response

• Auditable Events are critical for enforcing all aspects of Security System, not just detecting alteration of Audit Log, and integral to Access Reports and Accounting for Disclosure.

• Recommend that standard vocabularies required for the Authentication, Access Control, and Authorization criteria be used for managing and recording Auditable Events including:– Clinical Terminologies and HL7 Information Category codes to denote information objects– HL7 Data Operations Codes to denote “actions”– ASTM E1986 Structural Role value set (constrained to meet the criteria requirements) ; and

HL7 Participation Function Codes associated with Security Permissions such as conveyed by the HL7 RBAC Permissions Catalog Codes to supplement User Identification where a User may play more than one role

– HL7 Data Types to encode User Identification

• Where there are gaps, ONC should work with relevant SDOs such as ISO, HL7, ASTM, OASIS XSPA, and IHE to develop standards needed to fully implement Authentication, Access Control, and Authorization capabilities in EHRs.

31

AUDIT REPORTS

§ 170.210 (e)(2) StandardCertification Criteria § 170.314(d)(3)

32

170.314(d)(3) Audit ReportsDiscussion (Pages 77-79)

• Recommend for clarity that we move the specific capability “detection” from the Integrity criterion to the proposed auditable events and tamper-resistance criterion.

33

Audit Reports§ 170.210 (e)(2) Standard (Pages 161)

(2) When the audit log is enabled or disabled, the following must be recorded:

(i) The date and time each action occurs in accordance with the standard specified at §170.210(g); and(ii) User identification.

34

Audit ReportsCertification criteria (Page 172)

Enable a user to create an audit report for a specific time period and to sort entries in the audit log according to each of the elements specified in the standard at §170.210(e)(2):

(2) When the audit log is enabled or disabled, the following must be recorded:

(i) The date and time each action occurs in accordance with the standard specified at §170.210(g) {Synchronized Clocks}; and(ii) User identification.

35

Audit ReportsQuestions

• Is Integrity tamper resistance sufficient?• What other security risks need detection capabilities?• Is the Synchronized Clock standard §170.210(g) sufficient for

documenting Date and Time in a manner that is human readable and can be used in Accounting of Disclosures?

• Are the following Audit Report Data Elements sufficient? (i) The date and time each action occurs in accordance with the standard specified at §170.210(g); and(ii) User identification.

• E.g., does the User Role, Information Object, Action, and perhaps other Context or Permission information need to be recorded?

36

Audit ReportsProposed HL7 Response

• HL7 recommends that the Audit Report Synchronized Clock standard Date and Time be aligned with the Date and Time standards used for other Security Certification Criteria, e.g., – Access Control and Authorization especially where

these are governed by time and date sensitive context constraints

– Accounting of Disclosure standard data elements for time and date

37

AMENDMENTSCertification Criteria 170.314(d)(4)

38

170.314(d)(4) AmendmentsDiscussion (Page 25-26)

• MU Objective• Protect electronic health information created

or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities

• Enable compliance with HIPAA Privacy Rule Amendment requirements [45 CFR 164.526 See Notes below]

39

Amendments - Summary

(i) Enable a user to electronically amend a patient’s health record to:

(A) Replace existing information in a way that preserves the original information; and(B) Append patient supplied information, in free text or scanned, directly to a patient’s health record or by embedding an electronic link to the location of the content of the amendment.

(ii) Enable a user to electronically append a response to patient supplied information in a patient’s health record.

40

AmendmentsRequested Comments (Page 26)

We specifically request comment on whether EHR technology should be required to be capable of appending patient supplied information in both free text and scanned format or only one or these methods to be certified to this proposed certification criteria.

41

Amendments Certification Criteria(Page 173)

(i) Enable a user to electronically amend a patient’s health record to:

(A) Replace existing information in a way that preserves the original information; and(B) Append patient supplied information, in free text or scanned, directly to a patient’s health record or by embedding an electronic link to the location of the content of the amendment.

(ii) Enable a user to electronically append a response to patient supplied information in a patient’s health record.

42

AmendmentsQuestions

• What’s the difference between free text and scanned format?

• While Amendments are included with Privacy and Security Criteria, are there Privacy and Security concerns that should be addressed? – E.g., Security concerns related to embedding an

electronic link to the location of the content of the amendment

43

AmendmentsProposed HL7 Response

• HL7 recommends that the Amendment certification criteria reference the need to include Amendment technology, such as inclusion of hyperlinked Amendments, in the HIPAA Security Risk Assessment conducted as part of the MU Stage 2 Incentive program.

44

AUTOMATIC LOG-OFFCertification Criteria § 170.314(d)(5)

45

§ 170.314(d)(5) Automatic Log-offMU Objective (Page 96-97)

MU Objective Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities.2014 Edition EHR Certification Criterion§ 170.314(d)(5) (Automatic log-off)

46

§ 170.314(d)(5) Automatic Log-offDiscussion (Page 96-97)

• Clarifies that to terminate a session should not be confused with locking a session, where access to an active session is permitted after reauthentication.– Not revising or refining this certification criterion, but are

clarifying that to terminate a session should not be confused with locking a session, where access to an active session is permitted after re-authentication.

– EHR technology must have the capability to terminate the session, including terminating the network connection.

47

Automatic Log-off Certification criteria (Page 173)

(5) Automatic log-off. • Terminate an electronic session after a

predetermined time of inactivity.

48

Automatic Log-offQuestions

• Do we have concerns about EHR technology maturity wrt to the capability to terminate the session, including terminating the network connection?

49

Automatic Log-offProposed HL7 Response

• HL7 supports the certification criteria for Automatic Log-off.

50

EMERGENCY ACCESSCertification Criteria 170.314(d)(6)

51

170.314(d)(6) Emergency AccessDiscussion Page 97

• Removing the parenthetical “who are authorized for emergency situations” and including the phrase “identified set of users” to more clearly convey this certification criterion’s intent.

• The purpose of this criterion is to provide certain users (“identified set of users”) with the ability to override normal access controls in the case of an emergency.

52

Emergency Access Certification criteria (p. 173)

(6) Emergency access. Permit an identified set of users to access electronic health information during an emergency.

53

Emergency Access Questions

• How are the identified set of users with emergency access to be specified?

• Should there be a standard for designating:– User ID– User Role– Purpose of Use– Actions

54

Emergency AccessProposed HL7 Response

• HL7 recommends that the Final Rule specify standard vocabulary consistent with the Authentication, Access Control, and Authorization criteria to support this criteria including:– User ID using HL7 user identifier data types– User Role using ASTM E1986 value set and HL7 Participation

Function codes related to Security Permissions such as HL7 RBAC Permission Catalo

– Purpose of Use using HL7 Purpose of Use codes, i.e., emergency treatment, public health surveillance, disaster, threat, etc.

– Actions using HL7 Data Operations code set

55

ENCRYPTION AT RESTCertification Criteria 170.314(d)(7)

56

Encryption of Data at RestMU Objective (Page

MU Objective Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities.

57

Encryption of Data at RestDiscussion (Pages 79-83)

Two ways that EHR Vendors can demonstrate they meet certification criteria at § 170.314(d)(7):• The EHR technology is designed to manage electronic health information on end-

user devices and on which electronic health information would remain stored on the end-user devices after use of the EHR technology on the devices has stopped.

• We use “stopped” to mean that the session has been terminated, including the termination of the network connection.

• In these circumstances, EHR technology presented for certification must be able to encrypt the electronic health information that remains on end user devices.

• And, to comply with paragraph (d)(7)(i), this capability must be:– enabled (i.e., turned on) by default and – only be permitted to be disabled (and re-enabled) by a limited set of identified users.

• The EHR technology developer can demonstrate that its EHR technology can meet §170.314(d)(7)(ii) by proving that electronic health information managed by EHR technology never remains on end-user devices after use of EHR technology on those devices has stopped.

58

Encryption of Data at RestDiscussion (Page 79-83)

• HITSC recommends that we revise the “general encryption” criterion in favor of one focused on the capability to encrypt and decrypt electronic health information managed by EHR technology on end-user devices if such information would remain stored on the devices after use of EHR technology on that device has stopped

• Did not include “decrypt” in the proposed criterion because we believe that the critical capability to require is the act of encryption after use of the EHR technology on the end-user device has stopped

59

Encryption of Data at RestCertification Criteria (Page 174)

(7) Encryption of data at rest. Paragraph (d)(7)(i) or (ii) of this section must be met to satisfy this certification criterion.(i) If EHR technology manages electronic health information on an end-

user device and the electronic health information remains stored on the device after use of the EHR technology on that device has stopped, the electronic health information must be encrypted in accordance with the standard specified in § 170.210(a)(1).

(ii) This capability must be enabled by default (i.e., turned on) and must only be permitted to be disabled (and re-enabled) by a limited set of identified users.

(ii) Electronic health information managed by EHR technology never remains stored on end-user devices after use of the EHR technology on those devices has stopped.

60

Encryption of Data at RestQuestions

• Do we have concerns about EHR technology maturity wrt to the capability to meet the Encryption of Data at Rest Certification Criteria

61

Encryption of Data at RestProposed HL7 Response

• HL7 supports the certification criteria for encryption of data at rest.

62

INTEGRITY

Standard §170.210(c) Certification Criteria 170.314(d)(8)

63

IntegrityMU Objective(Pages 97)

MU Objective Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities.2014 Edition EHR Certification Criterion• § 170.314(d)(8) (Integrity)Standard• § 170.210(c) (Verification that electronic health

information has not been altered)

64

IntegrityDiscussion (Pages 97 – 99)

• Capability to detect changes to an audit log has been removed from this proposed certification criterion and added to the proposed certification criterion for “auditable events and tamper resistance”

• Understand that the strength of a hash function in digital signature applications is limited by the length of the message digest and that in a growing number of circumstances the message digest for Secure Hash Algorithm (SHA) -1 is too short for secure digital signatures (SHA-2 produces a 256-bit message digest that is expected to remain secure for a long period of time)– Certain operating systems and applications upon which EHR technology may

rely use SHA-1 and do not or cannot support SHA-2 at the present time– Thus, we request public comment on whether we should leave the standard

as it currently reads or replace SHA-1 with SHA-2

65

IntegrityStandard (Pages 161-162)

Mu Stage 1 2011 edition: §170.210(c)(c) Verification that electronic health information has not been altered in transit.Standard. A hashing algorithm with a security strength equal to or greater than SHA–1 (Secure Hash Algorithm (SHA–1) as specified by the National Institute of Standards and Technology (NIST) in FIPS PUB 180–3 (October, 2008)) must be used to verify that electronic health information has not been altered.

66

Integrity Certification Criteria – p. 174

i) Create a message digest in accordance with the standard specified in §170.210(c).(ii) Verify in accordance with the standard specified in §170.210(c) upon receipt of electronically exchanged health information that such information has not been altered

67

IntegrityQuestions

• Should ONC leave the standard as it currently reads or replace SHA-1 with SHA-2

• Is the Certification Criteria testable in a manner that indicates that the EHR in fact:• Create a message digest for all transmitted information• Verify Integrity on all information received?

68

IntegrityProposed HL7 Response

• HL7 recommends that ONC replace SHA-1 with more secure hash standard SHA-2 to verify that electronic health information has not been altered.

69

ACCOUNTING OF DISCLOSURES (OPTIONAL)

Standard § 170.210(d) Certification Criteria § 170.314(d)(9)

70

Accounting of Disclosures (optional) Discussion & Request for Comment

(Pages 98-99)

• Unchanged

• We previously adopted an “accounting of disclosures” optional certification criterion for the 2011 Edition EHR certification criteria (§ 170.302(w)), which requires EHR technology to be capable of electronically recording disclosures made for treatment, payment, and health care operations in accordance with the standard specified in § 170.210(d) (“Record treatment, payment, and health care operations disclosures. The date, time, patient identification, user identification, and a description of the disclosure must be recorded for disclosures for treatment, payment, and health care operations, as these terms are defined at 45 CFR 164.501”).

• We are proposing to adopt this same certification criterion as an optional certification criterion for the 2014 Edition EHR certification criteria (§ 170.314(d)(9)), but are requesting public comment on whether we should adopt a revised certification criterion.

• Since publication of the S&CC July 2010 final rule, the HHS Office for Civil Rights issued a proposed rule (76 FR 31426) addressing the changes required by section 13405(c) of the HITECH Act, including changes to the accounting of disclosure requirements under the HIPAA Privacy Rule.

• We are interested in whether commenters believe that the 2014 Edition EHR certification criterion for “accounting of disclosures” should be revised to be a mandatory certification criterion.

71

Accounting of Disclosures (optional) Discussion & Request for Comment

(Pages 98-99)Continued

We are also interested in whether commenters think that the 2014 Edition EHR certification criterion should be revised to include capabilities that would more fully support an EP’s, EH’s, and CAH’s ability to comply with the current HIPAA Privacy Rule accounting for disclosure requirements at 45 CFR 164.528.

Additionally, we are interested in receiving input on whether, and what additional, changes to the certification criterion would be needed to support compliance with the proposed HIPAA Privacy Rule accounting for disclosure provisions, if they were to be adopted by final rule in substantially the same form as they were proposed.

For those commenters that believe revisions are appropriate, we respectfully request that their comments identify whether the certification criterion should be changed from optional to mandatory and identify the specific capabilities that the certification criterion should include and the rationale for including those capabilities.

72

Accounting of Disclosures Standard

(Page 133-134)

§ 170.210(d) (“Record treatment, payment, and health care operations disclosures. • The date, time, patient identification, user

identification, and a description of the disclosure must be recorded for disclosures for treatment, payment, and health care operations, as these terms are defined at 45 CFR 164.501”).

73

Accounting of Disclosures (optional) Certification Criteria

(Page 174)

170.314(d)(9) Optional—accounting of disclosures. • Record disclosures made for treatment,

payment, and health care operations in accordance with the standard specified in § 170.210(d).

74

Accounting of Disclosures Questions

• Should Accounting of Disclosures be mandatory for Stage 2 MU?

• Should Standard Vocabularies we recommend for other Security Criteria be required such as:– HL7 Purpose of Use for HIPAA Treatment, Payment, Operations (TPO),

and more granular variants included in their HIPAA definitions, e.g., Emergency Treatment, Quality Improvement and Underwriting

– ASTM E1986 Structural Roles – e.g., value set for interoperable roles associated with functional roles representing permissions associated with TPO

• Should a computable and human readable electronic format standard, such as a CCDA template be developed?

75

Accounting of DisclosuresProposed HL7 Response

• Accounting of Disclosures is already required under HIPAA. However, there is no standard electronic format currently available by which to encode Accounting of Disclosures that is computably interoperable and human readable.

• ONC should support the development of Accounting of Disclosure standard format and vocabulary, including those we recommend for other Security Criteria be required such as:– HL7 Purpose of Use for HIPAA Treatment, Payment, Operations (TPO), and more granular variants

included in their HIPAA definitions, e.g., Emergency Treatment, Quality Improvement and Underwriting

– ASTM E1986 Structural Roles – e.g., value set for interoperable roles associated with functional roles representing permissions associated with TPO

– “Actions" should be encoded with HL7 Data Operations codes

• We suggest that relevant SDOs such as HL7 and S&I Framework Consolidated CDA project be tasked to develop Accounting of Disclosure CDA Template and Implementation Guide

• Once these standards are adopted, ONC should make computable, interoperable, and human readable Accounting of Disclosure standard a mandatory certification criterion for MU Stage 3

76

SECURE MESSAGING

Certification Criteria § 170.314(e)(3)Standard § 170.210(f)

77

Secure Messaging

• MU Objective• Use secure electronic messaging to communicate

with patients on relevant health information• 2014 Edition EHR Certification Criterion• § 170.314(e)(3) (Ambulatory setting only – secure

messaging)• Standard• § 170.210(f)

78

Secure MessagingDiscussion (Page 43-44)

• We have also included what we believe should be the baseline standard in terms of encryption and hashing algorithms used to implement secure messaging.

• More specifically, we are proposing that only those identified in FIPS 140-2 Annex A be permitted to be used to meet this criterion.

• As such, we propose to adopt a new standard in § 170.210(f) to refer to FIPS 140-2 Annex A’s encryption and hashing algorithms.

• Additionally, we are proposing, consistent with the HITSC’s recommendations, that methods for meeting this certification criterion could include, but would not be limited to, designing EHR technology to meet the following standards: – IETF RFC 2246 (TLS 1.0)– SMTP/SMIME– Specifications such as NIST Special Publication 800-52 (“Guidelines for the Selection and

Use of TLS Implementations”) specifications developed as part of nationwide health information network initiatives

We propose to adopt this new certification criterion at § 170.314(e)(3).

79

Secure Messaging Certification Criteria (Page 178)

§ 170.314(e)(3) Ambulatory setting only—secure messaging. Enable a user to electronically send messages to, and receive messages from, a patient in a manner that ensures:

(i) Both the patient and EHR technology are authenticated; and(ii) The message content is encrypted and integrity-protected in accordance with the standard for encryption and hashing algorithms specified at § 170.210(f).

80

Secure Messaging Standard (Page 162)

§ 170.210(f) Encryption and hashing of electronic health information. • Any encryption and hashing algorithm

identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2 (incorporated by reference in § 170.299).

81

Secure Messaging

• § 170.202(a)(1) (Applicability Statement for Secure Health Transport)

• § 170.202(a)(2) (XDR and XDM for Direct Messaging)

• § 170.210(g) (synchronized clocks)

82

VIEW, DOWNLOAD, AND TRANSMIT TO 3RD PARTY

Standard § 170.202 Certification Criteria § 170.314 (C)

83

View, Download, and Transmit to 3rd PartyCertification Criterion

Discussion (Page 60)

• For this certification criterion, we also propose to adopt as an optional standard at § 170.202(a)(3) the SOAP-Based Secure Transport RTM version 1.032 which was developed under the nationwide health information network Exchange Initiative and to which we believe EHR technology should be able to be certified.

• We believe including this option provides added flexibility to those EPs, EHs, or CAHs that may seek to use EHR technology with the ability to transmit health information using SOAP as a transport standard in addition to SMTP to meet MU.

• While we would only permit EHR technology to be certified to these two transport standards, we intend to monitor innovation around transport and would consider including additional transport standards, such as a RESTful implementation, in this certification criterion.

84

View, Download, and Transmit to 3rd Party Standard (Page 157)

§ 170.202 Transport standards. The Secretary adopts the following transport standards:(a) Directed exchange. (1) Standard. Applicability Statement for Secure Health Transport (incorporated by reference in § 170.299).(2) Standard. External Data Representation and Cross-Enterprise Document Media Interchange for Direct Messaging (incorporated by reference in § 170.299).(3) Standard. Simple Object Access Protocol (SOAP)-Based Secure Transport Requirements Traceability Matrix (RTM) version 1.0 (incorporated by reference in § 170.299).

85

Transmit to Third PartyCertification Criteria (Page 176)

§ 170.314 (C) Transmit to third party. Electronically transmit the summary care record created in paragraph (e)(1)(i)(B)(2) of this section and images available to download in paragraph (e)(1)(i)(B)(3) of this section in accordance with:• (1) The standard specified in § 170.202(a)(1);

and• (2) The standard specified in § 170.202(a)(2).

86

View, Download, and Transmit to 3rd PartyQuestions

Wrt Transmit to 3rd Party, do we think that:• SOAP should be a required certification criterion in place of

or in addition to DIRECT?•RESTful transport standard is mature enough to make it a

mandatory/optional standard to meet the View, Download, and Transmit to 3rd party certification criteria?• Should NPRM require adoption of the privacy and security

standards for XDR and XDM transport metadata as specified in the ONC DS4P such as HL7 Confidentiality and other Privacy and Security Codes?

87

Transmit to Third Party Proposed HL7 Response

• HL7 recommends that the Final Rule require adoption of the privacy and security standards for XDR and XDM transport metadata as specified in the ONC Data Segmentation for Privacy Initiative such as HL7 Confidentiality Codes, and other Privacy and Security vocabulary we have recommended in our comments.

88

Patient accessible log.Certification Criteria (Page 176)

§ 170.314 (C)(ii)(A) When electronic health information is viewed, downloaded, or transmitted to a third party using the capabilities included in paragraphs (e)(1)(i)(A) through (C) of this section, the following information must be recorded and made accessible to the patient:

(1) The electronic health information affected by the action(s);(2) The date and time each action occurs in accordance with the standard specified at § 170.210(g);(3) The action(s) that occurred; and(4) User identification.

89

Patient Accessible LogCertification Criteria (Page 176)

(B) EHR technology presented for certification may demonstrate compliance with paragraph (e)(1)(ii)(A) of this section if:– it is also certified to the certification criterion

adopted at § 170.314(d)(2) {Auditable Event and Tamper Resistance} and

– the information required to be recorded in paragraph (e)(1)(ii)(A) is accessible by the patient.

90

Patient Accessible LogProposed HL7 Response

• HL7 recommends that the Patient Accessible Log be recorded using the standards we recommend for Audit Records generally

• We recommend that Patient Accessible Logs be captured and conveyed using a standard, computable, interoperable, and human-readable format such as a CCDA Template

91

SECURITY & PRIVACY MEASURES INCENTIVE NPRM

92

Proposed Measure: Conduct/Review a Security Risk Analysis

• Proposed Measure: Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1), including addressing the encryption/security of data at rest in accordance with requirements under 45 CFR 164.312 (a)(2)(iv) and 45CFR 164.306(d)(3), and implement security updates as necessary and correct identified security deficiencies as part of the provider's risk management process.

• This measure is the same as in Stage 1 except that we specifically address the encryption/security of data is that is stored in Certified EHR Technology (data at rest).

93

Proposed EHR performance measures - CORE

• Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities– Conduct or review a security risk analysis in accordance with

the requirements under 45 CFR 164.308(a)(1), including addressing the encryption/security of data at rest in accordance with requirements under 45 Code of Federal Regulations (CFR) 164.312 (a)(2)(iv) and 45 CFR 164.306(d)(3), and implement security updates as necessary and correct identified security deficiencies as part of the provider's risk management process.

– EP and Hospital– Request for comments: pp. 82-84 of NPRM

94

Proposed EHR performance measures - CORE

• Secure electronic messaging• A secure message was sent using the

electronic messaging function of Certified EHR Technology by more than 10 % of unique patients seen by the EP during the EHR reporting period.

• Request for comments: pp. 135-138 of NPRM

95

Secure messaging

• Enable a user to electronically send messages to, and receive messages from, a patient in a manner that ensures:– (i) Both the patient and EHR technology are authenticated; and– (ii) The message content is encrypted and integrity-protected in

accordance with any encryption and hashing algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2

– Request for comments: pp. 43-44 of NPRM

96

Should Health care team membersbe incorporated into Stage 2?

• Health care team members– Record health care team

members (including at a minimum primary care provider (PCP), if available) for more than 10 % of all patients seen during the reporting period; this information can be unstructured.

– EP and Hospital– Request for comments: p.

154 of NPRM

• HL7 Response: – Would be helpful for

implementation of RBAC with restrictions based on membership in Care Team

– ASTM 1986 is one of the standards called for in Security related Certification Criteria

97

BACKGROUND

98

Resources

• Online Federal Register• ONC fact sheet [PDF - 99 KB]• Read the CMS Proposed Rule [PDF - 966 KB ]• CMS fact sheet• HHS press release• Presentation: Proposed Rule Standards & Certification Criteria 2014 Edition [PDF - 1.3 MB]• Health IT Buzz Blog post

• DEPARTMENT OF HEALTH AND HUMAN SERVICES Office of the Secretary 45 CFR Part 170 RIN 0991-AB82 Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology

• CMS Medicare and Medicaid EHR Incentive Program MU Stage 2Adobe Acrobat

Document

99

Table 4. Equivalent Certification Criteria