Building a Smart Laboratory 2017


Beyond the laboratory


a part of the process and must therefore be validated as well. Te industry asked the US Food and Drug Administration (FDA) how it would handle electronic signatures, and accordingly 21 CFR Part 11 saw the light in 1997. Te surprise was that most of the two- page document was about electronic data, and only a little about signatures. Tis, however, does make sense. How can


scientists use an E-signature if they are not sure that the data is (and will be) valid? Tey can’t; they need to have control of your data before they can sign it electronically. Te EU also came up with an equivalent to 21 CFR Part 11, namely the EU GMP Annex 11. Tis was revised in 2011 but does not improve on the first version. But a really good document covering electronic data and signatures is yet another document numbered 11, the PIC/S PI 011.[7]


Tis is a 50-page document


with the same requirements as Part 11, but it includes also a lot of explanations. PIC/S is the organisation for European pharma inspectors. Tey do stress that this document is not a regulatory requirement, only an 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


www.scientific-computing.com/BASL2017


more validation than low-risk systems.[8] Tis follows the same line of thought 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: l Risk management to decide how important the system is in the process;


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


l Combination of risks and categories to decide what to do for this system; and l Testing guide for how to test the system.


Risk management


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


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


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


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


Implement controls to manage risks: l Modify processes, modify the system


design; apply technical or procedural controls.


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


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


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


31


sfam_photo/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