ONC Issues Proposed 2015 Edition Health Information Technology Certification Criteria

On March 30, 2015, the Office of the National Coordinator for Health Information Technology (ONC) published the following proposed rule:

 

Department of Health and Human Services [HHS], Office of the Secretary, “45 CFR Part 170; 2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications,” Federal Register, v.80, n.60, March 30, 2015, pp. 16804-16921, which is available online at: http://www.gpo.gov/fdsys/pkg/FR-2015-03-30/pdf/2015-06612.pdf.  ONC invites public comment on the proposed rule, which must be received no later than 5 PM on May 29, 2015.  Instructions for submitting public comments are on page 16804 of the referenced issue of the Federal Register

 

The proposed rule Summary follows:

 

“This notice of proposed rulemaking introduces a new edition of certification criteria (the 2015 Edition health IT certification criteria or ‘‘2015 Edition’’), proposes a new 2015 Edition Base EHR definition, and proposes to modify the ONC Health IT Certification Program to make it open and accessible to more types of health IT and health IT that supports various care and practice settings. The 2015 Edition would also establish the capabilities and specify the related standards and implementation specifications that Certified Electronic Health Record (EHR) Technology (CEHRT) would need to include to, at a minimum, support the achievement of meaningful use by eligible professionals (EPs), eligible hospitals, and critical access hospitals (CAHs) under the Medicare and Medicaid EHR Incentive Programs (EHR Incentive Programs) when such edition is required for use under these programs.”

This proposed rule proposes to “[e]nsure all health IT presented for certification posses the relevant privacy and security capabilities.” [80 Federal Register 16805] Accordingly, the proposed 2015 Edition Base EHR definition is changed to take into the following consideration regarding privacy and security:

“It [the 2015 Edition Base EHR definition] does not include privacy and security capabilities and certification criteria. We believe privacy and security capabilities would be more appropriately addressed through our new proposed approach for the privacy and security certification of Health IT Modules to the 2015 Edition, as discussed under ‘‘Privacy and Security’’ in section IV.C.1 of the preamble. Our new privacy and security approach would eliminate eligible professionals (EPs)’, eligible hospitals’, and critical access hospitals (CAHs)’ responsibilities to ensure that they have technology certified to all the necessary privacy and security criteria. Rather, as part of certification, health IT developers would need to meet applicable privacy and security certification criteria.”  We commend your attention to 80 Federal Register 16875-16876: C. Health IT Module Certification Requirements.  1. Privacy and Security.  This section describes the proposed changes in the certification process with regard to the security criteria.  In the table below, we put side by side the 2014 and 2015 security criteria for convenience.  Notice that the changes are generally semantic rather than substantive, except for the term “optional” removed from Accounting of Disclosures in the 2015 set of criteria.

 

45 CFR 170.314[1]

2014 Edition electronic health record certification criteria

45 CFR 170.315[2]

Proposed 2015 Edition Health Information Technology (Health IT) Certification Criteria

(d)(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.

 

(d)(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 technology.

(d)(2) Auditable events and tamper-resistance.

 

(i) Record actions. EHR technology must be able to: 

(A) Record actions related to electronic health information in accordance with the standard specified in 170.210(e)(1)[3]

(B) Record the audit log status (enabled or disabled) in accordance with the standard specified in 170.210(e)(2) unless it cannot be disabled by any user; and

(C) Record the encryption status (enabled or disabled) of electronic health information locally stored on end-user devices by EHR technology in accordance with the standard specified in 170.210(e)(3) unless the EHR technology prevents electronic health information from being locally stored on end-user devices (see 170.314(d)(7) of this section).

 

(ii) Default setting. EHR technology must be set by default to perform the capabilities specified in paragraph (d)(2)(i)(A) of this section and, where applicable, paragraphs (d)(2)(i)(B) or (C), or both paragraphs (d)(2)(i)(B) and (C).

 

(iii) When disabling the audit log is permitted. For each capability specified in paragraphs (d)(2)(i)(A) through (C) of this section that EHR technology permits to be disabled, the ability to do so must be restricted to a limited set of identified users.

 

(iv) Audit log protection. Actions and statuses recorded in accordance with paragraph (d)(2)(i) of this section must not be capable of being changed, overwritten, or deleted by the EHR technology.

 (v) Detection. EHR technology must be able to detect whether the audit log has been altered.

 

(d)(2) Auditable events and tamper-resistance.

 

(i) Record actions. Technology must be able to:

(A) Record actions related to electronic health information in accordance with the standard specified in 170.210(e)(1);

(B) Record the audit log status (enabled or disabled) in accordance with the standard specified in
 170.210(e)(2) unless it cannot be disabled by any user; and

(C) Record the encryption status (enabled or disabled) of electronic health information locally stored on end-user devices by technology in accordance with the standard specified in 170.210(e)(3) unless the technology prevents electronic health information from being locally stored on end-user devices (see paragraph (d)(7) of this section).

 

(ii) Default setting. Technology must be set by default to perform the capabilities specified in paragraph (d)(2)(i)(A) of this section and, where applicable, paragraph (d)(2)(i)(B) or (C) of this section, or both paragraphs (d)(2)(i)(B) and (C).

 

(iii) When disabling the audit log is permitted. For each capability specified in paragraphs (d)(2)(i)(A) through (C) of this section that technology permits to be disabled, the ability to do so must be restricted to a limited set of users.

 

 

(iv) Audit log protection. Actions and statuses recorded in accordance with paragraph (d)(2)(i) of this section must not be capable of being changed, overwritten, or deleted by the technology.

(v) Detection. Technology must be able to detect whether the audit log has been altered.

(d)(3) Audit report(s).

 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 data specified in the standards at 170.210(e).

 

(d)(3) Audit report(s).

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 data specified in the standards in 170.210(e).

(d)(4) Amendments.

 Enable a user to electronically select the record affected by a patient’s request for amendment and perform the capabilities specified in paragraphs (d)(4)(i) or (ii) of this section.

 (i) Accepted amendment. For an accepted amendment, append the amendment to the affected record or include a link that indicates the amendment’s location.

 (ii) Denied amendment. For a denied amendment, at a minimum, append the request and denial of the request to the affected record or include a link that indicates this information’s location.

 

(d)(4) Amendments.

Enable a user to select the record affected by a patient’s request for amendment and perform the capabilities specified in paragraph (d)(4)(i) or (ii) of this section.

(i) Accepted amendment. For an accepted amendment, append the amendment to the affected record or include a link that indicates the amendment’s location.

(ii) Denied amendment. For a denied amendment, at a minimum, append the request and denial of the request to the affected record or include a link that indicates this information’s location.

(d)(5) Automatic log-off.

 

Prevent a user from gaining further access to an electronic session after a predetermined time of inactivity.

 

(d)(5) Automatic access time-out.

(i) Automatically stop user access to health information after a predetermined period of inactivity.

(ii) Require user authentication in order to resume or regain the access that was stopped.

(d)(6) Emergency access.

 

Permit an identified set of users to access electronic health information during an emergency.

(d)(6) Emergency access.

Permit an identified set of users to access electronic health information during an emergency.

(d)(7) End-user device encryption.

 Paragraph (d)(7)(i) or (ii) of this section must be met to satisfy this certification criterion.

 (i) EHR technology that is designed to locally store electronic health information on end-user devices must encrypt the electronic health information stored on such devices after use of EHR technology on those devices stops.

 (A) Electronic health information that is stored must be encrypted in accordance with the standard specified in 170.210(a)(1).

 (B) Default setting. EHR technology must be set by default to perform this capability and, unless this configuration cannot be disabled by any user, the ability to change the configuration must be restricted to a limited set of identified users.

 (ii) EHR technology is designed to prevent electronic health information from being locally stored on end-user devices after use of EHR technology on those devices stops.

 Note:  In (d)(7)(i)(A) above, 170.210(a)(1) is:  “(a) Encryption and decryption of electronic health information—(1) General.  Any encryption 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, (January 27, 2010) (incorporated by reference in 45 CFR 170.299.”[4]

(d)(7) End-user device encryption.

Paragraph (d)(7)(i) or (ii) of this section must be met to satisfy this certification criterion.

(i) Technology that is designed to locally store electronic health information on end-user devices must encrypt the electronic health information stored on such devices after use of the technology on those devices stops.

(A) Electronic health information that is stored must be encrypted in accordance with the standard specified in 170.210(a)(3).

(B) Default setting. Technology must be set by default to perform this capability and, unless this configuration cannot be disabled by any user, the ability to change the configuration must be restricted to a limited set of identified users.

(ii) Technology is designed to prevent electronic health information from being locally stored on end-user devices after use of the technology on those devices stops.

Note:  The only proposed change to 45 CFR 170.210 is the addition of 170.210(a)(3), referenced above in (d)(7)(i)(A):  “(3) General. Any encryption 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, October 8, 2014.”[5]

(d)(8) Integrity.

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

 

(d)(8) Integrity.

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

(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).

(d)(9) Accounting of disclosures.

Record disclosures made for treatment, payment, and health care operations in accordance with the standard specified in 170.210(d).

 

The Version 2 HIPAA Safeguard compliance tool that links its Risk Analysis Template to 92 HIPAA Privacy Administrative Requirement, HIPAA Security, and HITECH Act Breach Notification Policies and Procedures accommodates the expanded Stage 3 Meaningful Use proposed Objective and Measure requirements discussed in the preceding post.  The Version 2 HIPAA Safeguard compliance tool also includes a concordance between Stage 1 and Stage 2 Meaningful Use Security Measure and Certification Criteria and HIPAA Security Rule standards and implementation specifications.  When finalized, the 2015 security certification criteria will be added to HIPAA Safeguard’s Meaningful Use—HIPAA Security Rule concordance.

 

Register online today for a free sample of selected content from the Version 2 HIPAA Safeguard compliance tool.  Also, we want to let our readers know that we are in the process of exploring accreditation of HIPAA Safeguard with the Electronic Healthcare Network Accreditation Commission (EHNAC) in support of compliance enforcement and insurance underwriting.




[1] See Electronic Code of Federal Regulations at: http://www.ecfr.gov/cgi-bin/text-idx?SID=b3039a5e3f781a6334a596b79f8ff3c4&mc=true&node=se45.1.170_1314&rgn=div8.

[2] See March 30, 2015, Federal Register at: http://www.gpo.gov/fdsys/pkg/FR-2015-03-30/pdf/2015-06612.pdf.

[3] References to specified provisions of 45 CFR 170.210 in this table, unless otherwise indicated, are available at: http://www.ecfr.gov/cgi-bin/text-idx?SID=5169e17e9e208cfae44e66b95076b6f5&mc=true&node=se45.1.170_1210&rgn=div8.

[4] See 45 CFR 170.299 at: http://www.ecfr.gov/cgi-bin/text-idx?SID=cb1fe9a0cb4a534dd64397dfe7c84196&mc=true&node=se45.1.170_1299&rgn=div8.

[5] See 80 Federal Register 16905.

Categories



Archives

  • October 2017 (1)
  • August 2017 (3)
  • July 2017 (1)
  • June 2017 (7)
  • May 2017 (12)
  • April 2017 (10)
  • March 2017 (2)
  • February 2017 (3)
  • January 2017 (4)
  • December 2016 (4)
  • November 2016 (7)
  • October 2016 (7)
  • September 2016 (2)
  • August 2016 (1)
  • July 2016 (3)
  • June 2016 (1)
  • May 2016 (1)
  • April 2016 (8)
  • March 2016 (6)
  • February 2016 (2)
  • December 2015 (1)
  • November 2015 (1)
  • October 2015 (4)
  • September 2015 (1)
  • June 2015 (8)
  • May 2015 (3)
  • April 2015 (2)
  • March 2015 (1)
  • November 2014 (1)
  • September 2014 (15)
  • August 2014 (6)
  • July 2014 (1)
  • June 2014 (13)
  • May 2014 (11)
  • April 2014 (13)
  • March 2014 (6)
  • February 2014 (12)
  • January 2014 (3)
  • December 2013 (1)