OpenELIS Vietnam Progress Update

Here's an update of our progress on the development of the requirements for the Phase I milestone of OpenELIS in Vietnam.  The first two major foci of the Phase I deliverables are now at the point where they are ready to be shared with project stakeholders.  A development/demo site has been installed at the following URL:

https://openelis-dev.cirg.washington.edu/VN_APHLOpenElis/

(For access credentials, contact Jim Sibley)

The Phase I deliverables that are featured in this instance of the application are:

• Inclusion of batch specimen entry screen, allowing quick data entry for multiple specimens

• Inclusion of label printing functionality both outside and within specimen entry screens

The remaining Phase I deliverable is still currently under development:

• Modifications to individual specimen entry, i.e. limiting data entry screen to one page, allowing specimen rejection during specimen entry, etc.

Further, the effort to map the Vietnam test catalog to LOINC is continuing and very close to being complete.  Also, the deployment guide for OpenELIS Vietnam has been updated with a lot more content thanks to the diligent work of Reshma Kakkar.

OpenELIS Vietnam Progress Update

Here's an update of our progress on the development of the requirements for the Phase I milestone of OpenELIS in Vietnam.  As a reminder, the focus of the Phase I deliverables is in these three areas:

1. Inclusion of batch specimen entry screen, allowing quick data entry for multiple specimens
2. Inclusion of label printing functionality both outside and within specimen entry screens
3. Modifications to individual specimen entry, i.e. limiting data entry screen to one page, allowing specimen rejection during specimen entry, etc.

Integration of the first two of these goals is still continuing and is close to completion.  A demo site will soon be available showing off these new features.

Additionally, considerable work has been accomplished on getting the Vietnam test catalog completed and mapped to LOINC (with many thanks to Jerry Sable for his expertise and contributions).  It will soon be ready for integration into the Vietnam version of OpenELIS.

Finally, initial steps have been taken in development of a deployment guide for OpenELIS in Vietnam. A rough outline has been put together and discussions around content have begun.

OpenELIS Vietnam Progress

Here's an update of our progress on the development of the requirements for the Phase I milestone of OpenELIS in Vietnam.  The focus of the Phase I deliverables is in these three areas:

1. Inclusion of batch specimen entry screen, allowing quick data entry for multiple specimens
   
2. Inclusion of label printing functionality both outside and within specimen entry screens
3. Modifications to individual specimen entry, i.e. limiting data entry screen to one page, allowing specimen rejection during specimen entry, etc.

Development of the first two of these goals is mostly complete at this time, although there is still work required to integrate the new functionality into the existing code.  The third goal, individual specimen entry modifications, has not been started yet, but some of the work done for the batch specimen entry will be directly reusable for individual specimen entry, i.e. specimen rejection functionality.

Once the batch specimen entry and label printing functionality are fully integrated, we will make a demo version of the code available so that we can start collecting feedback on the progress made so far.

We will attempt to make regular progress updates on this blog fortnightly to keep everyone informed on the development status.

What makes things interesting - Dates

This will be the first in a series of blogs about some of the issues we run into when we are developing OpenELIS.

Before you read any further think of three different ways you can write the date of July 25th, 2012 for a French speaking audience.

Just to show off I'll give you four ways:

25-07-2012
25/7/2012
25 juil 2012
25 juillet 2012

These are all understandable by French speakers, or English speakers who know a little French (C'est moi). The problem is to make them understandable to OpenELIS.

We had a recent bug which was caused by a change in the date format of one of the analyzers we support and the fix was to have OpenELIS understand both the original format (25-07-2012) and the new format (25 juil 2012).

The programming language we use for OpenELIS, Java, has very good support for figuring out what the date is but you have to tell it what the format is first.  For instance, for the original format you would tell it that the format is the day followed by a dash followed by the month followed by a dash followed by a four digit year.  If you gave it 25/7/2012 it would not know what to do.

The format for 25-07-2012 is day-month-year
The format for 25 juil 2012 is day abbreviated month year

The first job is to figure out which date format has been sent by the analyzer, there are a couple of different ways to do this but the easiest is just to see if the date has a '-' in it, if it does then it is the original or if it does not then it is the new format.

That was easy.  But it still doesn't work for the new format.

We know which format to use but Java still can't understand '25 juil 2012'.  The reason is that Java thinks that 'juil.' is the French abbreviation for July, not 'juil'.  The extra '.' makes all the difference in the world.  That's not hard to fix, we can just add a '.' to the month and now Java is happy.  It will be able to handle the date which was causing the problem and everything should be good.  Until next March, the abbreviation for that month is 'mars', with no '.' at the end.

Fortunately that is not a hard fix and we didn't have to wait until next March to discover that only some months have a '.' at the end of the abbreviation.

Dates are very hard to get right, it is one of those things that are relatively easy for humans and very hard for computers.

After all we all know 05/10/2012 means, except that I'm not going to tell you if it was for a French speaker or an English speaker.

  

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!