Audit report(s) (MU2)
From OpenEMR Project Wiki
Overview
MU Requirements
Per ONC
- Taken from ONC Final Rule:File:2014 Edition Cert Federal Register.pdf
(3) Audit report(s). Enable a user to create an audit report for a specific time period and to sort entries in the audit log according to each of the data specified in the standards at § 170.210(e).
Per ONC/NIST Final Test Methods
Status
Analyzed by Columbia HIT Certification Class
Proposal
- By Columbia HIT Certification Class:
- Record the exit date and time
- Enable audit of unique patient identification
- Enable audit of all users of the system
- For user events, instead of displaying the SQL query string, the audit report should parse out individual, important elements
- Full Analysis: File:Audit Proposal.pdf
- Feedback on above proposal:
- Above is a nice and complete dissection of the requirements.
- Patient id and user id can be audited separately (see Patient and User selections at tope of report). Also can sort by these if click on top of the columns of the report.
- Can sort by date/time by clicking at top of column of the report.
- Here is a nice article dissecting this requirement: http://healthcaresecprivacy.blogspot.com/2012/09/meaningful-use-stage-2-audit-logging.html
- Brady's preliminary thoughts using above analysis:
- Three issues here to deal with:
- 1. The access and exit date/time stuff. Unclear where that came from. All I can see is the date and time of event. If need to really have an access and exit, then would need to sandwich the event with a log call before the event (this would create the log item with a pending flag) and then a log call after the event (would update the prior log item to complete, add exit timestamp, and set the success flag). My initial thoughts after reading the testing scripts is that this is not needed (ie. just an access date/time is needed).
- 2. It appears there is wordage that "copy" and "print" of things will need to be logged. If so, will need to incorporate logging into many of the button clicks within OpenEMR.
- 3. I think the toughest issue to deal with will be "specifying any changes made (with pointer to original data state) and a delete specification (with a pointer to deleted information)". Thus whenever do a update, insert, delete, replace will need to get the original data and store it (may need another log_data table) and place the pointer to it within the log item. That will be likely be rather expensive resource wise.
- An example would be that a "DELETE FROM "... query would get substituted to "SELECT * FROM "... and then would convert those elements into a json array perhaps and plop it into the log_data table in a data column (and id column of it would then get stored in the log table).
