Difference between revisions of "Audit report(s) (MU2)"

From OpenEMR Project Wiki
Line 31: Line 31:
:::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.
:::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.
:::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).


==Owner==
==Owner==

Revision as of 09:33, 11 January 2014

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

See here: http://www.healthit.gov/policy-researchers-implementers/2014-edition-final-test-method

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
Brady's feedback on above proposal:
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).

Owner

Columbia HIT Certification Class

Links