Audit & Access Logs

system · July 14, 2009, 3:26pm

anonymous wrote on Tuesday, July 14, 2009:

I am writing regarding the Audit & Access logs in the latest version of OpenEMR. From what I have seen in other programs comapred to the audit’s in OpenEMR they are not detailed enough, all it logs is views of encounters but not anything within the encounter or any other access within the patient or other things changed and viewed in the program and it doesn’t log when one of my staff members searches for a patient, which could lead to people looking at family & friends even basic info without opening the record and even if thy did it only logs Encounter Views in general. As for the actual Access Controls those are excellent but the logs lack in detail, ie. if a staff member searches John Doe’s record I should be able to see that search and then if he opens that patient’s record I should be able to see that, then I should be able to see what encounter he opened and what they may have changed/viewed within the encounter. I was told by Sam Bowen, MD to put this in here with the hope that this will trigger a placement of my request in the SourceForge bug tracker. Thank you.

system · July 14, 2009, 3:52pm

sunsetsystems wrote on Tuesday, July 14, 2009:

Yes the logging system needs a complete overhaul. As it is, it does a very poor job of telling you who did what, when.

Rod
www.sunsetsystems.com

system · July 16, 2009, 7:13pm

drbowen wrote on Thursday, July 16, 2009:

Tony,

I think this would be good for the "new feature request". There is a lot that would need to done to fix this and it is more than just a "bug".

Sam Bowen, MD

system · July 16, 2009, 10:49pm

tmccormi wrote on Thursday, July 16, 2009:

I agree. We’ve already added encounter level authorization to the log, but it is a total hack. Logging is well described in the CCHIT cert list. I’ll pull that into a Requirement/Spec and post it for feedback…

Tony

system · July 17, 2009, 1:01am

tmccormi wrote on Friday, July 17, 2009:

This is what is listed as not passing the CCHIT Certification Requirement for Audit (per ViSolve’s report) and my additions of technical reference. Open for comments…
–Tony

1. The system shall allow an authorized administrator to set the inclusion or exclusion of auditable events based on organizational policy & operating requirements/limits.

2. The system shall support logging to a common audit engine using the schema and transports specified in the Audit Log specification of IHE Audit Trails and Node Authentication (ATNA) Profile.

* http://wiki.ihe.net/index.php?title=Audit_Trail_and_Node_Authentication

Example message format
<AuditMessage>
    <EventIdentification>
    <EventActionCode>
    <EventDateTime>
    <EventOutcomeIndicator>
    <EventID code>
    <EventTypeCode>
</EventIdentification>
<AuditSourceIdentification>
    <AuditSourceTypeCode>
</AuditSourceIdentification>
<ParticipantObjectIdentification>
    <ParticipantObjectTypeCode>
   <ParticipantObjectIDTypeCode>
   <ParticipantObjectName>
</ParticipantObjectIdentification>\n");
</AuditMessage>

3. The system shall be able to detect security-relevant events that it mediates and generate audit records for them. At a minimum the events shall include those listed in the Appendix Audited Events. Note: The system is only responsible for auditing security events that it mediates. A mediated event is an event that the system has some active role in allowing or causing to happen or has opportunity to detect. The system is not expected to create audit logs entries for security events that it does not mediate.

4. The system shall record within each audit record the following information when it is available:
    1) date and time of the event;
    2) the component of the system (e.g. software component, hardware component) where the event occurred; (
    3) type of event (including: data description and patient identifier when relevant);
    4) subject identity (e.g. user identity); and
    5) the outcome (success or failure) of the event.

    * The step here is to identify what events need logging and implement the use of a common audit class method in all actions where it is configured to happen in item 1.

5. The system shall provide authorized administrators with the capability to read all audit information from the audit records in one of the following two ways:
1) The system shall provide the audit records in a manner suitable for the user to interpret the information. The system shall provide the capability to generate reports based on ranges of system date and time that audit records were collected.
2) The system shall be able to export logs into text format in such a manner as to allow correlation based on time (e.g. UTC synchronization).

6. The system shall be able to support time synchronization using NTP/SNTP, and use this synchronized time in all security records of time.

7. The system shall have the ability to format for export recorded time stamps using UTC based on ISO 8601. Example: "1994-11-05T08:15:30-05:00" corresponds to November 5, 1994, 8:15:30 am, US Eastern Standard Time.

8. The system shall prohibit all users read access to the audit records, except those users that have been granted explicit read-access. The system shall protect the stored audit records from unauthorized deletion. The system shall prevent modifications to the audit records.