Groundwork Code

Source code · US · EU

Pharma Batch Release & Deviation Control (US/EU GMP)

Standalone batch release and deviation control that keeps a batch from shipping while anything is still open.

Open the live demoWhat it rests onPricing

The demo runs on a free server and sleeps when idle, so the first load takes about a minute. Its data is wiped regularly.

Released
2026-09-16
Jurisdictions
US, EU
Rules implemented
27
Process chains
6
Known limitations
1
The application, signed in
The interface is deliberately plain. This is a reference implementation you extend, not a finished product — the work sits in the rules it enforces.

What it does

This is source code that runs the fixed route of a manufacturing batch from draft to release or rejection, under US 21 CFR Part 11 and EU Annex 11 rules. It holds the Electronic Batch Record, the Batch Release Record, deviations, CAPAs and OOS investigations as separate but linked state machines, each with its own transitions and its own conditions for moving forward. Every signed step records a printed name, a date and time, and the meaning of the signature. Once a record is released it becomes immutable.

The point of a system like this is not what it lets through but what it stops. A batch cannot reach Approved while a linked deviation or OOS is open. A record can only be edited while in Draft. A CAPA cannot be closed by its own owner. A correction to a released record cannot happen without a documented exception and QA approval, and every such change writes an audit trail entry with the old and new value. The rules are implemented from cited GMP sources; the enforcement is in the code, not in procedure.

The 6 process chains

Each chain is a route a record travels. What matters as much as what it does is what it refuses — those refusals are wired into the state transitions, not offered as guidance.

F1

Releasing the Electronic Batch Record

SupervisorQA Manager

The EBR is filled in and editable only while in Draft. A Supervisor submits it for approval, or cancels it when it is not required, typically on QA comment. The QA Manager performs the final verification and either releases it with an electronic signature — at which point it becomes immutable and the releasing user and timestamp are recorded — or rejects it.

It refuses

  • Submission of an EBR carrying a critical manually entered value is blocked until a second review signature confirms the accuracy of that value.
  • Any correction to a released record is refused unless a documented exception with QA approval and the original content exist; when they do, the change succeeds and an audit trail entry is written.
  • The EBR cannot be edited outside Draft.
F2

Approving the Batch Release Record

Operator/Productie of QA reviewerQA head / QPQuality Assurance (QA)

Production or a QA reviewer submits the record, moving it from Draft to Under QA Review. From there the QA head or QP sets the disposition: Approved requires the BMR and CoA reviewed, no open deviation or OOS, and certification by electronic signature. QA can place the record On Hold while a linked deviation, OOS or investigation is open, and a rejection requires a disposition reason. A held record can only reach Approved once the linked OOS and deviation are closed and reviews are complete.

It refuses

  • Certification by anyone who is not a QP is refused; certification by a QP succeeds and fills certified_by_user_id and certified_at.
  • Approval with an open deviation or open OOS fails with an explicit message; it succeeds only once all are closed.
  • An operator cannot move a record to Approved; only the QA head or QP can, and QA can move it to On Hold.
F3

Setting batch disposition from quarantine

Quality Assurance (QA)

QA works the disposition on the batch release record out of Quarantine. A batch moves to Approved only when discrepancies are resolved, deviations investigated, and any required CAPA or change control is complete. It moves to Rejected when it does not match the recorded information or carries significant GMP deviations.

It refuses

  • Certification by anyone who is not a QP is refused; certification by a QP succeeds and fills certified_by_user_id and certified_at.
  • Approval with an open deviation or open OOS fails with an explicit message; it succeeds only once all are closed.
  • An operator cannot move a record to Approved; only the QA head or QP can, and QA can move it to On Hold.
F4

Investigating and closing a deviation

Operator/Productie (Reporter) of InvestigatorInvestigator/QAQuality Assurance (QA)Quality Assurance (QA) (Senior)

A reporter or investigator moves a deviation from Open to Under Investigation with a description and a Minor/Major/Critical classification. Root cause and impact assessment are documented; a systemic cause requires a linked CAPA before it can move to CAPA Assigned. QA closes the deviation only after impact assessment, root cause, the linked CAPA milestone and any retraining are complete, approved with a Part 11 electronic signature. A critical deviation with direct impact on product quality or patient safety is placed On Hold by senior QA, quarantining the batch.

It refuses

  • A deviation with a systemic cause cannot move to CAPA Assigned without a linked CAPA.
  • A change to a deviation without a reason is refused; with a reason an audit trail entry is written with old_value and new_value.
  • A confirmed OOS without a linked deviation does not mark the batch releasable; with the link it does.
  • A late electronic signature on a critical check without an accompanying deviation is refused; with a deviation and evidence it is allowed.
  • Setting disposition to Approved while a deviation is still Under Investigation fails.
F5

Verifying and closing a CAPA

Quality Assurance (QA)Quality Assurance (QA) (onafhankelijke reviewer)

A CAPA is opened and executed by QA. Final closure is prevented until the effectiveness criteria and objective evidence are documented and approved. The verifying user must not be the owner: verified_by_user_id must differ from owner_user_id, and verified_at is set on closure. The In Progress step is an assumption; no explicit source rule covers that intermediate transition.

It refuses

  • A deviation with a systemic cause cannot move to CAPA Assigned without a linked CAPA.
  • An owner declaring the effectiveness of their own CAPA is refused; an independent QA reviewer succeeds.
F6

Running the OOS investigation

Quality Control (QC)Quality Assurance (QA)

QC opens the investigation and runs Phase I: a laboratory check of calculation, instrument and dilution for an assignable cause. With no assignable lab cause, QA authorises a retest plan and the investigation moves to Phase II. QA closes it with a conclusion of confirmed or invalidated, root cause and manufacturing impact determined.

It refuses

  • Approval with an open deviation or open OOS fails with an explicit message; it succeeds only once all are closed.
  • An OOS with conclusion=confirmed without a linked deviation does not mark the batch releasable; with the link it does.

Who uses it

Roles as the source material names them, with what each one does in the system.

RoleDoes
Operator/ProductieFills in the electronic batch record contemporaneously, submits it and signs that it is complete and accurate; reports deviations that occur during manufacturing.
SupervisorSubmits the EBR for approval, or cancels it when it is not required on the basis of QA comment.
Quality Control (QC)Performs analyses, records test results and opens the OOS investigation when a result falls outside specification.
QA reviewerMoves the batch record to 'Under QA Review' and assesses deviations and OOS investigations during the intermediate steps.
Quality Assurance (QA)Performs the independent final review, sets the disposition, holds batches while a deviation or OOS is open, and enforces investigation and reassessed classification.
QA head / QPSets the final disposition to Approved (Released) or Rejected and certifies the release with an electronic signature.
QA ManagerPerforms the final verification and releases the EBR (which then becomes immutable) or rejects it with an electronic signature.
Qualified Person (QP)Certifies the release of batches for the EU market by electronic signature.

What this is not

This system has not been validated for GxP use. It ships with no computer system validation package, no installation, operational or performance qualification, no supplier audit, and no approval from any regulatory body. In a regulated environment, validation is the responsibility of the licence holder and is carried out against your own processes and your own risk assessment; it cannot be handed over with a piece of software. This is a starting point that implements documented rules — not a compliant system. Treat it as code you own and must qualify, not as a system you can put into production as delivered.

The rules were drawn from 62 business rules examined, of which 34 were in scope and implemented. Those 34 come from cited US and EU sources: 6 US rules across 6 jurisdictional rules and 5 EU rules, sourced from eCFR, the EU Annex 11 text, GMP SOP references and industry writeups. This covers the release, deviation, CAPA and OOS flows described above and nothing beyond them. Anything outside these 34 rules — other GMP processes, other record types, other jurisdictions — is not in this code.

The database layer uses Node's built-in SQLite module, which is still marked experimental and prints a warning on every start. Fine for a reference implementation; you will likely want to swap it before production.

Known and accepted

  • A large part of the source code is written in Dutch. Function names, variables and comments are Dutch in 28 of the 50 source files outside the tests and in 16 of the 17 test files — including the authentication and server code (hashWachtwoord, verifieerWachtwoord, gebruiker). The user interface and the API are English. Expect to read and work in Dutch whenever you change this code. Accepted as a known limitation and reflected in the price: the single-project tier is 600 instead of 1,000. Everything runs and is tested; the rules and the tests behind them are unaffected.

What it rests on

27 rules the system implements, quoted from the material they were taken from. Each one carries its reference and its source in the archive, next to the module, the check and the test that enforce it. The reference in grey is the identifier the code and tests use; it comes from a larger catalogue of rules, so the numbers are not consecutive.

#Quoted from the sourceReference
1“The printed name of the signer; The date and time when the signature was executed”BR-01
2“secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries”BR-02
3“For critical data entered manually, there should be an additional check on the accuracy of the data”BR-06
4“the system should allow only Qualified Persons to certify the release of the batches”BR-07
5“For change or deletion of GMP-relevant data the reason should be documented”BR-08
6“Draft Record created, data being entered Production / QA”BR-22
7“Approved (Released) Disposition = release; batch can ship QA head / QP”BR-23
8“On Hold / Pending Held for an open deviation/OOS/investigation QA”BR-24
9“Rejected Disposition = reject QA head / QP”BR-25
10“a batch can't be released while a linked OOS or deviation is open”BR-26
11“Open → Under Investigation → CAPA Assigned → Closed”BR-27
12“the obligation to initiate a CAPA, track it to verified closure, and confirm the effectiveness”BR-28
13“Closure requires approval by a qualified QA reviewer, with an electronic signature that is 21 CFR Part 11 compliant”BR-29
14“Triggers immediate batch quarantine and senior QA involvement”BR-30
15“Phase I: lab investigation I calculation/instrument/dilution check”BR-31
16“Hypothesis / retest authorised II QA-authorised retest plan”BR-32
17“Status Open → Phase I → Phase II → Closed”BR-33
18“The EBR is editable only while in Draft”BR-34
19“The QA Manager performs the final verification and releases or rejects the EBR with an electronic signature”BR-35
20“the Supervisor can cancel it, typically based on QA comments”BR-36
21“should not release a batch until discrepancies are resolved or satisfactorily explained, deviations are investigated”BR-37
22“it should not be released unless a justified decision is made”BR-38
23“an explanation must be documented. If no explanation is provided, a deviation investigation must be initiated”BR-51
24“Investigations must extend to other batches of formulated or packed product and API, as necessary”BR-53
25“prevents final closure until the verification criteria — configured per CAPA type — are documented with objective evidence and approved”BR-59
26“Can production release a batch if QA is backlogged? No. Independence is fundamental”BR-60
27“Any correction to a released batch record requires a documented exception with QA approval”BR-62

Price

Both tiers contain exactly the same code. The only difference is how often you may use it. Either way you sell what you build with it, not the code itself.

Single project

$600

Use this code in one system, for yourself or for one client.

Unlimited

$1,500

Use it in as many systems as you like, for yourself or for clients.

Read what this is not before you buy: 1 known limitation, weighed and accepted.

Checkout opens shortly. To buy now, or to ask anything first, write to groundworkcode@outlook.com.

You may not resell this as source code, in whole or in substantial part, modified or not. What you build with it is yours to sell. The full licence ships with the archive.