6-steps to update your Laboratory Information Management System (LIMS) User Requirements Specification
Feb 17

6-steps to update your Laboratory Information Management System (LIMS) User Requirements Specification

A bonus article as an addition to our ‘Choosing a LIMS’ series to help keep your chosen system up-to-date. In a recent survey an amazing thirty NHS Trusts stated that they either do not have a LIMS User Requirements Specification (URS) or that it hasn’t been reviewed since its last upgrade. You need your User Requirements Specification (URS) to validate your Laboratory Information Management System (LIMS) and ensure that it’s fit for purpose.

If you don’t know what you need your LIMS to do, how can you check whether it’s succeeding?

It’s also an area that inspectors from regulatory bodies such as the MHRA and Human Tissue Authority (HTA) are increasingly focusing on. So, you should try to get your documentation in order before your hand is forced by an upcoming inspection. You’d then be under so much more pressure!

Finally, your department could make some big efficiency gains as well as proving compliance and reducing risk to patients. So, let’s make a start.

1.   Find and review the LIMS User Requirements Specification (URS) documentation you already have

You might already have a URS for your LIMS, albeit out of date. If you do, this is the perfect starting point. If you don’t have a starting point,  then don’t worry. It just means that, although you’ve got more documentation to do, nothing’s out of date and it will all be completely fresh.

Your department should have at least some existing business process documentation such as:

  • Standard Operating Procedures (SOPs)
  • Lab process flow charts
  • Training guides
  • Staff induction documents

And, of course, the processes that are locked in the heads of your team! This is all good material to get you started.

2.   Assess your processes and compare with your URS documents

Your first job covers to get a clear understanding of what your department does. Consider its inputs, outputs and what it does to turn the former into the latter. You can then document what you currently do day-to-day to carry that out.

Now compare this against your existing LIMS URS documentation. You might be surprised at just how out-of-date those User Requirements Specification documents are, meaning that it’s a good job you’re doing this now!

3.   Update your process documentation

Now that you have a clear picture of your processes, you’re well positioned to review your current process documentation and update it.

Review and update your process flow charts, make lists of the types of tissue receipts you get, what you need to do to them and list the types of dispatches you make, whether that’s other tissues or results data.

The last bit is to document the steps you carry out for each of those different processes that turn your receipts and requests into your deliverables.

At this point you’ve completed the first major part of your work. You know, and have clearly documented, what your work is and how you carry it out.

Now, the main aim of your LIMS is to help you carry out those day-to-day processes. In a nutshell, that’s what you need the LIMS to do. Time for the next step.

4.   Produce your LIMS User Requirements Specification (URS)

So, you just document specifically what your LIMS needs to do to support your processes. Adding your process flows and process descriptions to your URS document helps to give context to the specific requirements.

Your document should then list each step that the LIMS must do to support your processes. For each, make a note of data inputs that it should allow, what validation it should carry out and what outputs it must give. List searching capabilities, security filters that you need in place and access restrictions for different levels of user.

Once you have your URS for your Laboratory Information Management System (LIMS) you can build your test plan and scripts against its specific requirements. Those test scripts will allow you to validate your system.

5.   Test your Laboratory Information Management System (LIMS)

That’s what validation is. It’s not a dark art, it’s just a documented set of tests to prove that your LIMS does what (a) its specification says it does and (b) your processes need it to do. Those two things should, of course, be the same.

This is where your LIMS vendor can help. They have experience in testing and validation but remember that they can’t do it for you. Validation is on your lab processes and the effectiveness of your LIMS to support them. They can help by providing consultancy, help with test scripts and template documents but at the end of the day, it’s your job to validate your system.

6.   Make plans based on your findings

Finally, there is a further big benefit from producing your LIMS User Requirements Specification (URS). It highlights where you haven’t optimised your LIMS to your requirements.

You can now make an informed decision about whether your LIMS has reached the end of its useful life or whether you can optimise it to support today’s processes rather than those of a few years ago. You have evidence to support a funding application and a clear route to optimising your processes and reducing risk for your department, the entire institute and, most importantly, your patients and donors.

References

About The Author

Gary Rooksby has over 25 years’ experience implementing and evolving corporate systems including manufacturing and quality systems for a range of major clients such as the MOD. For the last 18 years Gary has specialised in Sample Management Software with emphasis on process optimisation and data management. Gary works in partnership with clients and draws on his wealth of experience to help institutes and their teams to maximise the benefits from new and upgraded systems. Business needs are constantly evolving, and Gary loves the changing challenges. Gary always focuses on delivering value to the users, whether that is financial, scientific or simply easing workloads. He believes that the system is never an end in itself; it is a tool to help the users achieve their goals and that principle is always at the heart of any system or data designs.