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

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]