Security Audit Application

The Security Audit Application provides a centralized location to display audit data and review system activity. As a part of a comprehensive Security Audit program, the use of the Security Audit Application can help protect electronic health information (EHI) as well as information that is sensitive to the organization.

The Security Audit Application allows information that is stored in the audit log tables to be accessed from the Security Audit Log and Security Change Log screens. Writing auditable events is done at one of two levels. Access events (ex. Query, Access, Print, and Copy) are recorded at the Application level and typically by screen or patient data category. Whereas, transaction events (ex. Insert, Update, and Delete) are recorded at the database level through database triggers. Transaction events may be configured using three different auditing levels: no audit required, transaction level and change level. Data stored at the change level may be selected from the audit log to display the Security Change Log for that audit entry. For more information on configuring audit levels please see the Data Dictionary Table List.

auditing mechanism

Writing Auditable Events

Because the audit application provides facility management the ability to audit PHI and non-PHI information, TruBridge strongly recommends that access to the auditing application be limited. This will ensure that data, sensitive not just to the patient but also the organization, is kept secure.

Granting access to the Auditing application in Identity Management allows access to the Security Audit Log screen and the Security Change Log screen. By default, all members of the System Administration role will have access to Auditing through use of the TruBridge Default Application Rule for System Administrators. This access may be customized for other users within the organization by allowing or denying access to specific auditing screens.

audit_log_security

Rule Based Security

The following access is granted with each screen when the rule is set to Allow.

•Security Audit Log Screen: Allows access to Security Audit Log.

•Security Change Log Screen: Allows access the Security Change Log which may include sensitive PHI and facility information.

If a user has access to the Security Change Log, behavior controls will also be need. Events that occur at the transaction level are recorded by the PostgresSQL table, each table in turn is assigned to a specific database access role (ex. Accounts Receivable, Clinical Information, Table Maintenance). The behavior controls for the Security Change Log are laid out by Role as well. If a user has audit access for a specific Role, then the Change Log data for all the tables that belong to that Role may be viewed. This will allow flexibility when assigning access to the Security Audit Application. The image below illustrates how the relationship between the Security Change Log behavior controls and PHI.

behavior_controls

Behavior Controls

The following behavior controls are available for the Security Change Log screen.

•Audit access for Accounting Role

•Audit access for Accounts Receivable Role

•Audit access for Payroll Role

•Audit access for Time and Attendance Role

•Audit access for Patient clinical Information Role

•Audit access for Table Maintenance Role

•Audit access for Unassigned DB Role

Below is a list of intended users for the Security Audit Application as well as the recommended security setting for each.

Intended User	System Administrator Role	Rule Based Security
IT Staff (Help Desk)	Yes	Create a single rule denying access to Security Change Log (security_change_log) screen and associate each staff member to this rule.
IT Management	Yes	Apply the TruBridge Default System Administrator Application Rule to the System Administrator Role and apply necessary Behavior Controls after performing a use case assessment.
HIPAA Security Officer/Privacy Officer	No	Create an Allow Rule for the Auditing Application at the user level and limit Behavior Controls to restrict access to sensitive Non-PHI data.
Other Users	No	Assess the use case for other users before allowing access

Overview

Overview