Due to the expanding nature of the LIMS market, there are a growing number of suppliers moving into the field. If a pharmaceutical manufacturer proposes to use a new supplier or a new LIMS product, it makes a great deal of sense to conduct a Supplier Audit of the proposed LIMS supplier.

If it has been some time since a supplier has been audited (e.g., one year or more), it is recommended that a follow-up audit be conducted to confirm that the supplier’s Quality Management System (QMS) continues to be followed. It is important that this audit be conducted prior to placing an order for the LIMS, as there may be some concerns regarding the ability of the supplier to produce a quality product.

Purpose

The purpose of the Supplier Audit is to allow the pharmaceutical manufacturer to review documented evidence of the supplier’s QMS. It is also essential to verify that this QMS has been used for projects involving the LIMS that is being considered for the current project, preferably including references to the types of analytical equipment interfaces to be implemented as part of the integrated LIMS. The Supplier Audit will also confirm that the supplier is capable of delivering the correct standard of software engineering and documentation for the LIMS.

ISO 9000

It has been shown many times that just because the LIMS supplier is ISO 9000 accredited does not mean the supplier is a quality supplier of software products. This is because the LIMS supplier is often accredited for the implementation and integration of LIMS, rather than the development of software. In these cases, the only way of gaining confidence in the approach to be taken in the software development, testing and change control processes is to visit the LIMS supplier’s premises. Where a supplier is accredited to ISO 9000–3 (TickIT), this will give the manufacturer greater confidence that a defined life cycle is followed because it is specifically aligned with the production of software.

Supplier Audit

The Supplier Audit Report is the documentary evidence approved by the pharmaceutical manufacturer, which identifies any issues raised during the audit and provides recommendations for any corrective actions. It is expected that these corrective actions will be implemented as part of the approval of the LIMS supplier for the project.

The pharmaceutical manufacturer is accountable to the regulatory authorities for any deficiencies in the chosen supplier’s capability. The pharmaceutical manufacturer is expected to bridge any gap in standards by assigning its own staff and/or employing consultants to assist the supplier in the validation of the LIMS. As this could increase the validation costs of the project, it is worth taking the supplier’s validation credentials into account as part of the selection process. In some cases, it may be appropriate to consider using another company to provide the validation expertise; this has the advantage of demonstrating independence from the LIMS supplier.

Design Specifications

Although the pharmaceutical manufacturer has determined its requirements and recorded them in the URS, by definition these requirements will be generic statements rather than being technically specific to any particular LIMS. The purpose of the design specifications, therefore, is to translate this URS into a proposed technical solution that will fulfill the requirements of the project. The structure of the design documentation, detailing the physical, functional and performance criteria for the LIMS, should be directly traceable back to the URS, to allow the manufacturer to confirm that all requirements have been addressed.

This may be achieved by using a cross-reference matrix that identifies each user requirement and references the location in the design documentation where the requirement has been addressed
and also holds justification for any requirements excluded or not to be fully implemented. The design documentation will usually consist of an FDS to provide a high-level overview of the proposed LIMS. A more detailed specification for hardware and software, the Hardware Design Specification
(HDS) and the Software Design Specification (SDS), are prepared if it is necessary due to the complexity of design. The design documentation should typically specify the following:

  • System overview description with diagrams (a concise description covering all interconnected systems)
  • System architecture with details of hardware with diagrams
  • System interfaces with diagrams (including networks and remote devices)
  • List of installed software packages with details of versions and so on
  • System performance (e.g., timing, memory storage, availability and spare capacity)
  • Software flow diagrams (e.g., Grafset, Yourdon, state transition diagrams, etc.)
  • Communications and network protocols (e.g., RS232, TCP/IP [Transmission Control Protocol/Internet Protocol] Ethernet)
  • Methodology for data storage and retrieval
  • High-level design of the database structure
  • Analytical equipment interface, computer and network systems design
  • Site environmental conditions, including power supplies
  • Client-server desktop user interface software configuration details
    and terminal emulation requirements
  • Peripheral devices (e.g., client-server desktop user interface computers,
    printers and backup devices)
  • Number of users and response time required from the LIMS
  • Functional descriptions of LIMS operations
  • Contingency Plans, maintenance and operating procedures
  • Application software and reports
  • Security and access control methods
  • Standard software products (e.g., Excel®)

Each of the functions within the FDS should have a unique identifier for tracability in the testing phase of the project. This may be achieved by using the outline function of the word processor used to create the document. The functions identified should be in sufficient detail to allow the LIMS supplier to produce meaningful tests, which will be recorded in the factory and site test documentation.

Where appropriate, the FDS will be supported by more detailed design documentation, such as the SDS and the HDS, and in the case where bespoke software is produced, the Software Module Design Specification (SMDS). These support documents or the FDS itself must provide sufficient detail to allow the core LIMS and analyzer supplier to fully define its respective systems and hence provide suitable test documentation.