Modifying Without a Trace: High-level Audit Guidelines are Inadequate for Electronic Health Record Audit Mechanisms: Difference between revisions
Jump to navigation
Jump to search
Programsam (talk | contribs) |
Programsam (talk | contribs) |
||
| Line 101: | Line 101: | ||
* Chuvakin and Peterson<sup>[3]</sup> provide a general checklist of items that should be logged in web-based software applications. We collect 17 auditable events from this source. | * Chuvakin and Peterson<sup>[3]</sup> provide a general checklist of items that should be logged in web-based software applications. We collect 17 auditable events from this source. | ||
* The Certification Commission for Health Information Technology (CCHIT) | * The Certification Commission for Health Information Technology (CCHIT)<sup>1</sup> specifies an appendix of auditable events specific to EHR systems. CCHIT is a certification body authorized by the United States Department of Health & Human Services for the purpose of certifying EHR systems based on satisfactory compliance with government-developed criteria for meaningful use<sup>[2]</sup>. We collect 17 auditable events from this source. | ||
* The SysAdmin, Audit, Network, Security (SANS) Institute provides a checklist of information system audit logging requirements to help advocate appropriate and consistent audit logs in software information systems<sup>[7]</sup>. We collect 18 auditable events from this source. | * The SysAdmin, Audit, Network, Security (SANS) Institute provides a checklist of information system audit logging requirements to help advocate appropriate and consistent audit logs in software information systems<sup>[7]</sup>. We collect 18 auditable events from this source. | ||
* The “IEEE Standard for Information Technology: Hardcopy Device and System Security” presents a section on best practices for logging and auditability, including a listing of suggested auditable events<sup>[6]</sup>. We collect 8 auditable events from this source. | * The “IEEE Standard for Information Technology: Hardcopy Device and System Security” presents a section on best practices for logging and auditability, including a listing of suggested auditable events<sup>[6]</sup>. We collect 8 auditable events from this source. | ||
Combining all four sets of data, we collect 60 total non-specific auditable events and event types. After combining duplicates, our set contains 28 unique auditable events and event types. The only item appearing in all four suggested auditable events sets is “security administration event”, suggesting all four sources are concerned about software security. Out of the 28 unique events, 18 (64.3%) are contained in at least two of the source sets. Ten events (35.7%) are only contained in one source set. The overlap among the four sources suggests some common understanding and agreement of general events that should be logged, yet the disparity seems to indicate disagreement about the scope and breadth of auditable events. Table 1 provides a comparison of the four source sets of non-specific auditable events and event types. | |||
Next, we categorize each individual auditable event or event type from Table 1 into one of two categories: events that ''affect'' user-based non-repudiation, and events that ''do not affect'' user-based non-repudiation. Our categorization is denoted in Table 1 under the “Affects User-based Non-repudiation” column. When categorizing these events, we determine if the given event can be traced to a specific user accountholder in an EHR system. If so, we categorize this event as one that affects user-based non-repudiation. If the event cannot be traced to a specific user accountholder, we categorize the event as one that does not affect user-based non-repudiation. For example, the “view data” event suggests a user accountholder (such as a physician) has authenticated into an EHR system and is viewing protected patient health information. The action of viewing this protected data can be traced to the physician’s user account. Therefore, this event is categorized as one that does affect user-based non-repudiation. On the other hand, an “application process failure” does not suggest any intervention by a user accountholder. Instead, this event suggests an internal EHR system state change. Therefore, we categorize this event as not affecting user-based non-repudiation. | |||
Of the 28 total auditable events and event types, we identify 16 events that affect user-based non-repudiation. Of these 16 actions, only 9 events (56.25%) are suggested by two or more of the sources. The remaining 7 events (43.75%) are contained in only one source set. | |||
==== 4.1.2 High-level Assessment Methodology ==== | ==== 4.1.2 High-level Assessment Methodology ==== | ||