Review by Exception & Digital Batch Release Case

Every pharmaceutical manufacturing site runs on a handful of systems that were never designed to talk to each other. The LIMS holds the results. The batch record holds the execution. Deviation management holds what went wrong, and training records hold who was qualified to do it. Each one is validated. Each one is correct. And none of them, on its own, answers the only question that matters on a Tuesday morning: which batches can we release today?

So somebody builds a spreadsheet. It works for years, in most cases. Quality, production and supply chain all reference it, external partners feed into it, and the daily rhythm of the site quietly organises itself around a file that nobody validated and one person maintains.

Then the volume changes. A new product transfers in, or a commercial launch lands, and the number of batches moving through review rises by an order of magnitude rather than a percentage.

At that point, the request that reaches IT or an external partner is almost always the same: can you add some automation and alerts to the spreadsheet? It is a reasonable ask, and it is the wrong project.

To understand why — and what the right project looks like — we need to start with what batch release actually involves, and where the time really goes.

Key takeaways

• Review by exception releases conforming batches on system evidence and reserves full human review for batches with deviations, incomplete records or out-of-specification results;
• The bottleneck in batch release is rarely the technical review  it is assembling current status across LIMS, MES, EBR, deviation management and training records;
• Automating the spreadsheet treats the symptom: coordination effort scales faster than batch volume, and an unvalidated status file that drives disposition is already in 21 CFR Part 11 and Annex 11 scope;
• Batch record review and batch disposition are different acts exception-based review changes the first; the Qualified Person’s release decision is unchanged;
• The blocking question is not tooling but criteria: what counts as an exception at your site, and can you prove it to an inspector.

What batch release involves, and why it takes so long

Batch release is the process by which a manufactured batch is assessed against its specifications and formally judged fit for supply. In practice it is less a single act than a chain of confirmations, each one drawing on a different system and a different function.

A typical release decision depends on:

• The executed batch record, complete with in-process checks and signatures;
• Analytical results from QC, held in the LIMS;
• Any deviations raised during manufacture, and their closure status;
• Environmental monitoring data for the relevant areas;
• Confirmation that personnel involved were trained and qualified;
• Equipment calibration and cleaning status.

None of that is optional, and none of it is the bottleneck. The bottleneck is assembly  the work of pulling those six things into one view and confirming that each is current. That work is invisible in the procedure. It shows up nowhere in the batch record. But it is where the hours go.

This is why sites that measure their release cycle time are often surprised by the result. The technical review of a clean batch may take under an hour. The elapsed time from batch completion to disposition can run into days, and most of that gap is coordination, not analysis.

Understanding that distinction is what makes the next question answerable.

Why automating the spreadsheet fails at scale

Upgrading the spreadsheet is the intuitive fix. Add alerts, add conditional formatting, perhaps a macro that flags overdue items. These changes are cheap and quick, and they address the symptom the site can see. They do not survive a ramp-up, for three reasons.

Coordination cost rises faster than volume

Fifteen times the batches is not fifteen times the data entry. It is fifteen times the data entry, plus the meetings, plus the status chasing, plus the recurring question of whether the numbers on screen are current.

A site spending roughly two hours a day on release coordination today does not simply spend thirty tomorrow. The process becomes unworkable well before that point, because the people doing the chasing are the same people who have to review and release product. There is no version of this where the coordination scales and the review does not suffer.

A spreadsheet can only reach so far into validated systems

Every automation bolted onto the file increases its dependence on data it cannot reliably pull. Some fields update; others are typed in. The result looks automated and is still fed by hand — which is more dangerous than an openly manual process, because people stop checking a tool that appears to be maintaining itself.

A tool that drives release decisions is in regulatory scope

Once a status view is how the site decides what is ready for disposition, the question of whether it is qualified, audit-traced and compliant with 21 CFR Part 11 stops being theoretical. Most sites carry this exposure already and are aware of it. A ramp-up is simply the moment it becomes visible.

If the spreadsheet is not the answer, the alternative is not a bigger spreadsheet. It is a different review model.

What is review by exception?

Review by exception is a batch review model in which only batches with deviations, incomplete records or out-of-specification results receive full human review. Batches that ran inside their parameters, with complete records and no open deviations, are released on system evidence rather than page-by-page reading.

The shift sounds small and is not. Under a conventional model, reviewer attention is distributed evenly across every batch regardless of whether anything happened. Under exception-based review, attention concentrates where something did.

The practical consequences:

• Review effort scales with the number of exceptions, not the number of batches;
• A volume increase no longer requires a proportional increase in QA headcount;
• Reviewers spend their time on investigation rather than confirmation;
• Problems surface earlier, because the system flags them rather than waiting for a human to reach that page.

The principle is not foreign to regulators. ICH Q10 describes a pharmaceutical quality system built on maintaining a state of control, with monitoring feeding back into process understanding a model that assumes an organisation can distinguish a conforming batch from a deviating one on evidence, rather than treating every page as equally likely to contain a problem.

What regulators do expect is that you can defend the distinction. Which raises a question that trips up many implementations.

Batch record review and batch disposition are not the same thing

This distinction decides what can safely be automated, and it is worth stating plainly because the two terms are often used interchangeably.

Batch record review is the examination of the executed record and its supporting data: in-process checks, deviations, analytical results, calculations and signatures.

Batch disposition is the regulatory decision to release or reject the batch, made by the Qualified Person or the designated responsible individual.

Review by exception changes the first. It does not remove the second. The disposition decision remains with the named person who takes responsibility for it what changes is the completeness and timeliness of what they are handed.

A site that blurs this in its procedures will struggle to explain the model during an inspection. A site that keeps it explicit finds it considerably easier to defend, because the answer to “who released this batch?” is unchanged.

Where electronic batch records fit

An electronic batch record captures execution digitally rather than on paper, with the data structured enough to be queried rather than read. Sites running EBR are structurally closer to exception-based review, because a conformance determination can be made against structured data instead of a scanned page.

But EBR is not a precondition, and this is where a good deal of budget gets misdirected.

Two things are true at once:

• Plenty of sites have EBR and still review every batch line by line, because nobody ever agreed the exception criteria;
• Plenty of sites without full EBR can reach a defensible exception model, because the critical parameters already sit in queryable systems.

The question is not which platforms you own. It is whether your systems agree on what happened, and whether you can demonstrate that agreement to an inspector.

What the determination actually draws on, and who owns each piece:

Every row is governed by ALCOA+ expectations data must be attributable, legible, contemporaneous, original and accurate — and by the lifecycle controls in Annex 11. That is the point most often missed: exception-based review does not lower the data integrity bar. It raises it, because a conforming batch is now released on the strength of the data rather than on a human having read the page.

The far end of this trajectory is real-time release testing, where quality is evaluated from process data rather than end-product testing. The peer-reviewed literature is candid about why adoption has been slow: the regulatory framework is harmonised and broadly accepted, yet industry has been reluctant to implement aggressively, and the most mature applications remain narrow. Exception-based review is the achievable step, not the destination.

Does a batch release dashboard need to be validated?

If it informs or evidences a GMP release decision, yes. A status view that people rely on to decide what is releasable is a computerised system used in a GMP-regulated activity, whatever tool it was built in.

Both 21 CFR Part 11 and EU GMP Annex 11 apply on that basis, and Annex 11 is explicit that a computerised system must be validated for its intended purpose and controlled across its lifecycle.

A defensible batch status view needs, at minimum:

• A documented intended use, stating what decisions it supports and what it does not;
• A risk assessment proportionate to that use;
• Verified data flows from each source system, with the verification retained;
• An audit trail covering data changes and user actions;
• Role-based access control, with review and approval rights separated;
• Change control covering both the view and the sources feeding it.

A read-only view built on validated GxP software is considerably simpler to qualify than a spreadsheet already performing the same role unvalidated. The validation approach should be set before anything is built, not retrofitted to a working prototype.

What it takes to implement review by exception

The technology in these projects is rarely exotic. What separates the implementations that hold from the ones that stall is consistently the same four things.

Interrogate the request before building it

The stated requirement and the underlying problem are different documents. When the trigger is a scale-up, design against the volume you will have, not the volume you have now. The most valuable thing an external partner can do in week one is ask what changes in month six.

Staff it with people who speak both languages

A team fluent in business intelligence but not in disposition will build something elegant and unusable. A team fluent in GMP but not in data architecture will rebuild the spreadsheet in a different tool. This gap is the constraint behind most smart manufacturing programmes that quietly stop after the pilot.

Agree the exception criteria before the build

This is QA’s decision, not IT’s, and it is the single most common point of failure. What makes a batch an exception at this site? If that question cannot be answered in a workshop, no amount of tooling will resolve it. Digital validation tooling supports the approach; it does not supply it.

Keep the feedback loop tight

Near-daily contact with the people who actually perform the review, not a requirements document and a demonstration in week eight. The reviewers know where the time goes. They are rarely asked.

What this looked like at a top-five pharmaceutical manufacturer

A Swiss-based pharmaceutical and biotechnology company one of the top five globally — had the same underlying problem one layer upstream of batch release. Quality data lived in paper documents that were manually transcribed and reviewed before anyone could analyse anything. Sites monitored and reported differently from one another. Data was hard to reach, and the volume needing analysis kept growing, which meant compliance risk grew with it.

The ask was not for a better spreadsheet. It was for the state of control to be demonstrable, continuously, across a global network process and product monitoring (PPM) and continued process verification in one web-based GMP platform, compliant with 21 CFR Part 11, with workflow review and approval and full audit trail.

BGO Software has been building and running that system with the client for more than three years.

What it took to make the data usable:

• Over 50 data connections feeding one platform;
• More than 3,000 attribute definitions that previously had no digital representation at all they existed on paper or in local files;
• Over a million attribute values under management;
• Close to 1,000 users across manufacturing locations working from the same definitions.

The monitoring itself works on exactly the logic this article describes. Attributes are mapped, control limits are established, variation is monitored on control charts, trend analysis assesses the state of control, and rule violations are documented as they occur. Nobody reads every data point. The system identifies what deviates and puts a human on it.

What the client measured:

The hours figure is the one worth sitting with. Roughly 100 hours of transcription, reconciliation and report assembly disappeared — not because anyone reviewed less, but because the data no longer had to be gathered by hand before it could be reviewed at all. Alongside it: monitoring standardised worldwide, variation identified proactively rather than retrospectively, and GMP reporting simplified rather than merely digitised.

BGO Software utilizes dedicated teams and structured communication, ensuring the timely and seamless construction of our web-based GMP platforms.

Harry Birimirski, Solutions Architect · Microsoft Technologies

Read the full case study: Drug Manufacturing Intelligence Solution

Why this matters for batch release. That engagement is continued process verification, not batch record review — a different decision at a different point in the lifecycle. It is included here because it answers the prerequisite question. Exception-based review is only defensible when the underlying data is contextualised, connected and trustworthy enough to carry the determination. Three thousand attribute definitions and fifty data connections is what that groundwork actually looks like at scale, and it is the same work a site has to do before it can tell a conforming batch from an exception without reading every page.

Conclusion

Reviewing every batch was never the control. It was the workaround for not being able to prove which batches needed reviewing.

That workaround held for as long as volumes were flat and the spreadsheet had a custodian. A ramp-up removes both conditions at once, and the automation that gets requested at that moment treats the symptom rather than the cause.

The question worth asking first is not how to make the status file faster. It is what an exception looks like at your site, whether your systems can currently prove one, and what it would take to make that determination defensible to an inspector. Those three answers decide the project — and they are QA questions before they are technical ones.

If your release process is heading into a volume increase it was not designed for, we can help you work out what that looks like.

Dobrin Kolarov

Healthcare business analyst with expertise in marketing and business development, and holds an MPharm degree. He specialises in creating and executing communication strategies that make digital health solutions and pharmaceutical technologies clear, accessible, and resonation for their audiences.

link to the author’s linkedin profile