Printer Friendly, PDF & Email Printer Friendly, PDF & Email

§170.315(d)(10) Auditing actions on health information

Updated on 03-11-2024
Regulation Text
Regulation Text

§ 170.315 (d)(10) Auditing actions on health information

  1. By default, be set to record actions related to electronic health information in accordance with the standard specified in § 170.210(e)(1).
  2. If technology permits auditing to be disabled, the ability to do so must be restricted to a limited set of users.
  3. Actions recorded related to electronic health information must not be capable of being changed, overwritten, or deleted by the technology.
  4. Technology must be able to detect whether the audit log has been altered.
Standard(s) Referenced

Paragraph (d)(10)(i)

§ 170.210(e)(1)

  1. The audit log must record the information specified in sections 7.1.1 and 7.1.2 and 7.1.6 through 7.1.9 of the standard specified in § 170.210(h) and changes to user privileges when health IT is in use.
  2. The date and time must be recorded in accordance with the standard specified at § 170.210(g).

§ 170.210(g) Synchronized clocks. The date and time recorded utilize a system clock that has been synchronized using any Network Time Protocol (NTP) standard.

        Review the NTP Reference Document for guidance on certifying to this requirement.

§ 170.210(h) Audit log content. ASTM E2147-18 Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems

 

Certification Dependencies

Design and performance: Quality management system (§ 170.315(g)(4)) and accessibility-centered design (§ 170.315(g)(5)) must be certified as part of the overall scope of the certificate issued to the product.

  • Quality management system (§ 170.315(g)(4)): When a single QMS is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
  • Accessibility-centered design (§ 170.315(g)(5)): When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively, the developer must state that no accessibility-centered design was used.
Privacy & Security Requirements

This certification criterion at § 170.315(d)(10) may be required as part of the privacy and security approach for the certification criteria at § 170.315(g)(7), (g)(9), and (g)(10). A developer may choose to demonstrate either § 170.315(d)(2) or § 170.315(d)(10) as part of the privacy & security approach for § 170.315(g)(7) and (g)(9). If the developer chooses to demonstrate § 170.315(d)(10) for § 170.315(g)(7), (g)(9), and/or (g)(10), this criterion at § 170.315(d)(10) only needs to be demonstrated once as part of the overall scope of the certificate sought.

Revision History
Version # Description of Change Version Date
1.0

Initial publication

03-11-2024

Testing components

Attestation: As of September 21, 2017, the testing approach for this criterion is satisfied by attestation.

The archived version of the Test Procedure is attached below for reference.

System Under Test

ONC-ACB Verification

The health IT developer will attest directly to the ONC-ACB to conformance with the § 170.315 (d)(10) Auditing actions on health information requirements. 

The ONC-ACB verifies the health IT developer attests conformance to the § 170.315 (d)(10) Auditing actions on health information requirements.

Archived Version:
Updated on 05-28-2024
Regulation Text
Regulation Text

§ 170.315 (d)(10) Auditing actions on health information

  1. By default, be set to record actions related to electronic health information in accordance with the standard specified in § 170.210(e)(1).
  2. If technology permits auditing to be disabled, the ability to do so must be restricted to a limited set of users.
  3. Actions recorded related to electronic health information must not be capable of being changed, overwritten, or deleted by the technology.
  4. Technology must be able to detect whether the audit log has been altered.
Standard(s) Referenced

Paragraph (d)(10)(i)

§ 170.210(e)(1)

  1. The audit log must record the information specified in sections 7.1.1 and 7.1.2 and 7.1.6 through 7.1.9 of the standard specified in § 170.210(h) and changes to user privileges when health IT is in use.
  2. The date and time must be recorded in accordance with the standard specified at § 170.210(g).

§ 170.210(g) Synchronized clocks. The date and time recorded utilize a system clock that has been synchronized using any Network Time Protocol (NTP) standard.

        Review the NTP Reference Document for guidance on certifying to this requirement.

§ 170.210(h) Audit log content. ASTM E2147-18 Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems

 

Certification Dependencies

Design and performance: Quality management system (§ 170.315(g)(4)) and accessibility-centered design (§ 170.315(g)(5)) must be certified as part of the overall scope of the certificate issued to the product.

  • Quality management system (§ 170.315(g)(4)): When a single QMS is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
  • Accessibility-centered design (§ 170.315(g)(5)): When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively, the developer must state that no accessibility-centered design was used.
Privacy & Security Requirements

This certification criterion at § 170.315(d)(10) may be required as part of the privacy and security approach for the certification criteria at § 170.315(g)(7), (g)(9), and (g)(10). A developer may choose to demonstrate either § 170.315(d)(2) or § 170.315(d)(10) as part of the privacy & security approach for § 170.315(g)(7) and (g)(9). If the developer chooses to demonstrate § 170.315(d)(10) for § 170.315(g)(7), (g)(9), and/or (g)(10), this criterion at § 170.315(d)(10) only needs to be demonstrated once as part of the overall scope of the certificate sought.

Revision History
Version # Description of Change Version Date
1.0

Initial publication

03-11-2024
1.1

Removed “Additional Resources” from the Standards Referenced accordion. Revised for clarity a clarification for paragraph (d)(10)(iv) regarding the use of hashing algorithms to determine whether an audit log has been altered.

05-28-2024

Certification Companion Guide: Auditing actions on health information

This Certification Companion Guide (CCG) is an informative document designed to assist with health IT product certification. The CCG is not a substitute for the requirements outlined in regulation and related ONC final rules. It extracts key portions of ONC final rules’ preambles and includes subsequent clarifying interpretations. To access the full context of regulatory intent please consult the Certification Regulations page for links to all ONC final rules or consult other regulatory references as noted. The CCG is for public use and should not be sold or redistributed.

The below table outlines whether this criterion has additional Maintenance of Certification dependencies, update requirements and/or eligibility for standards updates via SVAP. Review the Certification Dependencies and Required Update Deadline drop-downs above if this table indicates “yes” for any field.

 

Certification Requirements
Technical Explanations and Clarifications

Clarifications:

  • This criterion is an “abridged” version of § 170.315(d)(2) “Auditable events and tamper resistance” as some of the capabilities included in § 170.315(d)(2) would likely not apply to a Health IT Module certified only to the applicable application programming interface (“API”) criteria, such as recording the audit log status or encryption status of electronic health information locally stored on end-user devices by the technology. A health IT developer may choose to certify either § 170.315(d)(2) or this criterion at § 170.315(d)(10) to meet the requirements in the privacy and security certification framework. [see also 80 FR 62677]

Technical outcome – The health IT, by default, is set to track actions pertaining to electronic health information in accordance with sections 7.1.1, 7.1.2, and 7.1.6 through 7.1.9 of the ASTM E2147-18 standard when health IT is in use, changes to user, and records the date and time in accordance with any NTP standard.

Clarifications:

  • The ONC Cures Act Final Rule included the requirement for Health IT Modules to support an updates to audit logging and has incorporated by reference the standard at § 170.299(c) ASTM E2147-18 Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems, approved May 1, 2018, IBR approved for § 170.210(h).
  • For purposes of certification, a Health IT Module should adhere to any Network Time Protocol standard for the synchronized clock requirement.
  • To meet this provision for certification, the health IT must be set by default to record the actions and information specified. This is to ensure that at the point of installation or upgrade, the health IT will be set by default for a provider to record the actions and information specified in § 170.210(e)(1). [see also 77 FR 54233]
  • Only those sections specified from section 7 (i.e., 7.1.1, 7.1.2, and 7.1.6, through 7.1.9) of ASTM E2147-18 are the minimum required for certification.
  • Regarding the granularity of the information, ONC expects to be recorded, this should be consistent with the guidance in Section 7.1.9 of ASTM E2147-18, which states the “granularity should be specific enough to clearly determine if data designated by federal or state law as requiring special confidentiality protection has been accessed.” And more to the point, Section 7.1.9 goes on to state that “[s]pecific category of data content, such as demographics, pharmacy data, test results, and transcribed notes type, should be identified.” For example, the ability of the audit log to record that the user accessed a patient’s medication list would be sufficient for certification, and the audit log would not need to also record the specific medication. [see also 77 FR 54234]
  • ONC intends that the actions and information can be captured in a manner that supports the forensic reconstruction of the sequence of changes to a patient’s chart. [see also 77 FR 54235]
  • “Copy” can encompass a variety of actions, including extracting data from the health IT.
  • The certification criterion requires actions initiated by the user from within the health IT interface to be tracked in the audit log. The copy and paste functions of Microsoft Windows originate outside of the health IT environment and are thus outside the scope of certification. Copy actions originating from within the health IT interface (e.g., exporting or downloading a copy of electronic health information from the health IT) are required to be tracked in the audit log.
  • Demonstration of the ability to use NIST time servers is required for certification, however vendors are not required to use NIST servers post-certification.
  • Information related to the required actions (e.g., additions, deletions, changes, queries, print, and copy) must be recorded in the audit log, however the certification criterion is not prescriptive to the method by which this is achieved and does not place limitations on the format in which this information is presented in the audit log. Developers may design systems to place content in the audit log as long as the audit logs can be used to identify the information before and after change. A "pointer to original data state" is a means of identifying original information that has been changed by a user. Similarly, a "pointer to deleted information" is a means of identifying information prior to deletion. A description of a change or deletion is acceptable as long as the type of action is specified and both the original and modified data states are able to be identified. For example, an audit log could include a link to an original document and provide a description of the modified state. Conversely, it could include a description of the original data state and provide a link to the modified document. The certification criterion is not prescriptive of how the requirement should be achieved. Demonstrating the ability to view the original document prior to a change or deletion is an acceptable method of meeting the certification requirement, however it is not required during testing.

Technical outcome – The health IT will restrict the ability for auditing to be disabled to a limited set of users if the technology permits auditing to be disabled.

Clarifications

  • Health IT does not have to interpret the meaning of “limited.” To meet this provision, health IT would need to include a capability that allows only a limited set of users to have the privileges necessary to change when auditing is enabled or disabled. Generally, ONC would expect any general health IT user could perform such actions. [see also 77 FR 54233]

Technical outcome – The health IT will not allow actions recorded related to electronic health information to be changed, overwritten, or deleted by the technology.

Clarifications:

  • This provision would not prohibit an organization from making a policy decision to delete or purge audit logs after a legal retention period. Rather it focuses only on the prohibition of health IT to delete an audit log as a condition of certification. [see also 77 FR 54235]

Technical outcome – The health IT must be able to detect whether the audit log has been altered.

Clarifications:

  • This provision requires health IT to be able to determine whether activity outside of its control has in some way altered the audit log (e.g., that the operating system was exploited to modify the health IT’s database). [see also 77 FR 54235]
  • Hashing is one method to detect whether an audit log has been altered. To determine whether an audit log has been altered, ONC encourages the use of hashing algorithms consistent with the standards adopted for hashing of electronic health information at § 170.210(c), including a hashing algorithm with security strength equal to or greater than SHA-2 as specified by NIST in Federal Information Processing Standards (FIPS) Publication 180-4, Secure Hash Standard, 180-4 (August 2015). [see also 77 FR 54235]


Archived Version: