Batch Release, Deviation & OOS Workflow: Data Fields & Status Model (GMP)
2026-06-26
The field-level data model and status flow for three GMP quality workflows — batch release (disposition/approval/rejection fields), deviation investigation, and OOS (Phase I/II) — with status diagrams and how to build them as audited, role-gated workflows.
When you move a GMP quality process — batch release, a deviation, an OOS investigation — off paper and into a workflow system, the hard part isn't the screens. It's the data model: exactly which fields each record carries, and the status values the record moves through (and who can move it). Get those right and the system enforces GMP; get them wrong and you've rebuilt a paper form that doesn't control anything. This post lays out the field-level data model and status flow for the three workflows people search for most: batch release, deviation investigation, and OOS.
Batch release: status model + approval/rejection fields
A batch-release record is a state machine. The most common GMP status set:
STATUS MEANING WHO MOVES IT
--------------------- -------------------------------------------- -----------------
Draft Record created, data being entered Production / QA
Under QA Review Submitted; QA reviewing BMR, results, dev/OOS QA reviewer
Approved (Released) Disposition = release; batch can ship QA head / QP
Rejected Disposition = reject QA head / QP
On Hold / Pending Held for an open deviation/OOS/investigation QA
The fields that make the disposition auditable:
FIELD TYPE NOTES
----------------------------- ---------- --------------------------------------------
Batch / Lot No. text links to the BMR
Product + strength ref from product master
Manufacturing / expiry date date shelf-life check
BMR reviewed (Y/N) + by/at bool+audit review complete before release
Test results / CoA reviewed bool+ref links to QC/LIMS result
Open deviations linked ref[] must be closed (or assessed) to release
Open OOS linked ref[] must be closed to release
Disposition enum Approved / Rejected / On Hold
Decision by / date / e-sign audit 21 CFR Part 11 signature
Rejection / hold reason text mandatory when not Approved
The two controls auditors look for: every status change is timestamped with the user (audit trail), and release is blocked while a linked deviation or OOS is open. See the full batch release process & SOP guide for the procedure around these fields.
Deviation investigation: the data fields
A deviation record captures what happened, how bad, why, and what we'll do:
FIELD TYPE NOTES
----------------------------- ---------- --------------------------------------------
Deviation No. / date raised id+date unique running number
Reported by / department ref who found it
Description text what deviated from the standard
Planned / Unplanned enum planned = pre-approved change
Classification enum Minor / Major / Critical
Product / batch / equipment ref what's impacted
Immediate action / containment text what was done at once
Root cause (RCA) text method: 5-Why / fishbone
Impact assessment text product quality / other batches
CAPA linked ref[] corrective + preventive actions
Status enum Open / Under Investigation / CAPA / Closed
Closed by / date / e-sign audit QA closure
Status flow: Open → Under Investigation → CAPA Assigned → Closed (a Critical deviation usually also blocks the linked batch release until closed). The narrative across records matters — the deviation should link to the CAPA it spawned and, if results were involved, to the OOS below. More on the procedure: deviation management in pharma.
OOS investigation: the data fields (Phase I & II)
An OOS (out-of-specification) result follows the FDA two-phase model, and the data model mirrors it:
FIELD PHASE NOTES
--------------------------------- -------- ----------------------------------------
OOS No. / date / analyst — unique id + who got the result
Test / specification / result — the failing result vs the limit
Phase I: lab investigation I calculation/instrument/dilution check
Assignable lab cause? (Y/N) I if yes → invalidate, retest
Hypothesis / retest authorised II QA-authorised retest plan
Retest results II per a pre-defined plan (not "test into compliance")
Resample (if justified) II with documented rationale
Root cause + manufacturing impact II ties to a deviation/CAPA
Conclusion — confirmed OOS / invalidated
Status — Open → Phase I → Phase II → Closed
Closed by / date / e-sign — QA closure
The whole OOS investigation workflow, step by step walks the FDA Phase I/II logic these fields encode.
How the three connect
Result fails ──► OOS investigation ──► (manufacturing cause?) ──► Deviation
│
▼
CAPA
│
Batch release ◄──── blocked until OOS + deviation are closed ◄───────────┘
That linkage is the point of a data model: a batch can't be released while a linked OOS or deviation is open, and each record's status is a controlled, audited transition — not a free-text box.
Building it as a workflow (not a form)
A workflow platform models each of these as a stage machine with typed fields and role-gated transitions:
- Statuses are stages, and only the right role can advance them (QA approves release; an analyst can't close their own OOS).
- Fields are typed (enum dispositions, references to the batch/product master, dates with limits) so the data is queryable and reportable, not free text.
- Every transition is audit-trailed (who, when, e-signature) for Part 11 / Schedule M.
- Cross-record guards stop release while a linked deviation/OOS is open.
That's exactly what Flobri's workflow builder is — you define the stages, the fields, and who can move each record, and it enforces the GMP rules above. It's also the foundation a pharmaceutical QMS is built on.
Frequently Asked Questions
What status fields does a batch release workflow need?
At minimum a disposition enum (Approved / Rejected / On Hold) plus the gating flags — BMR reviewed, CoA reviewed, open deviations, open OOS — and an audited decision-by / date / e-signature. Release should be blocked while a linked deviation or OOS is open.
What data fields are in a deviation investigation record?
Deviation number and date, reporter, description, planned/unplanned, classification (minor/major/critical), impacted product/batch/equipment, immediate action, root cause, impact assessment, linked CAPA, and a status with audited closure.
What is the data model for an OOS investigation?
A two-phase structure: Phase I lab investigation (assignable cause check → invalidate/retest), Phase II authorised retest/resample with root cause and manufacturing-impact assessment, a conclusion (confirmed/invalidated), and an audited status from Open → Phase I → Phase II → Closed.
How do batch release, deviation and OOS link together?
A failing result opens an OOS; if the cause is manufacturing-related it raises a deviation; the deviation drives a CAPA. The batch release stays On Hold until the linked OOS and deviation are closed — the links are references in the data model, enforced by the workflow.
Flobri lets you build these GMP workflows — batch release, deviation, OOS, CAPA — as audited stage machines with typed fields and role-gated approvals, so the data model enforces the rules instead of a paper form pretending to.