Implementing eQMS in a GxP environment – digital progress with a focus on data integrity, Annex 11 and Annex 22

When GMP regulatory authorities audit digital quality management systems today, their attention is focused primarily on master data, access rights and timestamps. It is precisely these digital traces that determine whether an inspection proceeds smoothly or results in critical non-conformities relating to data integrity and computerised systems. In the following sections, you will learn which regulatory requirements govern the data integrity of an eQMS today, how the path leads from the User Requirement Specification to a validated system, and what the lifecycle entails once AI-supported functions are introduced.

Digital systems now permeate every aspect of pharmaceutical quality assurance, from document control to batch release. As this penetration increases, so does the complexity of what a single system must achieve in regulatory terms, and it is precisely this complexity that represents the real challenge of any eQMS implementation. Anyone setting up or upgrading an eQMS today is determining their own audit readiness for the coming years, often well beyond the day of implementation. It is therefore worth taking a closer look at the key building blocks of this process.

Annex 11, Annex 22 and the language of data integrity

In the EU, the Medicines Act, together with EudraLex Volume 4, forms the cornerstone of this field; within this body of legislation, Annex 11 on computerised systems, together with Chapter 4 on documentation, provides the actual framework for IT-supported quality systems. Furthermore, those serving the US market will encounter a related requirement from the FDA in 21 CFR Part 11 concerning electronic records and signatures, formulated in its own terminology but essentially committed to the same principle.

Annex 11 requires a comprehensive life-cycle approach, from specification through validation to ongoing operation, with particular emphasis on access controls, audit trails, data backup and regular reviews. The current draft further clarifies these requirements, for example with regard to security architecture, supplier oversight and data integrity throughout the entire system life cycle.

The draft of Annex 22, which is also new, addresses precisely this context and supplements the framework with requirements for artificial intelligence and machine learning in GMP processes. It focuses on the life cycle of models, the governance of training and test data, performance monitoring, and verification through qualified human assessment. Both documents are set against the backdrop of the same data integrity requirements as those established, amongst other things, in the form of the ALCOA+ principles: the requirement for data that is attributable, legible, contemporaneous timely, original, accurate, complete, consistent, durable and available.

Anyone drafting the User Requirement Specification for an eQMS would be well advised to enshrine these principles as mandatory regulatory requirements from the very first line, separate from the procedural requirements of the QMS and pharmacovigilance, and separate from the more desirable convenience features that tend to bloat a specification document.

The path from URS to validation

From this landscape of requirements, the actual project roadmap takes shape, step by step, following a sequence that the V-model has defined for years. In line with this model, the URS is followed by the functional and design specifications, each of which translates the previous concept into more concrete terms.

The design qualification alone enables a structured comparison of available systems and leads to a well-founded choice of the most suitable eQMS. Once this decision has been made, the provider’s qualification follows. This involves assessing the regulatory capabilities of the manufacturer or service provider, usually through audits or specially developed questionnaires for IT service providers. Here too, Annex 11 and Chapter 7 of the EU GMP Guideline remain the benchmark: the chapter on outsourced activities, which requires a written contract and the client’s right to audit for any collaboration with an external service provider. Particularly in the case of cloud-based or outsourced solutions, regulatory responsibility always remains with the pharmaceutical company itself, regardless of how many external parties were involved in the code.

GAMP 5 provides a possible reference framework for this – a roadmap, as it were – along which systems can be classified and the level of validation and scope of testing determined on a risk-based basis. Category 1 infrastructure software requires a more streamlined demonstration of compliance, Category 4 configured off-the-shelf software requires more, and Category 5 custom-developed software places the highest demands on documentation and testing. The more extensive the individual customisations of an eQMS, the higher the system moves up this scale – and with it, the validation effort.

This classification forms the basis for a validation plan. A test system takes shape, and Installation Qualification, Operational Qualification and Performance Qualification jointly verify whether the system actually delivers what the requirements promised.

The risk analysis determines the scope of the tests. Conversely, the test results are fed back into the revision of this risk assessment and form part of the validation report, which summarises the system’s suitability in a single, robust statement.

The life cycle does not end after validation

Signing the validation report is by no means the end of a system’s life cycle. Annex 11 and the draft Annex 22 require periodic reviews, ongoing monitoring of relevant quality metrics, audit trail reviews and a traceable assessment of the impact of any change on the validation status. Updates to the system may necessitate a targeted revalidation of the affected functions, proportionate to the actual scope of the change.

As soon as an eQMS incorporates AI-supported functions – such as for trending, classification of deviations or prioritisation of CAPA actions – the requirements set out in Annex 22 also apply. These relate to the governance of training and test data, model versioning, logical performance metrics and the assurance that critical decisions must always be subject to a qualified human assessment. A modern eQMS approach integrates traditional CSV practices – that is, tried-and-tested methods of Computerised System Validation such as risk-based requirements definition, documented testing, traceability, change control and regular reviews – with a structured, documented AI model lifecycle: two approaches that must increasingly work in tandem.

TentaConsult: your expert in eQMS validation

Anyone who regards the introduction of an eQMS as merely an IT migration underestimates the depth of the current regulatory changes, which are taking shape as a consistent governance framework in Annex 11, the draft Annex 22 and the practical application of the ALCOA+ principles. A consistent, risk-based lifecycle approach that brings these three strands together and sustains them over the years remains crucial.

Our experts at TentaConsult support you from the very first line of the User Requirement Specification, through supplier qualification, right through to the implementation of validation, including documentation.

Please contact us and we will be happy to assist you.