|
 |
 |
 |
 |
 |
 |
 |
|
     |
|
articles IT in the Lab: Cloudy Solutions 
Even if your lab's IT system is state-of-the art, inefficient procedures for acquiring, analyzing and reporting data can limit its chances for success As I begin to put fingers to keyboard, it occurs to me that many of my potential readers work within similar highly regulated environments as me. Our Regulatory Compliance Manager continually needs to remind us all of the differences between QC and QA, but my question is, why do laboratory personnel repeatedly fail to recognize the difference between information systems (IS) and information technology (IT)? With their ubiquitous PCs, analytical instruments and networks, laboratories today are brimming with IT, but surely, the underlying information systems that exist are equally significant. While laboratory managers are usually capable of identifying their information-related problems, understanding the contributory causes, identifying and clarifying the possible solutions that exist to manage and share the vast amounts of data that their laboratories generate requires experience and a different viewpoint. Consider any generic laboratory and the chances are that you could divide the work process into six categories:
I accept that these functions will differ in detail for each type of laboratory, but there is a surprisingly high level of commonality of operation and even though the language may vary, we can look at any category and analyze the impact of IT and the problems that it brings. Managing the flow of information To highlight my point, reflect on something as simple as a change to a client's contact address. Imagine that a change of address notification accompanies a batch of samples into sample receipt. What information systems need to be updated? I can, for example, think of at least three in our organization (LIMS, accounts, marketing). Which is the master system? Which system needs to be changed first? What are the possibilities and consequences of a mismatched address? Clearly, IT in the laboratory has been a boon but without taking a step back and looking at the overlapping Information systems, problems will arise. Whenever we invest in IT we should be asking ourselves what we are going to do with the data that we generate and what information will we need to extract from it? Sample analysis is an easy place to start digging, and in many laboratories, you do not have to dig too far. We all dream of the laboratory where all instruments utilize identical data systems but of course, in reality laboratories contain different types of instrument from different vendors running different data systems. I know there are constraints, but managers of instrument laboratories who upgrade their instruments to a new data system only to find that suddenly all the laboratory personnel cannot process any data should be taken to task and reminded of the bigger picture. I'm not suggesting that the tail should wag the dog, because analytical purchases should be justified on the laboratory's needs. But if more thought is given to a company's IS needs, then potential problems can be identified much earlier and solutions are clearer. A comparable problem existed at a laboratory that I visited earlier this year. Through normal growth, they reached the stage where a laboratory supervisor was responsible for 11 instruments from five vendors, covering six different techniques (GCMS, LCMS, HPLC, NMR, AA, and SEM) and ranging in age from six months to six years. My client was concerned about today, specifically how they could possibly manage to continue to train staff in all these systems, and equally about the storage and retrieval archive problems the future would bring. Surprisingly, the laboratory in question had a great deal of success with their goals and that is partly due to the efforts in standardizing data formats. I know that there is still a long way to go, but as consumers, we should recognize and applaud the progress, because the benefits are being realized. Importance of an IS strategy Despite the success story outlined, many of the problems should have been avoided. It disappoints me that so few companies can actually produce an IS strategy document. Whenever I visit a laboratory as a consultant I ask for a copy of the IS strategy, but to date only 10% of clients have been able to produce one! Is this the root of the problem? I think it is. Too often laboratory managers do not attempt to examine existing information systems and rely on IT or IT people to find solutions. The purchase of an Information Management system such as a LIMS (Laboratory Information Management System) is one example where too often the justification is valid, but the embedded information systems are not understood, the specification is incomplete and subsequently, regardless of the success of the implementation project, the resulting system will fail to meet all expectations. Sure, the laboratory may be happy or alternatively the system will address the company's higher level needs but unless both parties are treated as stakeholders at the outset, the system cannot be a measured success. Remember, the aim is not 'A successful LIMS implementation' but rather 'To implement a successful LIMS'. How to select a LIMS for your lab Taking the above into consideration, and in hope of inspiring good-natured debate here are a few must-do's for those of you considering a LIMS purchase, that can be applied to any similar IS purchase for the laboratory:- Use an external consultant. Typically, most laboratory managers justify, specify and implement at most one LIMS in their career. How can they possibly know what to expect from a product, or what common pitfalls exist? Used correctly, a consultant can bring value to your project. Remember, as the third party, your chosen consultant needs to bring something extra to the project. Today's labs are dynamic environments where business and individual needs change, so remember to ask your consultant how long it has been since they were last in a working laboratory! (You would be surprised at the answers from some!) They must be able to demonstrate practical experience of what you are trying to achieve. Theory is all well and good but ask them how many successful systems they have actually implemented themselves. Spend as much time as necessary identifying your business needs. Only when you have identified your business needs can you begin to consider whether you need a LIMS and the benefits it could bring. You must be able to answer the question 'Why do you need a LIMS?' People purchase LIMS for numerous reasons - many of them valid, but whatever you are looking to do, remember that the business needs should take precedence. Prepare a "user requirement specification" (URS). You can talk to vendors and review systems before you start the URS but please create the document before you ask for quotations. The document should not simply reflect your current working practices, but if possible, take the opportunity to review who is doing what and why. System analysis takes experience so even if budgets are tight; consider using a consultant at this stage. The URS needs to focus on 'What you need' and perhaps 'Why you need it', but try to leave the 'How to do it' to the vendor. Regardless of how experienced you or your consultant is, the vendor will know his system best, so let them have the opportunity to show you how they can meet your requirements. Most vendors much prefer the structured approach of quoting against detailed requirements. Two final notes of advice here: Firstly do not fall into the trap of making your initial URS too detailed, or the chances are that during the life of the project it will require too many amendments. Secondly, if a vendor offers to write your URS, then try not to laugh, but smile and politely decline the offer! Look beyond the product when selecting a system. It may surprise those of you who are unfamiliar with the LIMS market, but there really is not that much difference between the offerings from the market leading vendors. If you specified your requirements correctly you will soon know what is and isn't possible and the choice will come down to factors beyond the functionality of the product. You should investigate the quality and scope of additional services offered, and plans for future development. Carefully select your project team. Take time to ensure that everyone on your project team is a stakeholder committed to the project's success. Avoid people who are simply available. Project manage the implementation. Typically, implementing a LIMS still takes too long. There are a few projects that last only 12 weeks but conversely several take many years. You should aim for a 6 to 12 month timescale and manage the project accordingly. If no one from the laboratory team has project management experience, then again call in a consultant. Without correct management of the "time-functionality-cost" triangle your project will flounder. In summary, did I say earlier that we are simply trying to inspire a good-natured debate?! I am sure we are all looking for clearer solutions. Whether it is the receipt and subsequent analysis of samples, the sharing of information or the need to communicate with other systems, we should focus on understanding our business needs in the laboratory and identify the information systems in place. Without this knowledge, cloudy solutions will be commonplace; continued investment in IT will simply lead to duplication, inefficient information systems and the absence of any meaningful ROI calculations. About the author 
Trevor De
Silva is Chief Executive Officer of Scimcon. A graduate chemist,
Trevor has been working in forensic science since 1980 and with
LIMS and laboratory automation since 1987. He successfully
completed a second degree in computing science in 1990, and since
then has been involved in Information Technology, successfully
implementing and validating two LIMS for HFL in the UK (www.hfl.co.uk).
As the senior consultant with Scimcon, he has consulted on
numerous projects worldwide and written several articles on
information systems and laboratory automation.
|
|
|
|
||||||||||||||||||
|
|||||||||||||||||||||||
