- Creating a viewable audit trail of the order and sample/specimen events
- Fixing a long-standing ever-elusive bug that has consistently been very disruptive to end users (users only see the message "It's not your fault")
Viewable Audit Trail
We've known for awhile that it would be helpful for administrators and users to be able to view all of the events that have occurred for patient samples. In January we started talking with our colleagues in Cote d'Ivoire about how this feature would assist them in their troubleshooting any issues that cropped up during the use of the software. After our most recent trip last month, it was clear that this was the most important next feature to add to OpenELIS. Many times users will report a problem with the software, but the system support team has no way of determining whether this was actually a system error that caused the problem, or if the state of the order/sample/test is actually different than the user expected because of the way that the user has interacted with the system. We were told by users in the lab that these types of things are causing the majority of their work, so we hope that this feature will provide a big improvement to reducing this workload.
First phase of development for 2.7.1
The first phase of development includes the following:
- Researching all of the events that should occur and making certain that they are being added to the log in the database. Events for orders, samples, and tests should include the following
- Order creation (Sample Entry)
- Patient creation (Patient Entry)*
- Any changes to the patient information (demographics, medical history, etc.) *
- Status changes for an order (created, testing started, testing finished)
- Adding or removing samples from an order *
- Adding or canceling test requests from a sample in an order *
- Status changes for a test request (not started, test canceled, technical acceptance/rejection, biologist acceptance/rejection, result finalized)
- Nonconformity events for orders or for samples
- Addition of notes *
- Referrals to other laboratories and the receipt of those results *
- Patient reports generation
- Developing the code to access all of the events currently being captured
- Developing the code to group these events into a "trail" that would make sense to a user
- Developing the basic user interface to view the audit trail
What we found -
- We unfortunately found that not all of the events were being captured! So we are fixing this.
- For some of the update events, only the old values were being captured - not the new updated value. Not very helpful to have only the old values, so we are fixing this for those events already being recorded. We won't be able to reconstruct the data for previous events, but in going forward this will work correctly.
- We discovered we need to have a role available for system administrators to be able to configure user permissions to view the audit trail. Each installation may not want all users to be able to view this audit trail. We implemented and simply called this new permission 'Audit Trail'.
Current view today on our development server:
- Coding for the events that are not currently being capture or displayed. Those events in the list above with the asterisk (*).
- Improve the user interface to make the trail more readable to the user, including, making the table sortable by the user and filtering for types of events
- Possibly some of the feedback we receive from the first users of 2.7.1 (Retro-CI!)
Future development for X.X?
Eventually we would want to implement as part of the QA dashboard and include reports that might indicate potential issues in the events. Secondly we want to display the tracking data exchanges between systems, such as, aggregate reports between clinical and reference laboratories, patient demographic queries to a master patient index or other system, electronic results reporting, etc.
But that's in the future!
No comments:
Post a Comment