Manufacturing reviews first. QA second. Nothing skips.
Batch record review usually runs on a paper comment sheet, a spreadsheet and a chain of emails — and the order it is supposed to run in is held together by memory. OgmaQ makes the order the system's job: QA cannot start while a manufacturing finding is still open, every finding is somebody's named, dated task, and that person is told.
Your review flow, in one direction
Below is what OgmaQ ships with. The review passes in the middle are yours to set: rename them, reorder them, add one, give each its own colour, and choose which permission reviews it — so a site running batch record review, then QA dispo review, then QP review configures exactly that. Every batch sits in exactly one state, and the board shows them in your order. Each review pass always splits in two, for a reason worth stating: a review that has been handed on but not yet picked up is visibly nobody's, instead of quietly being everybody's.
Batch in Production
The batch is logged while it is still on the line, so the review queue reflects the floor rather than lagging behind it.
Manufacturing Review — Not Assigned
Production is marked complete and the record arrives for review with nobody on it. It is in the queue, and the queue can see that.
Manufacturing Review — Assigned
A reviewer takes it. They work the record, raise findings against the sheet positions they concern, and assign each one.
QA Review — Not Assigned
Completing the manufacturing review is the hand-over. The record moves here — and only here — once every finding on it is resolved.
QA Review — Assigned
A QA reviewer takes it. They may raise findings of their own, or return the record to manufacturing with a recorded reason.
Complete
The review comments are closed, with who completed each pass and when. The record waits here for release.
Archived
A batch is released to the archive, with a recorded reason and the person who did it. The permission is separate from the review one, so a site can hold it with its Qualified Person alone. The record then takes no further change.
Releasing a batch here archives the review record. It is not a batch disposition: that decision, and its signature, stay in your validated system.
A review pass does not start until the one before it is done
This is the sequence every batch review is supposed to follow, and the one that quietly breaks first when the review lives on paper. In OgmaQ it is not a reminder, a colour or a convention — it is a rule the database applies before it accepts the change.
A review pass cannot be completed while a finding is open
Completing the manufacturing review is the hand-over to QA — one act, not two, because two acts meant the second was routinely forgotten and finished records sat waiting for nobody. When that act is attempted, the number of unresolved findings is recomputed from the findings themselves, in the database, over every finding whatever stage raised it. It is never read from a flag the screen sent. If any is still open, the change is refused:
batch review guard: this review stage cannot be completed — 3 finding(s) still openThe person who completed one review pass cannot do the next
The record arrives in the QA stage with nobody on it, and a QA reviewer takes it. At that moment — and again when they complete it — the record is checked against the person who actually completed the manufacturing review, and the same person is refused:
batch review guard: separation of duties — the person who completed an earlier review stage cannot perform this oneEvery finding is somebody's job, with a name and a date
The comment sheet is where batch review work usually goes to be forgotten: a note against a page number, and no owner. In OgmaQ a finding is a record of its own, tagged to a person, and it appears on that person's own list of work until it is closed.
Raised against the sheet
The reviewer records what they found, under your own comment category and sub-category, with the step or page it concerns and — optionally — the document reference. Findings can be raised in the manufacturing review and in the QA review, and nowhere else.
Tagged to a person
The finding is assigned to a named user, with a due date that starts from your workspace's own window (two days as shipped, changeable by an administrator). The record's owning department follows from the first person a finding is assigned to.
They are told
In the system, always — with the reference, the document and the due date, but never the observation text. By email as well, if your administrator has switched that on for the workspace; that message carries less again, just the reference, the finding number and a link back.
Closed with what was done
The assignee opens the finding straight from their own list, describes how it was handled and — where a picture is the evidence — attaches a photo or a scan. The form will not let them mark it done without saying how it was handled; a stage reviewer may instead waive it with a justification — the finding is recorded as Not required, and the reason is one the database itself insists on.
Told in the system — and by email if you want it
Three layers, from one confirmed write. The first two are not settings; the third is, and it is off until an administrator turns it on.
In the app, and on My Actions
The finding appears in the assignee's notifications and on their My Actions list, alongside their escalation work — one list of what is owed, not a second inbox to remember. The card opens the finding in place, without leaving the list.
AlwaysA durable copy that follows them
The notification is stored against the person, not the browser they happened to be using — so it is waiting for them on the shop-floor terminal, the office machine and the phone alike, and it deep-links straight to the finding.
AlwaysEmail, when you switch it on
An administrator turns email on for the workspace and assignment mail goes out at once. It ships off: outbound mail is the layer that can fail or reach the wrong place, so it is a decision you make rather than one we make for you. Each person can still choose a daily digest instead, or nothing.
Off until switched onThe email is written from the stored record, not from whoever asked for it. The recipient is read again from the finding as it was saved, so a message can only reach the person the record actually names. And it deliberately carries almost nothing: the review reference, the finding number and a link. The observation text is never even read from the database to build it — if mail is going to leave your estate, it should not carry the finding with it.
Read the security postureYour review sheet, not ours
The module started life as one manufacturer's paper comment sheet, and it kept that shape: the categories below are what shipped, and every one of them is yours to rename, re-order or retire.
Two forms you own
The form that registers a review and the form that records a finding are both field lists your administrator edits in Administration.
- Rename any field to your own vocabulary, add a hint, re-order it, make it required, or switch it off.
- Add fields of your own — text, choice, date or number — and they appear on the form and on the record.
- Switch a field off and a record that already carries a value for it still shows the value.
- Some fields are structurally locked and cannot be switched off — the batch number, and a finding's description and category.
- Filters on the review board are built from your own register form, so a field you add becomes a filter without anyone writing code for it.
Fields, categories and sub-categories are deactivated, never deleted — so a record raised last year still reads the way it was raised.
A board that reads like the floor
Reviews land on a board whose columns are the states still in the flow, in flow order, so the pile-up is visible before anyone asks about it — batches waiting to be taken, reviews in hand, records QA has not yet picked up. Every one of them is there from the moment you open it, completed reviews included, so the flow reads end to end without switching anything. Released batches are the one exception, and deliberately so: that pile only ever grows, so it has a section of its own behind a View Archive button instead of a column nobody can read. The same set is available as a table with the columns a planner wants: reference, batch, product, status, findings, who has the manufacturing review, who has the QA review, and when it last moved.
OgmaQ carries the review, not the record. What lives here is who reviewed a batch record, what they found, who fixed it and when — the working layer that is otherwise a comment sheet and a mailbox. The batch record itself, and the disposition or release decision, stay in your validated systems. OgmaQ is operational support: it is not a validated GMP system of record by default and makes no 21 CFR Part 11 / EU Annex 11 compliance claim.
If your site runs an MES or an electronic batch record system, that system owns the record and its review. OgmaQ does not generate a batch record, and it does not replace review by exception where you already have it — what it carries is the review work itself: the findings, the named owners, and the order they run in.
See how we draw the lineWhat reviewers and QA ask first
Can QA start reviewing before manufacturing has finished?
No. Completing the manufacturing review is what hands the record to QA — one act, not two — and it is refused while any finding on the record is still open. The count is recomputed in the database from the findings themselves, never taken from the screen, so the rule holds however the request arrives.
Can the same person do the manufacturing review and the QA review?
No. The person who completed a review pass cannot take or complete a later one on the same record. The check is per person and lives in the database, and it reads every earlier pass — not just the one immediately before. Each pass also names the permission that reviews it: by default the Lead / Manager role carries the manufacturing review and the QA role carries the QA review, and a site that adds a pass chooses which of the two reviews it.
How is somebody told that a finding has been assigned to them?
Always in the system: the finding appears in their notifications and on their My Actions list, with the reference, the document and the due date, and a durable copy follows them to another device. Email is added on top when an administrator switches it on for the workspace — it is off until they do, and each person can still choose to receive it in a daily digest instead.
What can a person attach to show a finding was handled?
A photo taken on the spot, a scanned page, or a permitted file — attached to an open finding by the person it is assigned to, or by the reviewer holding that stage. Evidence attached to a resolved finding is frozen with it, and withdrawing a piece of evidence needs a reason and keeps the record of it. Attachments are available on the hosted product, where each stored item says plainly that it is not virus-scanned; a local evaluation build records the metadata only and says so on screen.
Does OgmaQ replace the batch record itself?
No. OgmaQ carries the review of the record — who reviewed it, what they found, who fixed it and when — while the batch record and the disposition or release decision stay in your validated systems. OgmaQ makes no 21 CFR Part 11 or EU Annex 11 compliance claim and is not a validated GMP system of record by default.
Can we use our own review sheet and our own comment categories?
Yes. Both forms — the one that registers a review and the one that records a finding — are field lists your administrator edits: rename, reorder, add a hint, make a field required, switch one off, or add your own text, choice, date and number fields. The comment categories and sub-categories are yours to edit too. A few fields are structurally locked and cannot be switched off, such as the batch number and a finding's description and category.
Is this an electronic signature?
No, and it is not offered as one. OgmaQ records who was signed in when each stage was completed, and holds the sequence and separation of duties described above — but it does not capture, witness or authenticate a signature, and makes no 21 CFR Part 11 / EU Annex 11 claim. Where an executed signature is required, it belongs in your validated system.
Do we have to run this module?
No. Batch Record Review is one of OgmaQ's nine modules. It ships switched on so you can see it, and an administrator switches it off in one click if your site does not review batch records here — the destination leaves the sidebar, and anything already recorded is kept.
The module system. How OgmaQ is composed, what a switch does and — more importantly — the four things a switch is deliberately not allowed to do.
See all nine modulesWhen a finding is a deviation. A GMP issue found in a batch record becomes an escalation in the same workspace — triaged, decided and closed on one auditable path.
See the full productBring your comment sheet to the demo.
We will build your categories and your review form on fictional demo data, and walk a batch from the line to a completed QA review.
Or email hello@ogmaq.com directly.