An EBR Is Not a Report — The Distinction That Changes Everything
The most common misconception about electronic batch records on SCADA projects is that they are the output of a report function. Export the process data for the batch window to PDF, add a header, and you have an EBR. This approach produces something that looks like a batch record but lacks several of the properties that make it a compliant electronic record under 21 CFR Part 11 and EU GMP Annex 11.
A genuine EBR is a structured, immutable record generated automatically by the system at a defined trigger point — typically batch or cycle completion. It captures a defined set of parameters and events from within the batch time window. It is linked to the batch ID so it cannot be confused with a different batch. It is stored in the historian in an unalterable format. It has a defined review and release workflow that requires specific e-signatures from specific roles. It is exportable as a certified copy. And critically, it cannot be modified after the first e-signature is applied — not by the operator, not by a supervisor, not by an administrator.
A report that an operator can run, modify the parameters of, and re-export is not an EBR. It may be a useful operational tool, but it is not a batch record. The FDS must make this distinction clear, and the URS must specify which records are batch records and which are operational reports.
What an EBR Must Contain
The content of an EBR must be specified in the FDS before development begins. Saying "the EBR contains batch data" is not a specification. Each element must be explicitly listed, because the OQ will verify that every listed element appears in the generated record and that no configurable fields permit omission.
The header must be entirely system-generated — no operator-entered fields in the header. The system assigns the batch ID (or receives it from an upstream system like an MES or LIMS), populates the timestamps from the NTP-synchronised clock, and captures the software version hash that was running during the batch. These are not optional: without the software version hash in the header, there is no evidence of which validated software state produced the record.
The process data section must cover the full GMP-critical parameter set with statistics over the batch window — minimum, maximum, average, and time outside any defined limits. Raw time-series data should be referenced by historian query parameters rather than embedded directly in the record — embedding thousands of historian data points in every EBR creates large, difficult-to-manage records. The FDS should specify which parameters have embedded data and which are referenced.
The events section is where most of the compliance weight sits. Every alarm that fired during the batch window must appear — with acknowledgement records, not just the alarm activation. An alarm that fired and was not acknowledged before the batch record was generated is a compliance finding in the batch record itself. Every operator action, every setpoint change, every mode transition within the batch window must be captured from the audit trail.
Trigger, Scope, and Batch Boundary Definition
Before designing the EBR content, you need to define the batch boundary precisely. This is where many EBR implementations become ambiguous and generate audit questions.
The batch start trigger is typically automatic — batch initiation by an authenticated Supervisor activates the recipe or sequence, and the EBR record window opens at that timestamp. The batch end trigger can be automatic (sequence completion) or operator-confirmed (Supervisor actively closes the batch after confirming all steps are complete). Both approaches have compliance implications: automatic closure is cleaner and eliminates operator discretion, but requires that the sequence logic is robust enough that it reliably signals completion. Operator-confirmed closure allows a Supervisor to flag exceptions before closing, but introduces a window during which the record is open and additional events can accrue.
The batch boundary timestamps are NTP-synchronised and immutable. They must be set by the system at the moment of the trigger event, not entered by the operator after the fact. If an operator can change the batch start time, the record is modifiable — a Part 11 violation regardless of whether the historian data within the window is correct.
Multi-step processes introduce additional complexity: does each step have its own record, or is there one record covering the entire batch? The FDS must specify this, and the answer flows from the quality system's requirement for batch record granularity, not from what is technically easiest to build.
Electronic Signatures — Design Requirements for Part 11
21 CFR Part 11 Subpart C defines the requirements for electronic signatures in closed systems. On a pharma SCADA, the EBR e-signature implementation must satisfy: unique user identification (username, not role), biometric or non-biometric with a password component, signed manifestation that permanently links the signature to the specific record, and a defined signature meaning from a controlled list.
In practice this means: the e-signature screen displays the full batch record content (or a definitive reference to it) before the user enters credentials. The user sees what they are signing. They enter their username — pre-populated from the authenticated session, not editable — and their password, which is always a blank field that cannot be pre-populated. They select a signature meaning from a defined list: "Reviewed," "Approved," "Released." They click confirm. The e-signature event is written to the audit trail immediately, and the batch record is locked against further modification.
The signature event must appear in the audit trail with six fields: the user ID, the role at the time of signing, the signature meaning, the specific record ID being signed, the timestamp, and the software version hash active at the time. This creates an unambiguous, auditable chain from the record to every person who signed it.
Part 11 §11.50 requires that signed electronic records contain information associated with the signing that clearly indicates: the printed name of the signer, the date and time when the signature was executed, and the meaning associated with the signature. This means the signature information must be embedded in or permanently linked to the record itself — not just in a separate audit trail entry. The PDF export of the EBR must show the signature block with all three elements. An audit trail entry that shows "user jsmith approved record #1234" is not sufficient on its own if the record PDF does not show the same information within its own content.
Certified Copies and Export
EU GMP Annex 11 Clause 8 requires that certified copies of electronic records can be generated on request. A certified copy of an EBR is a PDF export that: contains all the data in the original record with no field omission; includes a certified copy statement in the header identifying the source system, the export timestamp, and the exporting user; includes a checksum or equivalent verification statement that can be used to confirm the export matches the stored record; and has been produced by the system without manual assembly by the user.
The certified copy export must not require an operator to manually select which data fields to include. Every field in the stored record must appear in the export. If an operator can produce a "partial" export that omits certain fields — even a non-GMP-critical field — that export is not a certified copy. The FDS must specify that the certified copy export is a fixed-format, all-fields-included function, not a configurable report.
The checksum in the certified copy header links the export to the stored record. This allows a future auditor to take the exported PDF, recalculate the checksum of the data content, and confirm it matches what the system reports as the checksum of the stored record at the time of export. If someone has tampered with the PDF after export, the checksum will not match. This is not a perfect security mechanism, but it is a meaningful integrity check that is feasible to implement and credible to an auditor.
Record Locking and Immutability
An EBR must be locked — no modification permitted by any user — once the first e-signature is applied. The locking mechanism must be enforced at the database level, not just at the application level. Application-level locking (a flag that says "this record is locked" which the application then respects) can be bypassed by someone with direct database access. Database-level locking means the record is stored in the write-once table structure covered in the audit trail implementation — INSERT-only permissions, no UPDATE permitted by any account.
Before the first e-signature is applied, the record should be in a draft state that is clearly visible in the system — not just internally flagged. Operators and supervisors must be able to see that the record is open and pending review. Once the operator signs, the status changes to "Under Review." Once QA signs, the status changes to "Released." Each status transition is audit-trailed. The status column in the historian makes the review lifecycle visible in queries without requiring the user to open each individual record.
The EBR must not have a "reject" or "delete" function accessible to any user. If a batch record needs to be invalidated — because the batch itself was invalid — that is managed through the deviation and change control process, not by deleting the electronic record. The EBR remains in the historian with its status set to "Invalidated" or "Rejected" and a linked deviation record. The data still exists; the quality decision is documented alongside it.
Validation Approach — What the OQ Must Test
EBR validation in the OQ requires specific test cases that cannot be covered by general data integrity testing. The following must each have dedicated OQ test cases:
- Record generation trigger — confirm the EBR is automatically generated at batch completion and not before; confirm the batch boundary timestamps are correct and NTP-synchronised.
- Content completeness — verify every specified FDS element appears in the generated record; verify no configurable fields permit omission.
- Alarm capture within batch window — generate a known alarm during a test batch; confirm the alarm and its acknowledgement record appear in the EBR for that batch and not in the EBR for an adjacent batch.
- E-signature workflow — apply signatures in sequence; verify each signature is recorded in the audit trail with all six required fields; verify the record is locked after the first signature and cannot be modified; verify a concurrent login cannot sign the same record twice.
- Write-once confirmation — after QA release, attempt SQL UPDATE on the record; confirm permission denied.
- Certified copy export — generate a certified copy; verify all fields present; verify the checksum; verify the certified copy statement in the header.
The QLean framework is calibrated for a purified water distribution system, which does not have batch manufacturing in the traditional sense — there is no batch ID or ISA-88 batch sequence. The framework does not include batch record templates. However, the core data integrity architecture that underpins a valid EBR is fully covered: FUNC-SEC-004 specifies the e-signature implementation (unique ID + password, signed manifestation, signature meaning from controlled list, record locked after signature, event audit-trailed with all required fields); FUNC-DATA-003 specifies the certified copy export (all fields, certified copy header, checksum, exporting user captured); and FUNC-DI-002 covers the write-once architecture that prevents record modification. The FDS functional descriptions, SDS e-signature implementation, and OQ test cases for these functions provide the direct foundation for an EBR implementation on a batch manufacturing system — the batch-specific elements (batch ID, recipe parameters, ISA-88 phase boundaries) are the incremental design additions on top of this base.