Source: https://www.healthit.gov/test-method/auditing-actions-health-information
Timestamp: 2020-01-18 18:09:43
Document Index: 455633359

Matched Legal Cases: ['§170', '§170', '§170', '§ 170', '§ 170', '§ 170', '§ 170', '§ 170', '§ 170', '§ 170', '§ 170', '§ 170', '§ 170', '§ 170', '§ 170', '§ 170']

Auditing actions on health information | HealthIT.gov
§170.315 (d)(10) Auditing actions on health information—
By default, be set to record actions related to electronic health information in accordance with the standard specified in §170.210(e)(1).
If technology permits auditing to be disabled, the ability to do so must be restricted to a limited set of users.
Actions recorded related to electronic health information must not be capable of being changed, overwritten, or deleted by the technology.
Technology must be able to detect whether the audit log has been altered.
Paragraph (d)(10)(i)
§170.315(d)(10) Test Procedure
Version 1.0 Updated on 10-26-2015
Certification Companion Guide: Auditing actions on health information
This certification criterion at § 170.315(d)(10) may be required as part of the 2015 Edition privacy and security approach for the certification criteria at § 170.315(g)(7), (g)(8), and (g)(9). A developer may choose to demonstrate either § 170.315(d)(2) or § 170.315(d)(10) as part of the 2015 Edition privacy & security approach for § 170.315(g)(7), (g)(8), and (g)(9). If the developer chooses to demonstrate § 170.315(d)(10) for § 170.315(g)(7), (g)(8), and/or (g)(9), this criterion at § 170.315(d)(10) only needs to be demonstrated once as part of the overall scope of the certificate sought.
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 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 developer may choose to certify either § 170.315(d)(2) or this criterion at § 170.315(d)(10) to meet the requirements of 2015 Edition privacy and security approach. [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.2 through 7.4, 7.6, and 7.7 of the ASTM E2147-01 standard when health IT is in use, changes to user, and records the date and time in accordance with either RFC 1305 or RFC 5905.
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.2 through 7.4, 7.6, and 7.7) of ASTM E2147-01 are the minimum required for certification. [see also 77 FR 54234]
We intend 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]
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 (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.
Paragraph (d)(10)(ii)
Paragraph (d)(10)(iii)
Technical outcome – The health IT will not allow actions recorded related to electronic health information to be changed, overwritten, or deleted by the technology.
Paragraph (d)(10)(iv)
Hashing is one method to detect whether an audit log has been altered. We encourage the use of hashing algorithms specified in FIPS 180-4 (Secure Hash Standard) to determine whether the audit log has been altered. [see also 77 FR 54235]