In January 2011 the updated version of EU GMP Annex 11 on computerized systems was published that became effective on 30 June 2011 (1). In April 2011 this column (2) reviewed Annex 11 and also Chapter 4 on documentation to see if this was Europe's answer to 21 CFR 11 on electronic records and electronic signatures (3). In this "Questions of Quality" column I want to review the technical requirements of the new version of Annex 11 to see how the software commonly used in regulated laboratories meets these requirements and where they don't. To begin, I had better explain what I mean by a technical requirement of software.
A technical requirement is where compliance with a regulation is met through a feature or function in the software that has been designed, engineered and tested by the vendor of the product. In doing this, a vendor should seek the opinion of customers who although they work to the same regulation will tend to have different individual interpretations of how the software should comply with the regulations. The role of the vendor would be to sift through these interpretations, which will occasionally differ, to specify the software so that there is a generic approach to compliance. Where companies have different views then a vendor may use software configuration to enable individual laboratories to implement their own interpretation of a regulation. Here some features can be turned on and others off, allowing different laboratories to implement their own interpretations of a regulation but at the same time allowing a vendor to sell a standard product. So in this column we are looking at how software should meet the technical requirements contained in the new version of Annex 11.
What Are Annex 11 Technical Requirements?
Of the requirements in Table 1, I am not going to discuss clause 15 release of a batch by a Qualified Person (QP) as this typically occurs outside of the laboratory and not many analytical scientists are QPs. Also, the requirement for archiving is subject for discussion in one or two "Questions of Quality" columns and therefore we will not discuss this any further. Therefore, this leaves the following sections to consider:
Looking through the list you will see that many of the topics are concerned with data integrity which is complementary to the discussion in my last "Questions of Quality" column Fat Finger, Falsification or Fraud? (4), so we will consider the discussions about data integrity we looked at there as well as what we shall cover in this column. We will therefore start in a boringly logical order with the lowest numbered clause and proceed in increasing numerical order.
Automated Data Transfer Checks between Systems
Looking on the bright side, if all the computerized systems in your laboratory are standalone, then you don't have to consider this section as you are condemned to life imprisonment with eternal transcription error checking instead of hard labour. Actually, considering what I have just written, there is probably not much difference between the two apart from the former being physical and the latter mental hard labour.
However, if you have seen the light and are linking your computerized systems together, e.g. a Chromatography Data System (CDS) with a Laboratory Information Management System (LIMS) then you will want to make sure that what was sent from the CDS was the same as received in the LIMS and vice-versa. This is not a regulatory requirement, it is simply good analytical science. However, as we can see in Table 1, Annex 11 pokes its nose in by requiring "appropriate built-in checks for the correct and secure entry and processing of data". Therefore, there needs to be software functions to ensure that there is no corruption or truncation of data between the sending and receiving computerized systems. Ideally, there would be an interface option available from one or other of the software vendors, typically the LIMS vendor. This should be a standard software module that transfers the data between the two systems or it could be configurable application to accommodate the requirements for any CDS. However, it should not be a oneoff module of code written specifically for your situation as this will be more difficult to support over time.
Don't forget that the interface between the two systems needs to be specified in a user requirements specification and tested in your validation of one or both systems.