Batch Review by Exception (BRBE)

Batch Review by Exception (BRBE) is a batch-record review practice that uses validated electronic processing and predefined exception rules to focus human review on flagged issues while preserving access to complete batch evidence. Applied within an electronic batch record, it brings the broader review-by-exception approach to a specific batch and its supporting records.

The aim is to reduce repetitive examination of routine entries—not to reduce the completeness of the batch record. Entries that pass configured checks remain part of the evidence and accessible to reviewers. An exception can be a process departure, missing evidence, an execution error or a relevant record change; it is not limited to a result outside specification. A clean queue therefore means only that the configured checks found no unresolved flags, not that every possible quality issue has been excluded.

BRBE never transfers the quality unit’s responsibility for release decisions to software. Keep batch-review completion—the completion of assigned checks—distinct from quality disposition, the authorised decision about the batch. QP certification is a separate responsibility where applicable: for EU medicinal products, Annex 16’s scope addresses certification by a Qualified Person and batch release. Closing an exception queue is not itself disposition or QP certification; those decisions remain with authorised people.

Efficiency is a possible operational benefit, not a promised outcome or assurance of product quality. Measure review effort, investigation workload and missed-exception findings against the previous review method before claiming an improvement.

These terms describe different layers of batch control: the record environment, the review method, investigative work and authorised decisions. BRBE connects those layers for a particular batch; it does not make them interchangeable. The comparison below describes operational usage, with jurisdiction-specific references identified separately.

In practice, keep review completion, investigation closure and disposition as separate statuses. For US drug products subject to 21 CFR 211.192, production and control records require quality control unit review and approval before release or distribution. An empty exception queue therefore cannot stand in for that approval.

Before selecting exception rules, build a review-scope matrix for the complete batch record, including attachments and referenced evidence. The following is an operating-design approach, not a regulatory classification. Assign review methods to record sets rather than declaring the entire batch “exception-only.”

Define “full review” for each record set: the evidence examined, questions answered, supporting records consulted and completion recorded. It means completing that defined examination, not necessarily rereading every line by one reviewer. Different portions of one record may need different methods.

For each exception, examine the original observation, surrounding execution context, relevant changes, investigation evidence and the conclusion affecting the batch. Link any associated deviation; closing a queue item alone does not explain its disposition.

Require the operating design to name a reviewer, review method and completion evidence for every record outside automated coverage. The scope owner should document why each category suits its assigned method, including boundaries between separate processes and how their findings reach the batch reviewer.

Treat BRBE as an operating practice built on validated systems, not a named regulatory approval route. Map the applicable obligations first; then justify how exception-based review supports them. The references below distinguish binding US drug regulations from official guidance.

21 CFR 211.188 establishes the complete-record baseline: records must be prepared for each batch and contain complete production and control information. A filtered review view is therefore not a substitute for the underlying record.

FDA's data integrity guidance, question 7 includes audit trails within the production and control records reviewed and approved by the quality unit (see the introduction on why that responsibility stays with people). Question 8 of the same guidance advises matching audit-trail review frequency to prescribed data-review frequency; where none is specified, it recommends process knowledge and risk assessment, including data criticality, controls and product-quality impact. Build that reasoning into the audit-trail review workflow, rather than assuming a universal interval.

Annex 11, sections 9 to 11 address risk-based audit-trail design and regular review, procedural control of system and configuration changes, and periodic evaluation of continued validity and GMP compliance. Connect exception-rule maintenance to change control; these sections specify no fixed evaluation interval.

For QP decisions, check current applicable Annex 16 text and product and territorial scope. As a practice safeguard, examine registered specifications, investigation conclusions and root-cause correction before escalating an unexpected deviation for assessment—not as blanket permission to certify.

Supplements, food, devices and chemicals need separate jurisdiction-and-product mappings; do not transfer these drug references. The proposed operating controls are practice, while software examples are implementation support—not independent regulatory authority.

Treat these controls as an intended-use, risk-based implementation design, not a regulatory endorsement of BRBE. Document the records covered, exclusions, accountable process and system owners, controlled procedures, reviewer qualifications and acceptance evidence. Demonstrate performance before relying on the queue. FDA’s drug CGMP guidance, question 3, describes intended-use validation controls addressing software, hardware, personnel and documentation.

Challenge detection, not just calculation

Challenge ordinary passes, genuine failures, boundary values, missing inputs, invalid units, edited entries, duplicated messages and unavailable interfaces. Include deliberately seeded exceptions and compare expected findings with actual output: a missed exception is a validation failure even when displayed calculations are correct. Link requirements, rules and results through a CSV traceability matrix.

For each rule, retain its identifier, applicable product or process, input fields, comparison logic, units, severity, routing, effective version, approval and linked test evidence. Define four distinct evaluation results:

• Pass: evaluation completed against the applicable rule and met its criteria.
• Fail: evaluation completed and breached its criteria.
• Not evaluated: evaluation has not occurred, including where required inputs are missing.
• Processing error: evaluation could not complete reliably because of a technical or execution problem.

Keep incomplete evaluations explicitly unresolved; neither an empty queue nor absence of a flag establishes a pass. Preserve the evaluation result separately from any later reviewer disposition.

Make integrity evidence reviewable

Separate process-value rules from checks for changes, deletions, identity, sequence and missing evidence. Route relevant history into an audit-trail review workflow, not merely a count of edits. For EU medicinal-product GMP systems, Annex 11, section 9 says audit trails should be available, intelligible and regularly reviewed.

Control access; separate rule configuration from review responsibilities where risk justifies it. Protect original entries, retain traceable changes and enable retrieval of the complete review context: source records, applicable rule version, evaluation output, relevant history and reviewer decisions.

Maintain reliance—and withdraw it when necessary

Use change control to reassess system and rule performance after relevant changes. During operation, examine missed exceptions, incidents and reviewer findings at a justified frequency. For EU medicinal-product GMP systems, Annex 11, section 11 calls for periodic evaluation of continued validity and GMP compliance.

Define failed-prerequisite handling in the procedure: stop reliance on the exception summary, identify and assess affected records, and use a documented alternative review method. Assign authority for restoring reliance only after the failure and its impact have been addressed.

Use this sequence as an operating model, with handoffs defined in the site procedure. The responsibilities below are illustrative assignments, not universally prescribed job titles.

1. Establish the review baseline. Before execution, production confirms the approved batch-review scope; system or rule owners identify the effective rule versions and applicable record sources. Retain that baseline so reviewers can establish which controls applied to this batch.
2. Capture execution evidence. Production records activities and resolves immediate prompts through the defined procedure. Execution checks produce contemporaneous evidence such as limit-check results, acknowledgements and intervention reasons. Later batch-level evaluation assesses the assembled record, including relationships that cannot be evaluated until relevant operations finish; retain its results and evaluation time separately.
3. Reconcile coverage before handoff. Production and system owners account for expected records and evaluation results against the approved scope. Distinguish evaluated records from missing, failed or not-yet-evaluated inputs. Pass the linked record set and unresolved coverage issues to quality reviewers, rather than treating silence as successful evaluation.
4. Assess linked exceptions. Quality reviewers triage each issue using the surrounding batch context and assign investigators where appropriate. Link contextual assessment, investigation, corrective action, reassessment and documented closure to the triggering evidence. Include relevant changes through the audit-trail review workflow; closing a task should not substitute for recording its batch-impact conclusion.
5. Complete review and decide disposition. Quality reviewers check that the batch record is complete, evaluation statuses are resolved, linked investigations have appropriate conclusions, and outstanding review obligations are identified and addressed before review completion. Record the decision basis and hand off to authorised disposition personnel. Queue completion is not release approval; the quality unit retains its release-decision responsibility.
6. Control subsequent changes. If evidence changes after review, identify affected records, evaluations and decisions. Under the operating procedure, invalidate or reopen the relevant review state, preserve the previous approval history, and obtain authorised reassessment before relying on that review again.

As an operating practice, assess interface completeness separately from batch exceptions. An EBR might receive results through a laboratory interface, process measurements through an equipment-historian interface, and deviation status through a quality-management interface. A clean summary can conceal evidence that never arrived.

Define an interface contract covering batch and source-record identifiers, source timestamps with time-zone meaning, units and conversion rules, result status, unique message identity, acknowledgement semantics, and expected record counts. Specify how expected records are identified for each batch and how revisions are distinguished from duplicate deliveries.

• Flag late arrivals and incomplete transfers against the expected record set; do not interpret absence as a passing result.
• Detect duplicate deliveries without silently discarding legitimate revisions, and quarantine incorrect or ambiguous batch associations.
• Check unit conversions against source values. Interpret timestamps consistently, distinguishing event time from receipt time and accounting for clock offsets.
• Treat transport success as delivery confirmation, not proof of usable, correctly associated evidence. Reconcile unique expected records and their required status, not merely the number of received messages.

For controlled recovery, preserve the failure history, identify affected batches and records, then restore or retransmit evidence without overwriting originals. Reconcile recovered records against their sources, document duplicates and revisions, and rerun affected exception evaluations. If recovery changes an already reviewed record set, use the reopening mechanism described above rather than silently refreshing its review status.

Document a fallback for unavailable systems or interfaces: who activates it, which activities may continue, where temporary records are kept, and how batch identity is maintained. Before normal exception-based processing resumes, reconcile temporary records with restored systems, resolve gaps and duplicates, and document completion of recovery checks.

All three cases are hypothetical. Limits and routing decisions are site-defined assumptions for these examples, not regulatory thresholds or product specifications. Each case separates what an automated check detects from the evidence a reviewer needs to reach a conclusion.

Case 1: Zero failures, incomplete coverage

Assume 1,000 distinct expected record checks: 992 completed passes and eight not evaluated. Evaluation coverage is 992 ÷ 1,000 × 100 = 99.2%. A display showing zero failed checks describes only evaluated results; it leaves eight unresolved checks. The denominator remains all expected checks, not just those the system completed.

Apply the prerequisite and recovery controls covered above: identify the eight checks, map them to affected evidence using requirements traceability, and establish why evaluation did not occur. Under this example's routing rule, the review remains incomplete until evaluation finishes or an authorised alternative review is documented. Evidence needed: the expected-check inventory, evaluation statuses, affected source records, recovery results or alternative-review findings, and the reviewer's recorded conclusion.

Case 2: Yield outside the example range

Assume a theoretical yield of 200 kg, an actual yield of 190 kg and a site-approved example range of 96%–102%. Yield is 190 ÷ 200 × 100 = 95%, one percentage point below the lower limit. The rule detects a yield exception; it does not establish whether the cause is material loss, a weighing error or an incorrect input.

Route the exception for cause and batch-impact assessment, supported by yield reconciliation. Acceptance, rejection and QP certification are not automatic outcomes. Evidence needed: the approved calculation basis, original mass records in kilograms, accounted transfers and losses, relevant equipment checks, investigation findings and the authorised assessment of batch impact.

Case 3: An edited result still passes

Assume an approved example pH range of 6.5–7.0 and a recorded value changed from 6.7 to 6.9. pH is dimensionless. Both values pass the range check, but neither passing result establishes the reason, authority or evidence for the edit. Assume the site's routing rule flags result changes independently of range failures.

Review the edit in the batch execution history. Evidence needed: original and revised values, user identity, timestamps, recorded reason, applicable editing authority, supporting instrument or laboratory records, and a documented conclusion on the change's validity and batch impact.

These practical review-design checks test what the queue may hide. A low exception count, high closure rate or attractive dashboard is not, alone, evidence of effective review.

A justified false-positive classification explains, with retained evidence, why a finding does not represent the targeted problem. It is not permission to change or suppress a rule merely to remove inconvenient findings; assess rule changes separately through controlled approval.

For missing data, use the completeness and recovery controls covered above. Bring recurring review-design weaknesses into management review.

Use these practice-based readiness gates to decide whether the proposed BRBE operating method is ready for adoption.

1. Scope and ownership: Create a review-scope inventory mapping records and checks to exception-supported or comprehensive review. Document each rule’s owner, rationale, version and approver, alongside responsibilities for reviewing unresolved items.
2. Evidence readiness: Assemble intended-use validation evidence, interface reconciliation results and reviewer training records. Put exception handling, escalation and reopening procedures in a controlled SOP. Demonstrate a tested fallback method before relying on the queue.
3. Rule testing: Challenge boundaries, missing inputs, edited data and failed interfaces. Preserve expected and actual results. Establish discrepancy categories—missed exceptions, unevaluated checks, false positives and inconsistent dispositions—and risk-based acceptance criteria before assessing pilot results.
4. Pilot operation: Select representative batches and challenging scenarios using a documented risk justification. Compare exception-supported review with an independent, more comprehensive review. Measure unevaluated checks, independently detected missed exceptions, false-positive burden, reopened reviews and investigation ageing. Resolve unexplained coverage gaps and missed critical exceptions before adoption; assess remaining discrepancies against predefined criteria.
5. Authorised adoption: Obtain documented approval from authorised quality personnel, with process and system owners confirming readiness and QP involvement where applicable. Record approved scope, residual risks and fallback conditions. Method approval is separate from batch disposition.
6. Continued assessment: Assign authorised personnel to approve method changes through change control. Reassess after revised processes, recipes, specifications, interfaces, permissions or rule logic, and when performance trends question reliability. Set review frequency by risk rather than a universal interval.

Maintain a batch-level evidence index connecting batch identity, applicable review scope, source records, effective rule versions, evaluation results, exceptions, investigations and signed conclusions. Link the batch execution history to the authorised decision in the electronic release record.

Use this conceptual relationship model—not an application database schema: batch → review scope → source records; source record + effective rule version → evaluation result; exception → investigation → signed conclusion. Preserve links for unflagged results too. Can a reviewer reconstruct what was recorded, which rule version evaluated it, what changed and why the conclusion followed?

For US drug CGMP records, FDA guidance, question 1(b), recommends retaining data with the metadata needed to reconstruct the activity. For electronic-copy considerations, consult question 9. Keep those considerations separate from any assumption that a static report replaces the source record.

Package controlled review exports with identifiers and generation dates, readable audit information, and retrievable links to external evidence. Preserve access to original evidence and relevant metadata. Define retrieval ownership and retention arrangements against the applicable record obligations, including evidence held outside the batch system.

Inspection-readiness check: select one exception and one unflagged record; trace each through scope, evaluation and decision evidence.