New LNSP Software Update: Release 1.5

1. Specimen Rejection (NonConformity)feature - This new module allows users to reject a specimen and remove it from the sample processing workflow.  Users can indicate why it was rejected, which department it was rejected in, and who authorized the rejection.

 

First of all, you’ll find a new menu item for NonConformity:

When you go to the NonConformity page, you will see a field to enter the accession number of the sample you want to mark as Non Conforming.

If the Order Number already exists in the system because a test request was entered through the Sample Entry page, then you will see any existing information as seen in the screenshot below:

The patient information and site information is displayed.  If the sample has not been registered in OpenELIS, however, you will be able to enter the basic patient and site information (see below):

In the table below the patient and site information, the reason for rejecting the sample can be chosen for a list.  The type of sample, section and Supervisor name can also be entered.  The note field can be used to record any relevant information pertaining to sample rejection.

To remove cancel the rejection of a sample, a user can select the “Suprimer” button on the left and save the page.

2.  Sample Entry form updates:

                    a.  Required Patient Fields Changed – The sample entry page has changed to support the workflow at LNSP.  Now, on the sample entry page, the patient id is required.  No other patient information is required.  On the sample confirmation page, however, users can enter samples without any patient information.

Below is a screenshot of the patient section of the Sample Entry page.  You will see that a patient is always required.  Specifically, the patient id field must be complete as indicated by the red asterisk (*).

             b.   No longer needed to press ‘assign’ button to add tests – On the Sample Entry page, if you select or deselect test checkboxes, the appropriate tests will automatically be assigned to the sample.  Before, a user had to press the “assign tests” button.  This step has been removed thus simplifying the data input process for the user.

In the above screenshot, you can see that the checked tests were automatically assigned to the specimen.  There is no extra step to press a button.

            3.  User Manual Added – A main menu item, called “Help” has been added to the far right with a pdf version of the LNSP User Manual.  This will serve as a reference guide for users.

OpenELIS Global now on Twitter

You can follow our project through twitter at http://twitter.com/openelisglobal

As we complete tasks in the project planning software tool that we use, PivotalTracker, a tweet will automatically be sent out to update followers.   You can also directly view our PivotalTracker project at https://www.pivotaltracker.com/projects/18030#

New OpenELIS LNSP and Clinical Releases Provided

We’re happy to announce that updates for both the LNSP and the Clinical OpenELIS configurations have been provided to the Haiti team today.  We focused on improving the test configurations, reports, and referral and confirmation functionality.

The changes include the following:

• Type-ahead feature - Added a type-ahead feature to the Confirmation Sample Entry page for the referring site field.  Instead of just having a dropdown to choose the site, users now have the option to type the site name in the field.  The type-ahead feature will automatically suggest site names as you type.
• Sample type on results entry – Added the sample type to the results entry page.  Lab technicians can now see which sample type the test was run on when they are entering results.
• Patient report indicates if referred out – If a sample was referred out to another facility for testing, the patient report will now indicate that and include the external test results.
• French  – Improved French on several pages and on reports
• LNSP logo – Added a standardized LNSP logo to report headers.

Our next step is to define the requirements for aggregate clinical reporting at LNSP and importing historical data from existing databases.

Please pass along feedback and issues to John Wesley and Dimitri.  We welcome your input!

LNSP Release 1.3

We’re happy to announce that software Release 1.3 for LNSP has been packaged and provided to the Haiti team!  This update provides additional workflow support and expands reporting capabilities.

More specifically, the release includes the following improvements:

• Confirmation Test Requests
  

OpenELIS now supports confirmation sample intake.  A new sample entry page was developed which captures sample information specific to confirmation test requests.  This includes test results found at the sending site and contact information of the requester.

• Confirmation Report

In addition to the confirmation test request page, a report was developed to view all confirmation samples entered during a certain date range.  The report displays the test results of the sending site and LNSP’s test result for easy comparison.

• Data Export 

The ability to export test requests into a csv format was added.  This provides LNSP with reporting flexibility to create and design their own reports.

• Improved Test and Panel Configurations

More tests were configured in OpenELIS which means that the sample entry page now offers more tests.  Additional panels (grouping of tests) were also configured to make entry of test requests easier for the user.

• Improvements to the Referral Out Functionality
• The referral management page now supports the ability to enter more than one test result.
• The referral report layout was enhanced to make comparison of results between LNSP and the external site easier.

The Seattle team is excited to share this progress with you and we look forward to receiving feedback from LNSP users on this update!

LNSP Release – Feb. 28th

The Seattle team finalized development of the new LNSP reference lab configuration on Monday February 28th.  The software update was packaged and provided to the Haiti team who will be reviewing the software, followed by the installation at LNSP.  We are looking forward to receiving their feedback!

Because OpenElis configurations all use the same common code base, LNSP users will benefit from the software updates included in the Feb 14th Clinical release.   For example, the following  features that were included in the recent Clinical release are also included in this LNSP release:

• Ability to edit a lab order by adding or removing tests
• Reflex testing
• Ability to select more than one result for a single test

The new features developed specifically for the reference lab configuration are as follows:

Major Features

• Capture of Specimen Condition at Arrival – The condition of specimens can now be entered during sample entry.  This condition is then displayed on the results entry page to help users interpret test results.  For example, a blood sample may arrive at LNSP in a broken tube which may explain an abnormal test result.  Users are also able to enter more than one condition if needed.  For example, a tube might be broken and refrigerated.
• Ability to refer tests out to other labs – Users can now indicate that a test has been sent to another lab for testing and enter the referral test results.   A previous blog entry Referring Out, discusses this functionality in more detail.
• Ability to deactivate tests and edit tests – Through the permission-restricted Administration menu, users have the ability to edit and deactivate tests.  Deactivated tests will not be listed as an option on sample entry form or be listed in any dropdown list of tests throughout the application.  The ability to edit tests allows users to change the name of the test or assign it to a different department.

Other Updates

• The sample accession number format for LNSP has been configured to have  a prefix of  ‘lnsp’  For example, lnsp11000001
• The requesting site is now entered on the sample entry page and displayed on reports.

Next Steps

• Haiti team installs this new release at LNSP
• Seattle development team continues work on LNSP version for another release at the end of March – More on this later!
• Training materials and curriculum for a workshop are being developed for LNSP staff.

Haiti Clinical Release

We’re excited to be releasing a new configuration of the OpenElis software to be deployed in the Clinical labs in Haiti. The new features developed for this configuration are as follows:

• Ability to add multiple results for a single test
• Ability to edit a lab order by adding or removing tests
• Reflex tests for HIV Collodial Gold and Determine tests
• Ability to enable interoperability with iSante EMR, specifically allowing iSante to act as a Master Patient Index (MPI) by having OpenElis query iSante for patient demographics.  More on this topic later!

Our next steps include working with the in-country team on training and installation. We also are working to expand interoperability with iSante by developing a results and orders interface.  This work will be a good start for generalizing the data exchange mechanism in OpenELIS for interoperability with other EMR systems, such as OpenMRS.  In parallel, we are moving forward with finalizing the development for the Haiti LNSP lab configuration that will include reference testing, confirmation testing, external quality assurance, and reporting.

Referring out

There are times when a lab needs to ask another lab to to run a test for it. The lab may have run out of materials, an analyzer may be broken or the results of a test may need to be confirmed. The goal for the laboratory information system is to keep track of the request and to record the results when they come back. The basic work flow follows:

1. The lab technician recognizes that a test has to be referred out.
2. They mark the test as having been referred and why it is being referred
3. The personal review the tests needing referrals
4. They select which other lab will do the analysis
5. They select the tests they want the other lab to run. More than one test may be needed to confirm
6. The samples are sent to the other lab
7. The results are communicated back to the original lab and entered into they system

As always most of the work comes from handling the deviations from the normal work flow. How does a referral get canceled? If a referral does get canceled by mistake how is it uncanceled? If a test was requested by mistake how is it removed? How do we prevent a test being requested that needs a different sample type? For the rest of this entry we will follow the basic work flow.

Requesting a referral

A referral is requested from the results page.  That is where the lab technician spends most of their time and when it would become apparent that a referral is needed.

Referral Management

Referrals are tracked on their own page.  This is the central place for deciding where they should be sent and what tests should be run by the other lab.  Referrals will stay on this page until the final results are returned or when the referral is canceled.

On this page three tests have been marked for referral.  The first has already been referred out and waiting for results.  The second has been marked for referral but has not yet been referred.  The last one has been referred out with two tests, one of which has had the results returned and the second is still waiting.

The accession number, request date, sample type and the name of the test which caused the referral are given in the section above the editable part of the referral and are un-editable.  All other fields are editable at any time until the last result is entered or the referral is canceled.

So much more information, so little space

The age of the computer was suppose to clean the paper off of our desks. On good days it does. But all that information has to go somewhere and it has gone right in front of our faces onto a computer screen. What is in a paper logbook, taking up two logbook size sheets of paper, now has to fit on a 19 inch screen.

We were doing pretty well but have recently started supporting referring samples out to other labs to do tests which were inconclusive or unable to be done within the lab. We decided that the best place to decide to do the referral is on the results page. That is where the lab technicians spend most of their time and where they would become aware that an outside lab was needed for a conclusive test. We added two more columns to results page, one for indicating that the test should be referred and the other to give the reason for referral.

The bulk of the work with referrals, who it is referred to, what tests were run by the referral lab, who requested the referral, when the results were reported back and what the results were are on a different page.

The redesigned results page has moved the accession number and the patient information from the left of the results entry to a line above the results entry and allows the more of the page to be used for results entry. We have also removed the radio buttons for labeling the analysis as having been done manually or by an analyzer. They have been replaced with a checkbox to label the test as having been done by a analyzer. If the checkbox is not checked then by default the analysis is labeled as having been done manually. As with many features of OpenELIS the use of the new layout and the ability to refer tests to outside labs is a configuration setting.

The redesigned results page with referring enabled

The writers delema, to much writing to write

The past few months of have been spent expanding OpenElis and the urge to finish “just one more feature” has put writing about what we have done on the back burner. The urge to finish the features is still there but so is the need to let people know what is going on. I’m going to go touch on some of the new features, if you want more details feel free to contact us.

Observation History

A laboratory information system should not be the primary repository for patient demographics. In an ideal world a patient’s records would reside in medical records system attached to their primary health care server but sadly we do not live in an ideal world and a clinical lab may indeed be the a persons main point of contact where records are kept. There is some information about a person which does not change, their gender, their birth date etc. There is other information which does change over time, such as what other medical conditions they may have, what medications they are taking or their weight. We can now capture that information in OpenELIS.

Reporting

Originally the reporting portion of OpenELIS had been done through an open source application called OpenReports. OpenReports solved many problems, it is a well written and flexible package which added a lot of capacity with relatively little effort. The major drawback is that it is a separate application and communicating between OpenELIS and OpenReports is a weak link. We also found that it was confusing for users to be in one application, OpenELIS, and all of the sudden find themselves in another application, OpenReports. We are slowly moving our reports out of OpenReports and expect to have that completely done by the end of the year. The new reports will be able to take advantage of the search capacity within OpenELIS, such as search for a patient by name, ST Number or National ID. This is also the direction that the domestic US version of OpenELIS has taken so we will be in line with their practices.

Integrating with Analyzers

The integration of a LIS with analyzers is a major challenge. Interfacing with any hardware device is difficult and interfacing with a hardware device which you don’t actually have access to is even more difficult. The path of software development is to specify the requirements, write the implementation and then find if the implementation meets the needs of the problem. For analyzers all of the steps are difficult, each type, model and version of an analyzer has different requirements and the manufactures are not always willing to share the specifications with open source providers. Implementing the requirements is almost impossible without access to the analyzer itself. In the bad old days of software development software engineers would write programs, hand them to a person behind a desk who would then try and run the program sometime in the next couple of days. If there were any bugs the person behind the desk would give you the printout and you would try and fix the bug, give the program to the person behind the desk again and wait a few days to find if you had fixed it. Without the analyzer that is what it is like to develop an interface for the LIS, except that you are interrupting the work of the lab to see if what you wrote works. We have taken a much more modest approach, most analyzers are able to export their results to a file and we have written the software which will import those files into OpenELIS

Modifying test requests

This has been a long requested feature for our version of OpenELIS and we have finished the work. So long as a test has not actually been done it can be canceled and additional tests can be ordered after the original sample had been entered into the system. The domestic version of OpenELIS also has this feature but it had not been integrated into the global workflow.

Reducing the complexity of the Administration view

Sometimes removing features is a step forward. When we did the administrator training we found ourselves cautioning against changing some of the settings. We finally took the obvious step and removed the ability to change those settings.

Upcoming new features

One of the harder tasks in OpenELIS is adding new tests and configuring the correct result limits, panels and reflexes. It is an error prone process and several OpenELIS implementers are working on solutions. Because we want all of our meta data changes to happen through Liquibase, so we can track and reapply the updates, we will be building a tool which will take the test specification from a template and generate the correct Liquibase files. The goodness of this is that the domain experts will be able to state what the tests they want in a way they understand and the result will be a file that will allow us to apply those changes to all of the implementations that need the new test.

Most of the development team will be traveling to Cote d’Ivoire for a few weeks and when we return the focus will be on finishing up the work for the Haitian LNSP facility as well as finalizing the tests for the clinical version of OpenELIS.

I hope you all had a good summer and are looking forward to a gentle Autumn.

Testing test reflexes

It’s not unusal to go to a doctor and have them say, “We have the results of your last test and we are going to have to run more tests” or “Based on the results of your tests we think you have X but we can run some more tests.” This senaro is simular to what may happen in a lab. The results of some tests may mean that another set of tests need to be run, the sequence of tests is called a test algorithm and in OpenELIS it is implemented as a test reflex.

In it’s simplest form a test reflex decides that, based on the outcome of a test, another test should be run.

Needless to say, it can get complicated.

• What if the test reflex action is re-running the same test? How do you know not to run the test a third time?
• What if requesting another test depends on the outcome of more than one other test?
• What if the response to running a test is to request two other tests?
• What if the response to the outcome of a test, or two tests, is that a conclusion should be drawn such, as the patients HIV status is HIV-D?
• What if, for a given outcome of a test, the lab technician can either indicate that more tests should be requested or that a conclusion can be drawn without any more tests?
• What if somebody wants to know the sequence of tests run to reach a conclusion?

Being a good blogger I would not bring this up if I was not going to mention that we have expanded on the existing capacity for test reflex already in OpenELIS to support the extra complexity.

We do not have a use case for looking at the results of more than two tests to decide if another test should be run but the solution we developed is extendable to any number of determing tests and any number of requested tests.

The key concept we added was to mark test reflex as sibblings, if the conditions of one test reflex are satisfied then the sibling test reflexes are also checked to see if they are satisfied. If they are satified then the reflex actions are triggered, which can be either to add one or more tests, draw a conclusion from the outcomes or to send a message to the lab technician and have them decide what action should be taken.

The cost for the added complexity in behavior is added complexity for setting up the test reflexes. The rules for setting up the desired behavior are not extreamly complicated but nor are they extreamly obvious. We have added notes to our internal developers FAQ which spell out the rules which we would be happy to share with any other parties. Fortunally for the labs we are implementing OpenELIS versions we are doing this work for them, and thanks to the use of Liquibase we can easily add test reflexes to existing deployments.