Beyond the laboratory


Building a Smart Laboratory 2018


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: n Risk management to decide how important the system is in the process;


n Categories of soſtware to decide what needs to be done;


n Combination of risks and categories to decide what to do for this system; and


n Testing guide for how to test the system. Risk management


Identify regulated E-records and E-signatures: n 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: n Te classification of potential impact on


patient safety and/or product quality: is it high/medium/low?


32


Assess the risks of E-records: n Te impact and likelihood/probability of


problems being detected/happening: is it high/medium/low?


Implement controls to manage risks: n Modify processes, modify the system design; apply technical or procedural controls.


Monitor effectiveness of controls: n 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 n Definition: layered soſtware (i.e. upon which applications are built). Soſtware used to manage the operating environment.


n Example: operating systems, database engines, statistical packages, programming languages.


n Validation: record version and service pack. Verify correct installation.


Category 2: Tis category is no longer in use


Category 3: Non-configured products n 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.


n Example: firmware-based applications, COTS, instruments.


n 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 n 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.


n Example: LIMS/SCADA/MES/MRP/EDMS/ clinical trials, spreadsheets and many others (See GAMP5).


n 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 n Definition: soſtware, custom-designed and


www.scientific-computing.com/BASL2018


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