CCHIT Certification-Security-Audit Control

visolveemr wrote on Saturday, September 12, 2009:

Hi Team,

This section discusses about the "Audit Control" in details.

We have framed the technical requirements based on our understanding. Your suggestions are most welcome.
Logging is a record of who did what, when on which system.

**Auditing Events**

1. Machine startup and shutdown; startup and shutdown of audit function.

2. Successful/unsuccessful login and logout of users; denial of service events.

3. Account lockout, password change

4. Add, modify, and delete actions on all objects such as
o Patient demographic/history/encounters/issues/prescriptions/immunizations/referrals/orders/reminders
o Fee sheet creation, charges modify and billing activities
o Batch communication and changes to the address book
o Authorizations done
o Changes to user accounts
o Changes to ACL
o Doctor office setup events related to facilities, Practice, Services, Layouts, Lists, Language, Forms, Calendar
o Operations on phpadmin - database
o Billing
o Scheduling

5. View Events
o PHI view/import/export/print
o Billing info
o All reports

6. Backup and restore

7. Emergency access

8. Communication events  wherever appropriate

9. Other security administrative events

**Technical requirements**

1. The list of events that can be audited can be made configurable with different log levels (minimum log level – maximum log level) based on which the logging can be done.

2. Actual logging can be accomplished by a common function. All the modules only need to send the appropriate messages to that function with the required info and the log level.
3. By default, read access to the logging should be prohibited for all users. Only the privileged users can view them.

4. The logging details can be stored in a separate table and the content of the logging are:
• Date & Time
• Type of the event (login, logout, view, add, delete etc)
• ID of the user who caused the event
• Workstation that initiated the event
• The module that created the event(patient, billing)
• Status of the event (NORMAL, MINOR,MAJOR, CRITICAL, FATAL)
• Description of the event (it can vary depending upon the log level)
• Md5 digest of the event (for operation like addition, updation and deletion)

5. Audit trial GUI can contain the following formation
• From Date & Time – Calendar format
• To Date & Time – Calendar format
• Username – Combo box
• List of events - Combo box
• List of status types – Combo box

6. Once the selections are made and the submit button is pressed, the relevant log information can be displayed based on the time window

7. Irrespective of log level, all the details should be logged during the emergency access
Qns: How long we need to keep them? If more number of events are chosen to be audited and log level is set to high, the log database would grow to a larger extend.

Do share your views here.

Thanks
ViCare Team

cfapress wrote on Tuesday, September 15, 2009:

Logging is always a tricky thing. "How much to log?" is the toughest question to answer.

Given that hard drive space is cheap I’d suggest logging everything forever. But I also realize that this results in tables that are just too big and cause the database to slow considerably. Proper table indexing helps greatly and would keep the log table running smoothly for at least a million records.

But once you cross some magic number of records, the table will likely perform badly.

I suggested at one point to offer a "log archive" option. Simply put, this would be an Admin-only option and would move records from the LOG table to the LOG_ARCHIVE table. Both tables would be used when examining the log but only the LOG table would be used in day-to-day operations.

It’s a simple fix to a potential juggernaut of a table.

Jason