BRBEBatch Review By Exception

Batch Review by Exception (BRBE) is a release model in which the electronic batch record system reviews every step of every executed batch automatically against the master record, the specifications and the configured rule set. When every step passed every rule, the QA reviewer sees a green record and signs the release. When one or more steps broke a rule — a missed time window, an out-of-range value, a missing signature, an out-of-sequence event — the system flags those steps as exceptions and the QA reviewer's work is to disposition the exceptions, not to re-read the whole record.

The premise is that 90% or more of the lines in a typical batch record are routine and add nothing to the QA decision; the value of human review is concentrated in the exceptions. BRBE refactors the QA workload around that observation. Done well it cuts release cycle times from three to seven days down to four to eight hours, freeing QA capacity for the deviations and CAPAs that actually need human judgement.

21 CFR 211.192 requires that all production and control records be 'reviewed and approved by the quality control unit to determine compliance with all established, approved written procedures before a batch is released or distributed.' The regulation does not specify how the review is performed; it specifies what the review must conclude. EU GMP Chapter 6 and Annex 11 carry the same logic — the system must produce evidence of compliance, the QP signs the certification, and the form of the underlying review is allowed to evolve with the technology.

The FDA Data Integrity Guidance and the EMA Data Integrity Guideline both encourage risk-based review of audit trails — explicitly recognising that 100% manual review of every audit-trail entry is neither sustainable nor a good use of QA time. BRBE is the natural operationalisation of that recognition.

BRBE works because every step of the batch is compared against a defined rule set. The rules are not arbitrary; they are derived from the validated control strategy, the MMR, the specifications and the regulatory requirements. A 'pass' means every rule was met; an 'exception' means one or more rules were not. The richer the rule set, the more value BRBE delivers — and the higher the validation burden on the rule engine itself.

Categories of rules

• Identity rules — material identifier matches MMR (scan-verified), equipment used is qualified for this process, operator is trained for this step.
• Quantitative rules — value within range, calculation result within tolerance, yield reconciliation within ± expected.
• Sequence rules — step ran after its predecessor, no unauthorised re-execution, no out-of-order events.
• Time rules — step completed within window, hold time below maximum, decay correction valid.
• Signature rules — every required signature collected from a uniquely-identified, trained user; two-person checks where required.
• Audit-trail rules — no unexpected edits, no deleted entries, every change carries a Part 11–compliant reason.
• Cross-system rules — LIMS results match BMR entries; WMS lot status matches batch consumption; MES timestamps match instrument timestamps within drift tolerance.

Because BRBE moves a regulated decision (which steps need human review) from a human to a system, the rule engine itself is GxP-critical and must be validated under GAMP 5 / CSA. The validation effort is not theoretical: every rule must be traced to its requirement, every rule must have a test that exercises both pass and fail paths, every change to a rule must flow through change control with regression testing, and the engine itself must be qualified under IQ/OQ/PQ before live use.

1. User requirements specification (URS) defining the rule set and the exception-handling behaviour.
2. Functional specification documenting the rule engine architecture and decision flows.
3. Risk assessment per ICH Q9 / Annex 11 §1 — what happens if a rule fails to fire, what happens if a rule fires falsely.
4. Configuration qualification (CQ) for each rule, with positive and negative test cases.
5. PQ runs against representative batches including deliberate exceptions to confirm exception detection.
6. Change control on rule changes with full regression after each addition.
7. Periodic review of the engine performance — exception rate by rule, false-positive rate, missed-exception audits.

Under BRBE the QA reviewer's queue is structured around exceptions, not batches. A typical morning queue might contain 12 batches: 9 with no exceptions (release-ready, the reviewer signs the certification after spot-checking the assembled evidence), 2 with low-severity exceptions (a missed time window with the operator's documented justification, a manual-add slightly above the tolerance band with an approved deviation), and 1 with a high-severity exception (an OOS in-process result that requires investigation before disposition).

• Open the exception list, not the full batch record.
• Read each exception with the system-assembled context: rule, expected value, observed value, operator entry, related deviations.
• Disposition each exception: accept with rationale, reject the batch, return for deviation, escalate to MRB, or open a CAPA.
• Sign the disposition; the system propagates the decision into the release readiness state.
• Sign the release certification when every exception is closed and the batch is fit for release.

The QA workload shifts from 'reading lines' to 'making judgements,' and the time saved is reinvested in trend analysis, supplier reviews, CAPA effectiveness checks and the deeper investigations that previously got squeezed by release pressure.

The 2018 FDA Data Integrity Guidance and the 2016 MHRA equivalent both make clear that the audit trail must be reviewed before release of every batch — but neither requires line-by-line review of every audit-trail entry. The phrase used is risk-based review. BRBE operationalises this by running audit-trail-specific rules: any signature change after initial entry, any deleted entry, any value change with a generic 'correction' reason, any change made by a different user from the original signer, any change outside the original step window. Each of these surfaces as an audit-trail exception alongside the process exceptions, and is dispositioned with the same rigour.

• Rule set never reviewed — exceptions stop firing because the process has shifted, not because the process is clean.
• Severity tiering set so generously that everything looks low — QA dispositions in seconds without engaging with the underlying signal.
• Disposition rationales become free-text 'reviewed and accepted' without specifics — Part 11 attribution but no content.
• Audit-trail rules limited to deletions and edits — missing the 'same user, different step' patterns.
• Exception dispositioned without linkage to deviation when severity should have triggered one.
• Change control on rules done lightly — a rule change should regression-test the next 50 batches against the new logic.
• Engine performance not periodically reviewed — the system became a rubber stamp and nobody noticed.
• Reviewer training out of date — the people closing exceptions do not know what each rule is protecting against.

Pharmaceutical solid dose

BRBE is mature in this space. Typical exception rates: 10–15% of batches have at least one exception, 1–2% have a severity-high exception requiring deviation. The biggest gains come from automated yield reconciliation, IPV completeness checks and tablet-press parameter trending.

Biologics and aseptic fill

Higher exception rates (15–25%) reflect the larger number of in-process controls. Bioburden, endotoxin, fill weight, CCIT and environmental-monitoring data all flow into the rule engine. The QP certification under Annex 16 is the named release event; BRBE assembles the QP's certification pack automatically.

Medical devices and IVDs

BRBE on eDHRs under 21 CFR 820 and ISO 13485 is becoming common. Device-specific rules include design-history-file linkage, UDI consistency, sterilisation-cycle parameters and verification-test pass status.

Food and dietary supplements

Under 21 CFR 117 and 21 CFR 111, BRBE focuses on allergen segregation evidence, identity verification, label print verification and metal-detection / X-ray rejection logs. FSMA 204 critical-tracking-event data flows into the same rule engine.

V5 ships with a validated BRBE engine that compares the executed batch record against the approved MMR, the associated specifications and a configured rule library. The rule library is partitioned by industry and product type, version-controlled, and exposed in the change-control workflow so that every rule edit is itself a controlled change. At release the QA reviewer sees a single exception list ordered by severity, with the assembled context for each exception in one view.

• Validated rule engine — IQ/OQ/PQ qualified; every rule traceable to its requirement and tested with positive/negative cases.
• Severity tiering with controlled criteria — downgrading a severity-high exception requires a documented justification.
• Audit-trail rules first-class — same-user different-step, off-hours edits, generic-rationale changes all surface as exceptions.
• Automatic deviation creation when configured exception types fire.
• Disposition propagation — accepted exceptions update the CPV dataset; rejected exceptions block the release until closed.
• Periodic engine review reports — rule firing rate, false-positive rate, exception aging.
• QP / QA release certification with the assembled evidence pack attached and immutably linked to the batch.