...
Unlicensed user, Unlicensed user, Unlicensed user Unlicensed user
Further Discussion
On May 30, 2013, during Q&A with Wyclif, we reviewed the functionality of his auditlog module and the possibility of using it instead of our current method of maintaining audit log information in each record. We identified the discussion points below. Because we expect tomorrow's meeting will be preoccupied with GSOC, we welcome discussion here. The main goal for tomorrow's meeting will be to identify potential show-stoppers, to address comments and questions raised during discussion, and to decide whether it would be a good investment of resources to run a performance test of the new proposal.
1. What is the purpose of auditing? What do we expect to gain by changing?
Auditlog records who changed data by maintaining a table of date-time, user, table, field, old value, new value. It needs some modification to include newly added and deleted records. Field values are serialized. It might be possible to record only old value or only new value with same effect.
a. Improve performance by eliminating 3 indexes per table
b. Be able to find out who made a particular change
c. Meet FDA requirements for clinical trial data??
d. Meet HIPAA requirements for auditing access??
e. Not replace native DB transaction logs or backup procedures
2. What is the architecture of auditlog and how would it integrate with existing code/modules?
It is a Hibernate interceptor, as are (1) core audit logging; (2) synch module; (3) event module. Since many important events are DB updates, there is a lot of common functionality that could be factored out and help us move toward an event-oriented model. Some possibilities:
a. hibernate interceptor generates events and event module publishes them to which centralized auditing and synch subscribe;
b. hibernate interceptor includes centralized auditing which raises events to event module for others to subscribe.
For performance reasons, we should consider giving auditlog its own connection to the DB (not through Hibernate?), which may be a different DB than the OpenMRS DB.
3. Are there DB changes which would not be logged?
Anything that did not go through Hibernate. Anything that is not an OpenMRSObject.
a. Core SQL method -- uses Hibernate, but do they trigger the interceptor?
b. Liquibase -- can it be configured to use Hibernate? what about structure changes? do we need to keep table version?
c. Direct manipulation through MySQL or other DB session -- at startup, compare each record update time with last logged change??
d. Initial startup -- it would take days to copy the initial contents of the DB, probably a show-stopper
4. How could we test centralized auditing?
Install an MDS package under both scenarios and compare times
a. Modify auditlog to reflect discussions.
b. Write liquibase change sets to remove indexes and not-nulls from audit fields (big task, could be helped by automation)
c. Modify Hibernate XML to remove relationships from audit fields
d. Disable the hibernate interceptor that updates audit fields
e. Locate uses of audit fields -- duplicate checks? voiding an encounter? -- and make sure they won't break if fields are empty
Estimated time: 1 week