Christian Stage

A laboratory information management system (LIMS) can control, manage, organize and document information thus saving time and money. Locating certain types of production information or documentation can be easily fulfilled using software search functions. The ability to automate more procedures reduces the risk for human error and allows personnel to be used for other types of work providing a better cost benefit ratio. All these parameters should work together to reduce the time and cost of production. 

LIMS software systems started with small, closed, in-house solutions in the 1970s. In the 1980s, commercial products became available when software was installed on computers linked together in a closed network system. The software was usually specific to a certain instrument supplier and used a proprietary data format to protect the product and keep customers reliant on the brand. Technical improvements led to faster and more open client server systems becoming available in the 1990s. Modern systems are open client server web-based systems using Microsoft .Net technology. 

In general there are three options available to a company. It can decide to program an in-house, proprietary system fulfiling all local company demands. Alternatively it may buy a commercial product and modify it to fulfil local demands, a process known as customization. The last solution is to buy a standard program covering most of the needs of the project, known as a commercial off-the-shelf (COTS) solution. Parameters such as initial price, licence price, implementation time, updatability, staff training, design and ease of use, CFR 21 Part 11 compliance, audit trails, electronic signatures and validation should be taken in consideration before selecting a new LIMS software system. 

What about software security and validation?

A lot of laboratories and production units are controlled be regulatory rules. Working with software with traceability options offers huge benefits when solving technical problems and complying with documentation demands. All pharmaceutical companies must adhere to the 21 CFR Part 11 regulation including electronic signatures and audit trails. Traceability is the key component of solving many technical challenges. The technical development of the computers, advanced modern software technology, standardized result formats, LIMS flexibility and performance has reached a level where it can offer most users large scale options to make life easier. 

LIMS software is traditionally found in analytical laboratories such as R&D labs, in-process testing labs and quality assurance (QA) labs. Technical developments and increasing demands in other industrial areas has seen LIMS placed in environmental labs, industrial labs, and pharmaceutical and life science labs. LIMS is designed to be linked to analytical equipment through an interface box. Depending on the size and type of the LIMS, the following procedures can be undertaken: 					

Results approved and electronically signed.

Manufacturing industries where individual components are used may need to track objects incorporated into many products reliably across the globe. Achieving this task without the aid of a LIMS type system would be extremely difficult. 

Reducing the time-to-market is a priority in the pharma industry, with development costs rising rapidly. LIMS software can be used to optimize the instrumental analytical capacity for testing different samples using resources in the most efficient way. During the regular inspections, which form part of the industry's tight regulation, a searchable electronic database created by a LIMS system is invaluable.  

How is data reliably and securely matched and extracted from the database?

With increasingly complex networks and multiple feeds to a central server, software is needed to collate and sort information. The central software is typically a relational database, for example an SQL database. If the information has varying formats a translation module must be programmed to standardize the data for ease of analysis. 

The central software must have maximum security to comply with 21 CFR Part 11 including user name, password (including rotation rules), electronic signature and audit trail. It must not be possible to delete data using the Microsoft "explore" functionality, though data may be inactivated. If necessary it must be possible to "reactivate" the data to comply with regulatory requests. All risk-based actions must be documented in the audit trail and validated. Any critical parameter able to influence the final judgment of the data must be checked (validated). When combining and modifying data formats it is difficult to keep the audit trail and track all calibration data/off set values. If one of the programs is updated, it may be necessary to change or modify all linked programs with a following complete validation of all parameters. 

With all data in the same database, statistics, calculations and baselines might be extracted. To create statistic reports the correct data must be present. The correct data is normally produced using the software search functionality. All statistic and search functions must be validated to ensure that all data are present and calculations are performed according to an accepted standard. Using different calculators may cause small differences in the calculated results. The differences are due to how many decimals are used and the rounding technique. Routine calculations may be programmed as macros. Some programs may create a baseline report meaning that the user can get a summary report at a certain time stamp showing the status of all parameters.

  Even if there are no external authorities demanding a validation or similar documentation it is strongly advisable to test any software doing the target task in the local environment. 

Using a LIMS software system may increase efficiency if the needs of user are matched, the system is implemented in a proper way, validated according to local demands, properly configured to local structure and if incoming data arrives in the same format. The system must be continuously updated and a back-up procedure defined. Modern technology and software development has improved LIMS flexibility and performance to a level where it can offer most users large scale options to make life easier. Generally speaking, the LIMS system started as a "narrow" software solution supporting only few applications but today it is much more standardized and able to support a huge range of applications.  

is director of QA product development at QAtor, Denmark. 

Title 21 Code of Federal Regulations Part 11 (21 CFR Part 11)

 U. S. Food and Drug Administration, 5600 Fishers Lane, Rockville MD 20857-0001 

Articles

A laboratory information management system (LIMS) can control, manage, organize and document information thus saving time and money.

Why use LIMS and related software

Baselines are one of the most useful tools in the 'validation toolbox'. They can be used for a variety of tasks with great success. This article will examine how they can be used and for what. 

Regulations (21 CFR Part 11) require companies to be able to present a snapshot of an installation at a given point in time. Most firms do this by managing changes (which are also required by the regulations), but the vast number of them makes it very difficult to present the data for a single system within a reasonable amount of time and limited effort.  

A Utah medical case describes how a company, unable to show that system changes had been tracked continuously, was subsequently unable to present specifics about any given baseline in the production facility.

  This lead to several 483s (cGMP noncompliance notice forms) and a law suit. GSK was asked by the UK authorities about the configuration of a system before and after a specific change, which again suggests that the authorities are interested in baselines. 

The Parenteral Drug Association (PDA) Technical Report 18, Section 3.1 suggests: "An inventory should be created of all computer systems being used within the appropriate business area (company, department etc.). It should be a dynamic inventory representing, at any point in time, all systems currently in use. A regulatory inspector often asks for this inventory as one of the first questions during an inspection."

FDA regulation 211.184(c) provides further enlightenment as the regulation is not related to end user products alone, but also to production, production facilities and the system used in the production process:

"An individual inventory record of each component, drug product container, closure, and for each component, a reconciliation of the use of each lot of such components. The inventory record shall contain sufficient information to allow determination of any batch or lot of drug product associated with the use of each component, drug product container, and closure."

The glossary to this article can almost be considered a step-by-step guide to creating a baseline. First, establish a list of systems and the units they consist of. At this point it is important to consider the setup. You may want to describe the hierarchical structure of the entire company or merely the structure of a single system (Figure 1).  

 Figure 1 Example of structure for a large company.			

It is essential to decide upon the level of detail required in the documentation; for example, for a computer system, do you need the serial number and type of the hard disk? Maybe. It depends on what you are going to use the system for. If it is specifically for regulatory reporting, you may not. The size, type or serial number of a hard drive is not critical, but the collection of such information could be useful for maintenance purposes as well. Daily use of the information will — provided it is updated regularly — ease system maintenance because the required information is readily available not only to an inspector, but also for those maintaining the system. They will be able to retrieve the information about which hard disk they need for a support job without actually taking out the hard disk from the machine or even going to the specific machine.  

Of the information that could be collected it is necessary to determine what is most important. Generally, it is wise to consider three scenarios : 				

What information is needed to re-establish a given system? The answer indicates that hard disk size and type may be important, though serial number may not. Software types, versions and settings are important because they determine how the system works. 

What is required for inspections? The hard disk is not of interest, but the software make and version are.  

What is needed for maintenance? Minimum requirements are important, as this may be the basis for a like-for-like exchange.

  If a system contains irreplaceable components, this may also be noted. 

To determine what data must be recorded for a baseline, their purpose must be considered (Table 1).  

Table 1 Example of a generic structure capable of containing both file and printer servers.			

When the structure and detail level have been decided, the first CII draft may be noted. At this point, the individual components of the systems are entered into the CII list (Table 2).  			

This draft CII list requires a baseline (based on the CII lists, which are reorganized into a protocol) to be compared with Table 3.  			

Creatively used, and given the flexibility of some sort of system to manage it (and I emphasize that a baseline system is NOT Word, Excel or the like, which are programs), baselines could also be used for controlling backups. Figure 2 shows how a specific configuration can be derived from the baseline by extracting the information for a given point in time. It shows that you will be able to present, based on a baseline report for any given point in time, exactly which backup to restore, on which system, and what hardware.  			

Consider the advantages of being able to readily present this information from the baseline used for the daily system maintenance.  

Fully implemented, the baseline may be used for other purposes too. Currently, the authorities are interested in equipment requalification and process revalidation — the CII report or the baseline report will help with this. Because the reports list all the changes that have occurred within a single system, it is possible to provide the change information almost immediately. Also the product annual review, which is very much in the sight of the authorities, can benefit from the baseline report, as it shows the system has been in control continuously. 

The baseline can not only provide information about the production system at any given point in time, it can simultaneously highlight differences between two points in time. This is not only beneficial for computer-related systems, combined with a calendar the baseline can be used for calibration and preventative maintenance. 

Figure 2 Logical view of several configurations held in several baseline documents.

Used properly, the baseline can be one of the most important tools for tracking system changes. The debate during an inspection will shift from how a system looked before and after a specific change, to the deeper and more profound questions about how many minor changes makes a major change, and was the change corrective, adaptive or perfective, but these matters are beyond the scope of this article.

www.fda.gov/bbs/topics/news/2004/new01102.html

Validation and Qualification of Computerized Laboratory Data Acquisition Systems

3. US Food and Drug Administration, 21 CFR Part 211 — 

Current Good Manufacturing Practice Regulation for Finished Pharmaceuticals

General Principles of Software Validation; Final Guidance for Industry and FDA

Baselines are one of the most useful tools in the 'validation toolbox'. They can be used for a variety of tasks with great success. This article will examine how they can be used and for what.

Regulatory Report: Using computer baselines

				In the pharmaceutical world it is generally accepted that a valve can be exchanged for another when it becomes defective, provided that the new one is exactly the same as the old one.  

Occasionally, the supplier of the old valve no longer exists, but the same valve from the new supplier can be accepted as a like-for-like exchange. Also, valves that have the same diameter, are made of the same material and share other identical specifications are accepted too, even if it is a completely different valve. Personally, this is satisfactory as long as functionality is considered in terms of risk assessment.  

But what happens when a computer system breaks down? Computer hardware tends to be unobtainable within a very short time frame. Furthermore, is it acceptable to exchange a Gb hard drive for a Mb one, or can the software run on a GHz computer instead of a MHz one? 

In my opinion, the most important tool for finding out how the exchange of a unit influences a system is risk assessment. For one client, who recently required assistance with their computer systems, we created a like-for-like standard operating procedure (SOP), which we took a little further.  

We discovered that although numerous parts of the original documentation referred to a like-for-like change, nowhere was the term specifically defined. An effective and lasting solution was required. In this case it was computer-related systems that needed attention. 

First, it was decided that the SOP should be as extensive as possible. The goal was to create an SOP that covered all changes of computer equipment and process logic controller (PLC) systems. But how possible is it to exchange systems or parts of systems for something equal, and what exactly is equal hardware? 

In practice, it is quite difficult to find hardware that is exactly the same as that installed, and old software may not run on newer hardware. Therefore, system analysis is a good option. If the software requires Windows NT or newer it may not actually impact your system if you install Windows 2000 in place of the Windows NT. Also, if the software requires a minimum memory of 4 Mb, a new computer containing 512 Mb should not pose a problem, as long as the operating system can handle it. When talking about computer systems, we are, in fact looking at minimum requirements rather than specific requirements.  

To establish what exactly the requirements are, some detective work is required at this stage. 

 Gather the user requirement specification (URS) and design specification to find out if they contain exact requirements regarding the system. Frequently, the hardware is poorly described, and the system software equally vague. 

 Next, obtain information from the software supplier — this information is often found on the side of the original software distribution box or on the supplier's home page of their website. The text is often worded to the effect of: "The system will run on a computer with a 50 MHz 486 central processing unit (CPU) or faster, and minimum 64 Mb RAM." Unfortunately, these specs are long gone and the minimum available is a Pentium 4 and 1 Gb of memory, but the software may run successfully anyway. 

 The next move is to contact the supplier. If, in their opinion (preferably based on a written statement that could be attached to the like-for-like documentation), the software runs on the available hardware, we can proceed to the next step. If the supplier does not recommend a like-for-like exchange, the risk assessment has to be moved to a higher level (change request or change control case). 

Almost anything can be 'passed' provided it is properly documented and based on adequate rationales. To document the considerations made, a risk assessment must be performed.  

If professionals do the rationales that explain why the like-for-like is OK based on a predefined pattern, it will be possible to record them in a 'fill-in-the-blanks' template document, which makes it easily accessible. By doing this, we can consider all the general pitfalls that would occur during the actual implementation:  			

hardware stress as result of use of increased system performance

lack of documentation to perform the action.

 Table I Sample rows from a sample SOP.						

Based on these considerations we can decide whether it would be feasible to do a like-for-like exchange, otherwise a change control case will be needed to be opened instead. As opposed to malfunction scenarios, it is possible to do the risk assessment in good time, and any slight indication of problems regarding a seamless change of device/system/software will give the person evaluating the risks a better idea of choosing between the straightforward like-for-like option or a more paper-consuming change control case. Whatever the decision, the performed risk assessment may serve as an appendix for either, demonstrates the occurrence of thorough scrutinization and that rationales for either choice are in place. 

To make the like-for-like exchange more easy to implement in real-life and to keep stress levels to a minimum, it is wise to prepare. A generic test protocol for verification of system settings and functionality (referring to the existing validation documentation for the system) should be possible to create. It is advisable to consider both physical settings, as mentioned in the system's design specification and verification of the installed software based on the system (according to the baseline for the system), and functionality tests (such as start of the application and communication towards other systems). 

Once the 'equalness' (like-for-like similarity) based on minimum requirements of the system are established, a final report can be written. If sufficiently prepared, a 'fill in the blanks' report may be produced prior to the test. 

At all stages of this system update it must be borne in mind that the like-for-like exchange is a 'cheap' version of the change control case. Provided that the considerations that the like-for-like exchange are based on are done before the exchange is necessary, it is quite easy to maintain a very high level of control, and, therefore, the 'validated state'. If the considerations are not made beforehand, it may be far more difficult to prove that full control has been maintained throughout the process. 

It may be worthwhile to build an SOP that contains: 			

a prewritten generic document analysis (Table 1)

If these elements are predefined and the considerations are made beforehand, more degrees of freedom can be allowed. After all, that is what we are looking for, and with the authorities actually suggesting that we use the risk assessment in a more active manner, it might be a good way of being in compliant control, and fixing problems related to the age of the computer at the same time. It also complies with the life cycle approach, provided that we do make updates when necessary and the 

like-for-like exchanges when appropriate. 

This topic is not debated nearly enough. In the area of computerized systems, there have not been sufficient considerations to decide whether like-for-like exchanges of equipment must be based on exact likeness or can be based on minimum requirement likeness. 

I hope that this article gives your company a push in the direction of the latter, but urge you to make your own decisions based on risk assessment.  

 is director of QA product development at QAtor, Denmark.

In the pharmaceutical world it is generally accepted that a valve can be exchanged for another when it becomes defective, provided that the new one is exactly the same as the old one.

Like-for-Like Exchanges

Reading the good automated manufacturing practice (GAMP 4) guide acquaints you with the now classic and almost famous V-model.

 The V-model, originally used for describing a validation workflow of IT and automated systems, is easy to understand and very good at ensuring that the requirements and design are built into the final solution. It is also extremely versatile and can be used for almost any type of validation task you could meet in a development phase (Figure 1). 

 Figure 1. GAMP/ISPEs perception of the world.			

However, its benefits are not unlimited. What problems could such a seemingly 'perfect' model have? 						

First, when performing validation, I do not begin by mapping out the user requirements, which are the result of large amounts of research and engineering — initially, I do not have any details or specifics. Also, to write the user requirements before the validation plan goes against the general requirements about working against predefined plans. Instead, I start a project based on a customer's idea and, through discussion and refinement, it becomes clear what the project is about. Up until this point, notes are made with no thought of good manufacturing practice, thereby encouraging free thinking without restrictions or limitations. Once the project objective

is defined, it is recommended that the customer obtains a quote for its execution. If a serious supplier with knowledge of the pharmaceutical industry delivers a fixed price offer, they will almost certainly want to see the validation plan because this is where more than 50% of the project's time will be spent; they will want to know what documents they will have to produce. From an economical perspective, this suggests that the validation tasks are more important than the user/customer requirements. 

The second issue with the V-model (and Vs in general) is that they have an end; once the validation is complete, the papers will be confined to storage where they will sit and collect dust. Subsequent changes or additions to the existing system will result in creating new, little V-models rather than reusing existing documentation. This is primarily because the engineering department does not have access to the end users' document archive. This promotes the idea that the project is in a constant state of development. In truth, it actually means discarding preceding user requirements, design and validation as any new version of V-model may add, delete or change the three cornerstones (requirements, design and test. I call this phenomenon 'fragmentation' — one of the most dangerous phenomena encountered in validation because it becomes increasingly difficult to preserve the full overview of both the system and the validation. With fragmented documentation you have to look at more than one document to get the full picture. For example, when the user requirements are spread over dozens of papers, nobody actually knows what the collected sum of the requirements are. A similar situation is created when design documentation is spread over different documents, and changes are included in other documents (modifications to an existing design or additions based on new requirements from new documents). During an all-important inspection, there is nothing worse than having to trawl through mountains of paperwork to locate those that support a specific system, not to mention time consuming.  

Lots of little V-models that describe a system ready for retirement creates a third major problem. Not only is it difficult to find out what the system cornerstones are (because of fragmentation), but it is time-consuming finding and retiring all the old documents.  

When planning, life cycle considerations such as maintenance and retirement, should be built in to ease later processes (e.g., data migration [Figure 2]). Having lots of V-models though does not go hand-in-hand with complying life cycle considerations described in the GAMP 4 guide. So what can we do? 

If we turn the 'V' into an 'O', the life cycle consideration might actually work because there would be no additions, deletions or modification, just the newest version of the documents (Figure 3). This would solve the problem of document fragmentation because the documents would always be updated and the latest version consistent with the real life system. Instead of creating a new user requirement specification (URS) in a new V-model, modify the old one and save it as Version 2. Based on the modified URS, it is possible to modify the design so that it mirrors what is actually going to be implemented in the real world. 

The only problem with the reuse of documentation is the manually performed additions to documents; that is, manual comments and manually performed tests. However, FDA's 21 CFR Part 11 may have found a solution to this. Some years ago, FDA (and prior to that Eudralex) permitted electronic signatures.

 Rather than seeing these as a hindrance, perhaps we can actually use them to our benefit. These clauses allow us to move any type of electronic raw data (provided we do it in a validated manner). So, provided we make electronic signatures for any modifications manually added to documents, we could move signatures from one version of a document to another. There are, however, some 'minor' technical obstacles about proving that signatures were not compromised, such as proving that they were moved in a validated manner. However, once they are overcome it should be possible to insert new tests of new requirements in the already established test scenarios. This is also possible with paper-based documentation. 

Using an O- instead of the V-model would also be far more logical regarding the life cycle considerations because, unlike V-models, O-models constantly evolve. The O-model enables production to continue with little validation interruption because specific versions of validation documentation are available to support any point in an item's life cycle. The method can also be done using multiple V-models, reusing the same documents as developed in the last V-model in every new one

Finally, we must consider how to start and end an O-model. It seems that the right way to begin an O-model is via a change request or a deviation. In many cases the refinement process is part of the deviations or change requests, but putting it into the planned loop might actually allow the process to be right first time. The end of an O-model is controlled by end of life considerations — what are we going to do with raw data, can we reproduce data or a production scenario in the full retention period? This is also logical, as the documentation is kept within the circle during normal life, and leaves the circle once the system expires. 

Knowing that the ways of the (validation) world do change over night, I am aware that the idea of using validation documentation for something other than inspections, is provocative. However, the ultimate goal of validation is to produce documentation that actually raises quality instead of just producing more paper. Think it over! 

www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfCFR/CFRSearch.cfm

Reading the good automated manufacturing practice (GAMP 4) guide acquaints you with the now classic and almost famous V-model.1 The V-model, originally used for describing a validation workflow of IT and automated systems, is easy to understand and very good at ensuring that the requirements and design are built into the final solution. It is also extremely versatile and can be used for almost any type of validation task you could meet in a development phase.