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 67: | Line 67: | ||
=== 3.2. Challenges in Policy, Regulations, and Compliance === | === 3.2. Challenges in Policy, Regulations, and Compliance === | ||
As previously discussed in Section 1, policies and regulations such as those defined by HIPAA suggest a foundation for software audit mechanisms, yet fail to provide any fundamental guidance for software developers to build compliant software systems. In this section, we group policy and regulatory challenges into two categories: ill-defined standards, policies, and regulations; and ineffective log analysis. | |||
==== 3.2.1. Ill-defined Standards, Policies, and Regulations ==== | ==== 3.2.1. Ill-defined Standards, Policies, and Regulations ==== | ||
Standards provide a foundation for consistency and quality. With software systems, coding standards provide a set of guidelines and suggestions for making program code style consistent across software applications; software developers may choose to ignore standards if they wish, but overall quality and understandability may be sacrificed. | |||
Software audit mechanisms are inconsistent. Log file content, timestamps, and formats may vary externally over software companies and internally over software applications of the same company<sup>[8]</sup>. Distributed web services, for example, may have different policies based on the host machines<sup>[3]</sup>; the database server may have one set of auditing policies, while the web server may have a completely different set of auditing policies. In addition, the physical location of the distributed systems may cause concern. Again, the organization (or country) that hosts the database server likely has different policies and regulations compared to the organization (or country) that hosts the web server. Furthermore, the transmission of data between these servers may pass through additional organizational authority, which likely introduces an additional degree of varying policies and regulations. Chuvakin and Peterson<sup>[3]</sup> state that administrators of such complicated distributed systems may not currently enable security features (such as software audit mechanisms) by default; instead, software organizations must actively enable auditing features by choice. Without a default auditing system enabled, user-based non-repudiation and enforcement of accountability would likely decline. | |||
Even if software audit mechanisms are enabled, these mechanisms still face other challenges, such as ambiguous logging requirements. When implementing audit mechanisms, software developers may focus on recording only additions, deletions, and modifications of data; the developers tend to overlook viewing or reading of data, however<sup>[11]</sup>. In healthcare<sup>[5]</sup>, viewing and reading data in EHR systems is a vital concern when managing protected health information. | |||
Without well-defined standards and regulations by a central governing body, the industry has no widely accepted standard for software audit mechanisms<sup>[3]</sup>, including audit mechanisms in EHR systems. This leaves the responsibility of interpreting and complying with vague regulatory verbiage to individual software development teams who may be unprepared, untrained, or unaware of policies and regulations that govern the software systems upon which they work. | |||
==== 3.2.2. Ineffective Log Analysis ==== | ==== 3.2.2. Ineffective Log Analysis ==== | ||