laboratory informatics


of the systems that they are responsible for supporting.’ Tis is a major step that has been taken to


extend the life of informatics systems as users are not adding code to a soſtware package but creating customised experiments that can help them adapt to changes in laboratory function. As Uzzo states, these tools allow vendors


to unify their soſtware without custom code embedded into individual installations – significantly increasing a vendor’s ability to maintain and support users. All of the informatics soſtware vendors interviewed for this feature include their own version of workflow creating tools to support user configuration. ‘Tese are accessing frameworks that


we have built into the system to empower the customer to deal with aspects of their workflow that are unique or to give the customer the ability to deal with change in the future,’ says Uzzo.


Supporting change When replacing a legacy system the focus must be on the requirements of the users but this is not a simple task. In most cases, this requires a deep understanding of not only the industry in which the laboratory serves, but


also to predict how changes in this industry might affect future development of the methods and experiments used. As den Boer highlights, it is not the


upgrade that is most important but the reasoning for the upgrade: ‘I think data is one of the big challenges. Before you start the process of replacing a legacy system you need to think about the intent. You need to ask yourself “did my business change in


EVEN SOME OF THE PHARMA COMPANIES CAN BE A BIT RELUCTANT TO TAKE THE CONCEPT OF STANDARDISATION ON BOARD


the meantime?” Normally the business has changed since the company first implemented the system. Te lab has moved on but the system has not moved on and moved with it.’ Te latest soſtware products allow users to


customise the functionality of a LIMS or ELN using workflow tools, but this is not possible with older technologies. However, legacy systems do not include this functionality so there is inevitably a point where the


functionality is not sufficient to support changes in the laboratory. Den Boer explains that, to manage


upgrades effectively, it is imperative that users ‘sit down and really thinking about what they want to achieve with this upgrade or replacement of this system’. Failure to properly audit a lab’s function


and requirements is a common pitfall in den Boer’s experience, which results in a company that is on the back foot from the start of a new deployment or upgrade. Te vendor and the customers end up learning this the hard way as they configuring the system to meet the laboratory’s requirements. Tis can cause delays and unwanted complications, which further postpone the new system. Other than managing the requirements


for an upgrade, Termo Fisher’s Ingalls stresses that data migration can be the biggest challenge to successfully deploying a new informatics system: ‘Different LIMS systems data models can be so radically different that trying to do a full migration of data can get really challenging.’ Ingalls adds that this is more applicable to the sample, test, or lot relationship, rather than master data, but nevertheless combining disparate data sets from different platforms can be extremely difficult and time consuming. Tis


➤


www.scientific-computing.com l


@scwmagazine


DECEMBER 2016/JANUARY 2017 5


wavebreakmedia/Shuterstock.com


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32