EU Annex 11 for US labs and device makers

The annex covers “all forms of computerised systems used as part of a GMP regulated activities”, and a computerised system is software and hardware that together do a job. Two duties follow: “The application should be validated; IT infrastructure should be qualified.” A system that replaces a manual step must not lower product quality, process control or quality assurance, and must not raise the overall risk of the process.

Shown by: A validation report for the application, qualification records for the servers, network or hosting under it, and, where a paper step was replaced, the risk comparison.

Risk management runs through the whole life of the system, weighing patient safety, data integrity and product quality. How far you validate and which data integrity controls you build are “based on a justified and documented risk assessment”.

Shown by: One written risk assessment per system that explains why validation went as deep as it did, and no deeper.

Process owner, system owner, Qualified Persons and IT work closely together. Everyone has the right qualifications, the right level of access and written responsibilities. The glossary defines the two owners: the process owner is responsible for the business process, the system owner for the system's availability, maintenance and the security of its data.

Shown by: A named process owner and system owner for each system, role descriptions, and training records that match the access each person holds.

When a third party provides, installs, configures, integrates, validates, maintains (remote access included), modifies or retains a system, or processes data, “formal agreements must exist” that state the third party's responsibilities (3.1). An in-house IT department counts the same way. Whether to audit a supplier is “based on a risk assessment” (3.2). The regulated user reviews the documentation that comes with off-the-shelf software against its own user requirements (3.3), and supplier quality and audit information is “made available to inspectors on request” (3.4).

This is the clause that reaches most US vendors and contract labs. How to qualify a cloud vendor is set out in Part 11 for cloud and SaaS systems.

Shown by: A signed quality agreement with every supplier that touches the system or its data, a supplier assessment, and either an audit report or the risk reasoning for not auditing.

Validation documents and reports cover the relevant steps of the life cycle, and the manufacturer can justify its standards, protocols, acceptance criteria and records from its risk assessment. The validation pack includes change control records where they apply and reports on every deviation found during validation.

Shown by: A validation plan and report that name the life-cycle steps covered, with each test deviation written up and closed.

An up-to-date list of all relevant systems and their GMP functions. For critical systems, a current description of the physical and logical set-up, data flows, interfaces, hardware and software prerequisites, and security measures.

Shown by: A system inventory with a GMP-impact column, and a system description (a data-flow diagram helps) for each critical system.

The user requirements specification describes what the system must do, is based on documented risk and GMP impact, and stays “traceable throughout the life-cycle”.

Shown by: A numbered URS (the URS template builds one) traced to tests in a matrix.

The regulated user takes all reasonable steps to make sure the system was developed under an appropriate quality management system, and the supplier is “assessed appropriately”. For bespoke or customised systems there is a process for formally assessing and reporting quality and performance measures at every life-cycle stage.

Shown by: Evidence that the developer works under a quality system (an audit, a questionnaire, certificates), and for custom code, the development and test records.

Test methods and scenarios are shown to be appropriate. Parameter limits, data limits and error handling get particular attention. Automated test tools and test environments have documented assessments of their adequacy.

Shown by: Test scripts that push limits and bad inputs, not only the happy path, and a short assessment of any automated test tool used.

When data moves to another format or system, validation checks that it is “not altered in value and/or meaning” on the way.

Shown by: A migration protocol with record counts and a sample of values compared before and after, signed off.

Systems that exchange data electronically with other systems have built-in checks that the data goes in and is processed correctly and securely.

Shown by: Interface tests in the validation pack: a record sent, a record received, a malformed record rejected.

Critical data typed in by hand gets a second check, by another operator or by a validated electronic means. How critical the data is, and what a wrong entry would cause, is covered by risk management.

Shown by: A list of the hand-entered critical fields and the second check on each (a witness signature or a validated range check).

Data is protected against damage by physical and electronic means, checked for accessibility, readability and accuracy, and “Access to data should be ensured throughout the retention period” (7.1). Relevant data is backed up regularly, and the integrity of the back-up and the ability to restore it are checked during validation and monitored periodically (7.2).

Shown by: A back-up schedule and a dated restore test, repeated on a set interval, not just once at go-live.

You can get clear printed copies of stored data (8.1). For records supporting batch release, a printout can show whether any data was changed since the original entry (8.2).

Shown by: A printout of a batch-release record that flags changed values, produced live in front of the auditor.

“Consideration should be given, based on a risk assessment” to building in a system-generated record of all GMP-relevant changes and deletions. The reason for a change or deletion of GMP-relevant data is documented. Audit trails are available, convertible to “a generally intelligible form”, and “regularly reviewed”.

Note the review duty: Part 11 asks for the trail but sets no review. What a trail must capture is covered in what an audit trail is in GxP.

Shown by: A reason-for-change field switched on, and dated records of trail review (the audit trail review checklist sets one up).

Any change to a system, configuration included, is made only in a controlled way under a defined procedure.

Shown by: A change control SOP and the change records for the last configuration changes, each with its impact assessment.

Systems are “periodically evaluated to confirm that they remain in a valid state and are compliant with GMP”. Where it fits, the evaluation looks at functions in use, deviations, incidents, problems, upgrade history, performance, reliability, security and validation status.

Shown by: A dated periodic review report per system that walks those topics and ends with a conclusion: still valid, or what must be revalidated.

Physical or logical controls limit access to authorised people; keys, pass cards, personal codes with passwords and biometrics are all named as options (12.1). How strict depends on how critical the system is (12.2). Creating, changing and cancelling access rights is recorded (12.3). Systems record who entered, changed, confirmed or deleted data, with the date and time (12.4).

Shown by: An access request and removal log, a current user list reconciled against staff, and one login per person.

All incidents, not only system failures and data errors, are reported and assessed. The root cause of a critical incident is found and becomes the basis for corrective and preventive action.

Shown by: An incident log for the system, with critical incidents linked to a CAPA record.

Records may be signed electronically. An electronic signature is expected to carry the same weight as a handwritten one inside the company, be “permanently linked to their respective record”, and include the time and date it was applied. It names no printed name or meaning on the signed record; Part 11's § 11.50 does, and the signature manifestation check tests that.

Shown by: A signed record showing the date and time, a test that the signature cannot be copied to another record, and a policy that e-signatures bind like handwritten ones.

Where a system records certification and batch release, only Qualified Persons can certify, the system identifies and records the person releasing, and “This should be performed using an electronic signature.”

Shown by: Role configuration that lets only QPs release, and a release record carrying the QP's e-signature.

For systems that support critical processes, there are arrangements to keep the process going if the system breaks down, such as a manual or alternative system. The time to switch over is based on risk, and the arrangements are documented and tested.

Shown by: A written fallback for each critical system and a record that it was tested, with the switch-over time.

Archived data is checked for accessibility, readability and integrity. Before relevant changes to the system (new equipment or software), the ability to retrieve the archive is ensured and tested.

Shown by: An archive retrieval test run after each upgrade or migration, with the records it pulled back.