Review by exception: what changes for the QA reviewer, the operator and the Qualified Person

Monday morning, a QA office next to a biologics suite. The reviewer opens the electronic batch record of a buffer preparation that finished over the weekend. A year ago this meant a printout as thick as a phone directory, a pad of sticky notes and most of a day. Today the screen shows three exceptions, each already commented by the operator on shift, one already countersigned by a supervisor. She clears them in twenty minutes. Then, and she would not say this in a meeting, she scrolls back through the steps the system did not flag, the ones she no longer has to read. Just to be sure.

That small gesture is what this article is about. Review by exception works: it removes a queue that kept batches in quarantine for weeks. But it changes three jobs at once, the operator’s, the reviewer’s and the Qualified Person’s, and few projects plan for that. The software gets a validation plan. The people get a training session.

What review by exception actually changes

In a classic paper or hybrid process, the record is reviewed after the batch, line by line, by production and then by quality. Every entry gets the same attention, which in practice means none gets quite enough. Review by exception turns this round. While the batch runs, the MES or electronic batch record checks every step against predefined rules: limits, sequence, signatures, material status, alarms, manual interventions. Anything that breaks a rule is raised as an exception, with its context, and sent to someone who has to explain it and close it. The rest is not presented for review.

The idea is not new. ISPE’s GAMP good practice guide on manufacturing execution systems gave it an appendix in 2010, and the Second Edition of GAMP 5 (July 2022) added material on review-by-exception reporting. What has changed is that the review now happens during the batch rather than weeks after it.

In a 2020 InTech feature, a life sciences product manager at Emerson described one biopharmaceutical plant that made the move. By her account, release times fell from weeks to hours, operators and QA cleared most exceptions together on the floor before the batch ended, and QA could “auto-release” a share of batches on completion. The figures are the vendor’s. The last word deserves a pause, because on a European site it is wrong, and why it is wrong says a lot about where people still sit in the process.

What the rules ask, and what they leave open

The GMP texts do not prescribe review by exception. They say what the review must achieve and who answers for it, which leaves room for it as long as the design meets each requirement.

Two guidance documents describe the tool itself. The MHRA’s GXP data integrity guidance of March 2018 defines an exception report as a validated search tool that identifies and documents predetermined abnormal data or actions needing further attention from the reviewer, and expects every data review to end with a clear statement of whether issues were found. PIC/S PI 041-1, published in July 2021, names review by exception as one way to focus audit trail review on anomalous or unauthorised activity, once you have assessed which audit trails matter. Two words carry the weight: validated, and predetermined. An exception report only sees what someone decided, in advance, it should look for.

There is no such thing as auto-release

Under EU GMP, Annex 16 is explicit. Each batch of finished product must be certified by a Qualified Person before it is released for sale or supply, and until then it stays in quarantine. Annex 11 §15 adds that when a computerised system records certification, only Qualified Persons may certify, by electronic signature. A system can do a great deal around that act. It can assemble the evidence, show that no exception is open and, as Annex 16 §4.2 allows, act as the validated safeguard that keeps an uncertified batch out of saleable stock. The certification itself is not its to give.

In the US, §211.192 gives review and approval to the quality control unit, not to software. The unit may approve on the strength of a clean, validated exception report. A person still signs.

Real time release testing is not a counter-example. Under the EMA guideline of 2012, RTRT replaces end-product testing with validated process data where the marketing authorisation allows it, and the Qualified Person still takes the batch’s conformity into account before release. What one plant calls auto-release is, in European terms, a well-prepared certification. The difference shows on the day something has gone wrong unseen: it decides who is accountable.

The QA reviewer: from reading everything to judging what matters

Ask experienced reviewers off the record and they will admit they skimmed most of those thick reports. Nobody reads hundreds of pages with steady attention. Review by exception makes the skimming explicit and, with good rules, safer. The skill shifts from spotting a wrong figure to asking a better question about a figure that looks right.

What a reviewer still looks at, once the list is short:

• The exceptions themselves, properly. “OK as per operator” closes nothing. The reviewer judges whether the explanation holds up, whether product impact was assessed, and whether this is a deviation in disguise.
• The batch that is too clean. A complex batch with no exception at all is a signal, not a reward. Has a data source stopped feeding the system? Was a rule switched off during a recipe change?
• Manual entries and overrides. Values typed in, steps forced, sequence jumps acknowledged. These should always be exceptions by design, and the reviewer checks that they are.
• The same exception, again and again. One alarm cleared fifty times with the same comment is not fifty small events. It is one unresolved problem, and the reviewer is often the only person who sees the pattern across batches.

The real risk is complacency, and it creeps in. In the first months reviewers double-check everything, like the one in our opening scene. A year later the list is trusted, the habit of scrolling back has gone, and nobody remembers which rules were relaxed during the last change. Reading everything again is not the cure. A planned check is: a full review of a sample of batches, at a set frequency. PIC/S PI 041-1 asks for the same idea in its data governance review, using a sample of previously verified data to confirm the routine process still works.

The operator: comments written at the time

For operators the change shows on day one. Instead of noting an event on paper and leaving QA to discover it three weeks later, they are asked during the shift to explain an exception while the cause is still in front of them. Done well, this is the best data integrity improvement the site will make all year: contemporaneous, attributable, written by the person who saw it.

Done badly, it turns into pressure to clear. Once the open-exception count is discussed at the morning meeting, operators learn that a closed exception is a good exception, and comments get shorter. On a filling line the usual pattern is a recurring sensor exception closed with the same three words for months, until an engineer asks why the sensor keeps drifting.

Three things help. Measure the quality of comments, not only the time to close. Make it clear, from the supervisor up, that an exception is a fact to describe honestly, not a fault. And let operators escalate instead of closing, with severity levels that send serious exceptions to QA and production management for signature.

The Qualified Person: relying on what she did not read

The QP’s position is the most delicate. Annex 16 §1.7 already accepts that the QP relies on the pharmaceutical quality system for many checks, provided she has ongoing assurance that the reliance is well founded. Review by exception adds one more layer of reliance, and a big one: the QP certifies a batch whose detailed record nobody read in full, on the strength of rules written by a project team.

So the QP should ask, not for the batch record, but for the evidence behind the rule set: which risks each rule covers, how it was challenged, what has changed since, what the sample reviews found. In our experience, the QPs who are comfortable with review by exception sat in the rule-design workshops. Those handed a finished system ask for the full report “just this once”, every time.

What must be validated so that “no exception” means nothing to see

An empty exception list is evidence only if the rules are complete, correct and still running. Annex 11 §1 asks for risk-based decisions on validation, and §11 for periodic evaluation; between them they give the frame.

Two points cause most of the trouble. Missing data is the classic blind spot: if a historian tag freezes, a naive rule sees a perfectly stable value and raises nothing. And the rule set drifts. Every recipe change, new alarm or replaced instrument touches it, and unless rule maintenance is written into change control, the system slowly ends up checking a process that no longer exists.

Where to start

1. Write the review requirements before choosing a tool. What must a reviewer know to approve a batch, and which of it can a rule check?
2. Build the rule set in a workshop with QA reviewers, operators, process engineers and the QP, starting from the process risk assessment.
3. Define severity levels and routing: who may close what, and which exceptions need a QA or management signature.
4. Run seeded tests and a parallel period, full review and exception review side by side, and compare what each one found.
5. Put rule maintenance into change control, and the sample review into the periodic evaluation.
6. Train people for their new job, not for the screens: what a good comment looks like, what a too-clean batch looks like, when to escalate.

Five common mistakes

• Calling it auto-release. Under EU GMP the QP certifies, and the word in a URS or a slide deck sets the wrong expectations.
• Treating silence as compliance. A missing data feed produces no exceptions.
• Measuring only the time to close. It rewards short comments and hides recurring problems.
• Leaving the QP out of rule design. She will make up for it by asking for the full record.
• Validating the rules once. Without change control and periodic samples, they describe last year’s process.

Review by exception does not take judgement out of batch review. It concentrates it and moves it upstream, into the rules and into the people who keep asking what the rules cannot see.

References

• 21 CFR 211.192, Production record review, and 211.188, Batch production and control records. ecfr.gov
• FDA, Data Integrity and Compliance With Drug CGMP, Questions and Answers, guidance for industry, December 2018, Q8. fda.gov
• EudraLex Volume 4, Annex 11: Computerised Systems (in operation since 30 June 2011), §1, §9, §11, §15. health.ec.europa.eu
• EudraLex Volume 4, Annex 16: Certification by a Qualified Person and Batch Release (in operation since 15 April 2016), §1.1, §1.7, §4. health.ec.europa.eu
• PIC/S PI 041-1, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments, 1 July 2021, §5.6 and §9.6. picscheme.org
• E. Cook, “Digital transformation of batch review improves operations efficiency and release time”, InTech, September/October 2020, pp. 64-66 (the starting point of this article). isa.org