Beyond the laboratory Building a Smart Laboratory 2015
explanation to the inspectors on how to handle IT systems. How that cannot be a requirement document, is hard to understand, however. Te main difference between Part 11 and Annex 11 is that the latter also includes risks. IT validation shall be based on risks; high-risk systems need more validation than low-risk systems.[8]
that the FDA started in the early 2000s: know your processes, and base the work on the risks they encompass.
How do we validate our IT system?
Te best answers are in a guidebook called GAMP5[9]
. GAMP also has a few more detailed
sub-books. What is written in this guide to a smart laboratory is of course just an overview. Please see GAMP5 for more details. Te GAMP5 way of validating the IT systems is as follows: • Risk management to decide how important the system is in the process;
• Categories of soſtware to decide what needs to be done;
• Combination of risks and categories to decide what to do for this system; and • Testing guide for how to test the system.
Risk management Identify regulated E-records and E-signatures: • Is the record required for regulatory purposes? Is it used electronically? Is a signature required by GMP/GLP/GCP?
Assess the impact of E-records: • Te classification of potential impact on patient safety and/or product quality: is it high/medium/low?
Assess the risks of E-records: • Te impact and likelihood/probability of problems being detected/happening: is it high/medium/low?
Implement controls to manage risks: • Modify processes, modify the system design; apply technical or procedural controls.
Monitor effectiveness of controls: • Verify effectiveness, consider if unrecognised hazards are present; assess whether the estimated risk is different and/ or the original assessment is still valid.
GAMP5 software categories
Category 1: Infrastructure soſtware • Definition: layered soſtware (i.e. upon
30
which applications are built). Soſtware used to manage the operating environment.
• Example: operating systems, database engines, statistical packages, programming languages.
• Validation: record version and service pack. Verify correct installation.
Category 2: Tis category is no longer in use
Category 3: Non-configured products • Definition: off-the-shelf solutions that either cannot be configured or that use default configuration. Run-time parameters may be entered and stored, but the soſtware cannot be configured to suit individual business processes.
• Example: firmware-based applications, COTS, instruments.
• Validation: the package itself. Record version and configurations, verify operations against user requirements. Consider auditing the vendor. Risk-based tests of application: test macros, parameters, and data integrity.
Category 4: Configured products • Definition: soſtware, oſten very complex, that can be configured by the user to meet the specific needs of the business process. Soſtware code is not altered.
• Example: LIMS/SCADA/MES/MRP/ EDMS/clinical trials, spreadsheets and many others (See GAMP5).
• Validation: life cycle approach. Risk- based approach to supplier assessment and other testing. Record version and configuration, verify operation against user requirements. Make sure SOPs are in place for maintaining compliance and
fitness for intended use, as well as for managing data.
Category 5: Custom applications • Definition: soſtware, custom-designed and coded to suit the business processes.
• Example: it varies, but includes all internally/externally developed IT applications, custom firmware and spreadsheet macros. Parts of Category 4 systems may be in this category.
• Validation: the same as Category 4, plus more rigorous supplier assessment/audit, full life cycle documentation, design and source code review.
System validation
Te validation itself usually needs to be divided into more manageable pieces. One way is to use the ‘4Q method’. Tis comprises development qualification (DQ), installation qualification (IQ), operation qualification (OQ), and performance/process qualification (PQ). What the chosen manageable pieces or phases are is up to the individual, but it must be described in the validation plan. Tis defines the phases, the input and output of the phases, and which documents will be created during the phases. Typically, this will be a phase plan including test plans, the testing itself and the test documentation, and the phase report.
DQ – development qualification Tis includes writing the user requirements specification, choosing the system, auditing the supplier if the risk assessment says that this is needed, and implementing the system.
www.scientific-computing.com/BASL2015
Tis follows the same line of thought
LDprod/
Shutterstock.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 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44