Improving User Experience: The Audit Trail

In August, we finished initial work on a new OpenELIS feature: the Viewable Audit Trail. Jan wrote about the Audit Trail, explaining the impetus and the first phase of development. In short, it came out of discussions with our colleagues in Cote d'Ivoire about ways to better troubleshoot problems, both with samples and the OpenELIS system itself.

As part of an on-going process to improve the OpenELIS user experience, I've been thinking about how to best implement some features that will make the system easier to use and give users faster, more intuitive ways to get their work done. So as part of rolling out the Audit Trail, I took the opportunity to use it as a test case for some new features.

A picture can say a thousand words, so here's a quick comparison of the "old" and "new" versions:

Old Audit Trail

New Audit Trail

We've done a few things here:

• Added summary information at the top: the order/accession number, the date it was created and the current status.
• Just below that is a new row with tools for sorting through the audit trail. It shows the number of "entries" in the database and allows for filtering through the entries by searching of by selecting a category. Very useful for an order that may have hundreds of rows in the database.
• The table itself has a new, more modern look and can be sorted. 

If a picture is worth a thousand words, surely a video is worth even more. Here's a short screencast that shows these improvements in action.

We know OpenELIS users have a lot to do. All the user experience (UX) improvements are intended to the user's goal (in this case, understanding where a problem may have occurred) easier, faster and, dare we say, more pleasurable experience. We hope that being able to parse through tables more quickly and getting better feedback from the system will lead to significant saving in time spent per order and a reduction in the error rates.

We're making all this happen by employing some new and powerful software frameworks. The new Audit Trail UI relies on:

• jQuery - an open-source Javascript library that has all sorts of tools for "client-side scripting". That simply means being able to do things on screen after the page is loaded. For example, changing the sorting order of a table.
• DataTables - an open-source jQuery plug-in that handles the interactions to the HTML table.
• Bootstrap - an open-source CSS framework from the good folks at Twitter. It's a flexible and efficient way to build UI elements in web apps that work across all major browsers.

The updated Audit Trail will be part of the next set of OpenELIS releases. And the UI will soon be applied to other sections of OpenELIS.

As always, please let us know if you have any thoughts or questions.

- Mark

Viewable Audit Trail

In our current development iteration towards an unscheduled release of OpenELIS 2.7.1 and scheduled release 2.8, we have focused development over the last couple of weeks on two very important scopes of work:

• 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

[* indicates those events that are not currently being tracked and/or displayed in the audit trail for this release.]

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:

Next phase of development for 2.8

• 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!