Modifying Without a Trace: High-level Audit Guidelines are Inadequate for Electronic Health Record Audit Mechanisms: Difference between revisions
Programsam (talk | contribs) |
Programsam (talk | contribs) |
||
| Line 49: | Line 49: | ||
== 3. Related Work == | == 3. Related Work == | ||
Related literature has identified several challenges and limitations with software audit mechanisms. Here, we discuss challenges in technology and challenges with policy, regulations, and compliance. | |||
=== 3.1. Challenges in Technology === | === 3.1. Challenges in Technology === | ||
Audit mechanisms in EHR systems face several challenges and limitations because of technology. We group these challenges into two categories: limited infrastructure resources and log file reliability | |||
==== 3.1.1. Limited Infrastructure Resources ==== | ==== 3.1.1. Limited Infrastructure Resources ==== | ||
Behind every piece of software lies some sort of hardware configuration. Hardware, itself, provides limitations that affect software. For example, information storage may be restricted to a single hard drive with a limited storage capacity. As a result, EHR systems must manage storage resources carefully. | |||
Another challenge involves distributed software systems. Chuvakin and Peterson suggest that the biggest technological challenge of audit mechanisms involves determining the location at which generating, storing, and managing the log files will be most beneficial for the subject domain and intent of the software application [3]. In these systems, software components may run on separate host machines. For example, one machine may host a database server while a separate machine hosts a web server. In this situation, software audit mechanisms are not as centralized or easy to implement with the physically distributed nature of the overall software application. Here, the actual site of the audit logging functionality is not easy to define [3]. Should software generate audit trails at the web server level, at the database server level, both, or at some third-party location? Software architects must determine the ideal location of user-based non-repudiation audit mechanisms to ensure all user accountholder actions are recorded and monitored. | |||
==== 3.1.2. Log File Reliability ==== | ==== 3.1.2. Log File Reliability ==== | ||