A LabWare LIMS Developer’s Guide to Supporting an Existing System
Supporting a LabWare LIMS implementation often can be a technically challenging affair, especially as a new person on-boarding with an existing LabWare project. If documentation for your LabWare system is lacking, figuring out the appropriate solution can be a difficult task.
The word appropriate is emphasized because usually there are multiple ways to solve a problem, but special care must be taken to arrive at the best solution.
The best solution is defined by the factors of the environment in which an issue is found. Variables like cost, frequency of occurrence, and complexity of the issue can play into what the most appropriate/correct solution would be. Below is a methodology for arriving at the best, most appropriate solution.
Observation And Understanding
The scientific method begins with observation, as does proper issue resolution of your LabWare LIMS. Observing the issue as it’s happening is the best way to confirm that it is actually occurring. However, this isn’t always possible. Luckily, LabWare has an extensive auditing system that makes checking the audit table the next best alternative. When investigating an issue, it’s critical to ensure that the audit history corroborates the user’s account of what caused the issue. LabWare implementations can often have processes occurring in the background so the issue may not be the direct result of the user’s actions.
Once an issue is observed, the next step is to understand why it occurred. Looking into the code and debugging an issue will normally provide a one-dimensional answer as to why something is not working as expected. For example, if a lot process (e.g., any LabWare process that involves Lots) expects only lot templates A, B, or C, but a user tries to use lot template D, the system will likely throw an error. The solution shouldn’t be to modify the system immediately to allow the user to use lot template D. The user should be asked why they are attempting to use the template. The solution will depend on their response. If they didn’t know any better, than it’s likely a training issue. However, if a new process in the lab exists and template D is needed, then perhaps the system will need an update so that template D can be used.
Communication is key. Asking questions and understanding why an issue occurred is a critical part of issue resolution. Answers to the questions like “How often does this issue occur?”, “Who will be affected after making this change?”, and “How much value does this provide the business?” can play into whether or not the issue is worth resolving. Remember, as support, you’re here to enable the user to do their job by fixing issues, and through communication, they enable you to do your job.
Replicating And Testing
If a code defect truly exists in LabWare LIMS, it is important to replicate the issue in a lower environment. There are multiple reasons for this step. First, many production environments (especially regulated pharmaceutical environments) have rules against nonlab technicians making changes directly in production. This can make replicating the issue in production a nonviable option. Second, replicating the issue in a lower environment demonstrates an understanding of the root cause and can be useful proof that the issue has been resolved in a lower environment. Moreover, for someone who is learning a particular LabWare system, setting up the data to replicate an issue allows you to get a better understanding of the system you’re supporting.
Finally, once the solution has been developed in a lower environment, if the change affects existing functionality, then regression testing is absolutely necessary. Complex systems often can have unexpected dependencies and making changes to resolve issues may cause more issues without the proper system knowledge. It’s for this reason that having access to system documentation is paramount. When access to system documentation is unavailable, it is expected that you create your own as you work on the system.
Presenting Potential Solutions
When the resolution to an issue in LabWare LIMS is complex and there are multiple possible solutions, it can be helpful to involve the user. It’s necessary to clearly lay out the pros and cons of each possible solution and to anticipate any questions they may have. When laying out multiple options, don’t be afraid to cast your vote as to which option is the best and to give reasons why. This is helpful to the decision makers when they are not as knowledgeable about the system.
When the LabWare user is involved, it leads to fewer surprises when the time comes to import the changes to production.
Provide The Best Solution
In brief, when supporting a LabWare LIMS it is essential to have the mindset of trying to provide the best possible solution. This mindset forces you to ask the question of whether what you’re doing is in the best interest of the LabWare system as a whole. Quality matters in complex systems and pays dividends in the long run.
