The Core Laboratory for Clinical Studies (CLCS) at Washington University School of Medicine in Saint Louis, USA, conducts testing on Phase 3 and 4 clinical trial samples. In addition to pharmaceutical sponsors, the CLCS also performs testing for Washington University School of Medicine researchers, and for clinicians who service patients. In early 2002 it was determined that the legacy Laboratory Information Management System (LIMS) was to a more robust, data driven system.
David A. Mulvihill
is Manager of Information
Systems, Core Laboratory
for Clinical Studies,
School of Medicine, USA.
The IT department was tasked with designing a solution that would meet business, regulatory, user and client requirements. Determining where the legacy system failed was helpful in planning a system that would be extendable and maintainable. The legacy system was written in dBase 4, an application development language, and was architectured in a way that required significant re-coding of the LIMS to implement basic enhancements (such as a new test or bringing new pharmaceutical studies online). Performing these updates and subsequent testing and implementation on a rigorous schedule became overwhelming, and led to programming inconsistencies and system errors. In addition, the legacy LIMS database was not normalised, resulting in significant data duplication. When a patient’s name was updated, for example, numerous tables needed to be updated in a cascading fashion. This caused inconsistencies in the database and was to be avoided in the development of the new system.
We determined that the best architecture for the new LIMS would be a data driven n-Tier system that would utilise the reusability of classes in an object-oriented programming language to ease in performing system updates or enhancements. Due to the separation of business logic, user interface and the data store, n-Tiering permits modification of one tier without necessarily impacting the others. For example, a database upgrade
or a modification to allow web access can minimise the need for heavy reworking. Microsoft Visual FoxPro 6 (VFP) was selected as the development language because there was in-house expertise in the use of an x-based language (dBase 4). VFP is an object-oriented language offering an integrated development environment for both user interface and database. In addition, the VFP database is easily scalable to an enterprise database management system such as Oracle eor MS SQL Server.
The next step was to map all the legacy processes to the new n-tier system. This involved creating logical maps of laboratory processes and determining the impact the new system would have on these processes throughout the laboratory. Key process changes were identified and noted so standard operating procedures and training material could be developed prior to implementation. Physical maps of the database were developed to classify how data from the legacy system would be stored. Legacy entities, attributes, indexes and data were scrutinised to maximise performance and eliminate data duplication in the new normalised database schema. The data conversion programming was developed from these maps.
The CLCS utilises numerous automated analysers to perform testing. In order to speed data entry into the LIMS and minimise the risk of data entry errors, these instruments were targeted for electronic data interfaces. Most laboratory analysers use an ASTM International or subset protocol for messaging between the LIMS and the instrument. There were two scenarios that were considered when designing instrument interfaces. In the first, the instrument only sent sample results, uni-directionally, to the LIMS. In the other, the instrument queried the LIMS for pending test orders and sent samples results to the LIMS, bi-directionally. Both scenarios used barcoded IDs to uniquely identify the sample. Instrument interfaces for each analyser were created using Microsoft C#.Net to pass data between the instrument and the LIMS. Data import processes were created for other laboratory instrumentation that did not support a messaging protocol but allowed for exporting the data in some fashion (.txt, .csv, etc.).
Since the CLCS performs laboratory testing for multi-site international clinical trials as well as physician offices, we needed to create the flexibility to route the report to clients via printed, faxed or PDF copy. In addition, we needed to mimic the report format from the legacy system so the LIMS upgrade would be transparent to clients. This was accomplished by designing a helper application that monitored the LIMS for reports to create. When the helper application found all testing was complete on a patient, it created an ASCII text file with an identical format to the legacy systems report. The LIMS user would then be able to review the report and subsequently authorise it to be delivered via the preferred client method. An important business critical requirement that was addressed was the detection of laboratory results that fell outside reasonable limits. The LIMS was designed to compare patient results to known extreme, physician alert and client requested values. If outside defined limits, the result was flagged for resolution by the technologist. This insured that no questionable values were released to clients without being double checked for accuracy. An additional delta check, added to compare a patient’s current result against a previous one, aided in identifying non-analytical errors such as switched or mislabelled samples.
Due to special data handling requests from the CLCS client base, it is difficult to predict data formats and attributes required for the client data set. In these cases, data handling applications are developed independent of the LIMS. They are controlled by a formal change control process and validated as standalone applications.
After realisation of the full scope of the development project, we began formal development of the system. Throughout the development lifecycle, numerous iterations of unit, module and system testing phases were performed to internal quality assurance standards.
The impact of the new LIMS on workflow and lab-level operations was foreseen to be minimal. The impact on users, however, was expected to be extensive and posed a significant business risk. Standard Operating Procedures (SOPs) were created to address, in detail, all aspects of the use and maintenance of the LIMS and associated applications. Group training sessions were conducted to give users a general overview of the systems functionality. Specialised sessions targeted smaller user groups; they focused on tasks specific to particular laboratory positions and were conducted close to the ‘go-live’ date to provide comfort to users during transition to the new LIMS.
A new server was installed and workstation hardware upgraded or replaced prior to deployment of the LIMS. The network operating system (NOS) was updated from Novell Netware 4.0 to Windows 2000 Server and all workstation operating systems were upgraded from Windows 98 to Windows XP. The system was tested side-by-side with the legacy system before being fully implemented.
In order to bring the LIMS into compliance with the US Regulations mandated by our pharmaceutical clients, a retrospective validation was performed three years later. Such a process establishes documented evidence, which ensures that the system not only offers users the requisite functional capability but will continue to do so through the LIMS lifecycle. System validation is considered a critical instrument to ensure data quality. By improving regulatory compliance and reliability, it can help ensure that patient risks, error rates and related costs can be controlled. Costs can therefore be reduced throughout the lifecycle, as it becomes easier to perform system modifications and re-validations.
Since the CLCS operates in a regulated environment, all computer devices that capture, enter or modify data are required to follow change control procedures. These allow system modifications to be traced to their origins and permit ‘rollback’ to a previous system state if required. A change control SOP was developed to provide an organised and consistent plan to ensure integrity and stability throughout the LIMS lifecycle.
Conclusion: Build or Buy ?
There are many commercial LIMS systems that could have performed well for the CLCS and we took account of many factors– among them, flexibility, scalability, quality, security and cost – before deciding to build a custom system. The CLCS also sought to avoid a rigid LIMS framework which required a prolonged waiting period for upgrades or entailed dependence for maintenance on an external vendor.
Our new system blends the productivity and throughput of commercial systems with the flexibility of a custom system built around the core business which we, as users, know best.