Our users at Retro-CI alerted us to a bug that needed an urgent release from us to patch.
The bug originally appeared as though when a user accepted CD3 and CD4 results automatically imported from an analyzer, only the CD4 results then appeared in the biological validation screen. Normally all accepted results should then appear in the validation screen after acceptance by a technician. When the user checked the manual results entry screen, the already accepted CD3 results appeared on that screen ready for results entry, but with the imported value already entered. To solve this problem and get the results to show up in validation, it initially appeared that the user would need to select a checkbox to flag as "analyzer result". Once this checkbox was checked for this rogue result, the result suddenly appeared on the biological validation screen. Since checking this box led to the result suddenly appearing in the proper spot, the assumption that this was the behavior that fixed the problem with the result.
However, sometimes when an outcome is the desired result, it is easy to believe the last action taken caused that result -- like superstitious beliefs -- so you repeat that action again and again hoping for the same outcome. Like throwing spilled salt over your shoulder to make good things happen in life, users will continue to interact with software in a certain manner believing that it makes the software work in a certain way. In troubleshooting bugs, it's also easy to focus on some user action as the fix (or the cause) of some outcome and sometimes make it difficult to determine the true issue at hand.
In this case, we knew that the fact the result got stuck in results entry rather than moving to validation step had something to do with the "state" of the test result. As samples move through the workflow in OpenELIS, the software keeps track of the status or state of the sample, the tests ordered, and the results of those tests in the workflow. So when a test result first enters the system, it appears as a state of "not accepted by technician". After the technician accepts the analyzer import of the results, those results change to a state of "accepted by technician". Only those results with a state of "accepted by technician" will appear in validation.
We could see that once a technician accepted the result, the state for the CD3 results did not change and still showed "not accepted by technician" - even though we knew for a fact that it was. We knew from the bug report that users believed that the actual clicking of this checkbox was what was changing the state to "accepted" so it would move into validation. But after some troubleshooting, we realized that it was actually the changing of the record within the results entry screen that triggered the state change. That could include checking the checkbox, changing the results value, or anything on that results entry screen would cause the record to be updated upon saving and thus trigger the state change. So it was superstitious behavior because the checkbox really had nothing to do with the state change.
As an additional note of the troubleshooting, we realized it wasn't only with CD3 results, but users only saw this because CD3 was always 1st on the list of the results and it was this that was the actual bug. Any result that was 1st on the list of results would not change state, so we fixed this as well.
And with that, we released OpenELIS\Global v2.7.3.
No comments:
Post a Comment