Signature Meaning Statement

A Signature Meaning Statement (SMS) is the controlled textual reason bound to an electronic signature that explains why the signer applied the signature—e.g., “Performed,” “Witnessed/Verified,” “Reviewed,” “Approved,” “QA Release.” In regulated MES contexts, the SMS is mandatory signature metadata captured and rendered together with the signer’s name and the date/time. 21 CFR 11.50 requires that the signed electronic record clearly indicates the meaning associated with the signature; EU GMP Annex 11 extends this expectation to computerized systems used to create, process, and manage GxP records. An SMS eliminates ambiguity, enabling reviewers and inspectors to understand a signer’s role and intent at a given step.

Operationally, SMS values are enumerated and governed under document control, mapped to roles, steps, and SOPs. They appear consistently in on-screen views, audit trails, and any human-readable manifestation (PDF printouts, eBMR/eDHR excerpts) so context is never lost when records are exported or archived. Within ISA‑95 Level 3 MES, signature meanings are part of execution event data, interlocking step logic (e.g., recipe phases, holds/releases), and release workflows across Quality.

The legal anchor for SMS is 21 CFR 11.50, which obliges electronic records to present the signer’s printed name, timestamp, and the meaning of the signature. FDA’s Part 11 Guidance clarifies that signature manifestations must be preserved when records are displayed or printed for inspection. EU GMP Annex 11 requires electronic signatures to be permanently linked to records, include date/time, and reflect the reason for signature (e.g., review, approval). Part 11.200 further stipulates controls for non-biometric signatures (two distinct components, periodic checks) to ensure only the intended individual can apply a meaning-bearing signature.

While Part 11 and Annex 11 set the signature manifestation baseline, product-specific cGMP regulations (e.g., 21 CFR 210/211 for drugs, 820 for devices) impose role-based accountability and documented approvals throughout batch/device history. An SMS operationalizes those responsibilities at the electronic record level—explicitly stating what the signer intended when authorizing an addition, verification, review, or final release. GxP data integrity expectations (MHRA, PIC/S) reinforce that records must be attributable, readable, contemporaneous, original, and accurate; the SMS contributes to ‘Attributable’ and ‘Readable’ by encoding the signer’s purpose in a controlled, queryable form.

• 21 CFR 11.50: signature meaning must be displayed with name and time.
• Annex 11: signatures must be linked to records and include reason, date/time.
• GxP DI (MHRA, PIC/S): meaning supports ALCOA+ (Attributable, Readable).
• Part 11.200: controls ensure only authorized persons can apply meanings.

Effective SMS design begins with a controlled vocabulary aligned to SOPs and role authority matrices. Avoid free-text fields; instead, manage a versioned dictionary of allowable meanings (e.g., Performed, Witnessed, Reviewed, Approved, QA Release, QA Reject, Calculation Re-run Justified) with clear definitions and role mappings. Bind meanings to step types (perform, verify, review, disposition) and recipe phases to minimize user choice where intent is deterministic. Where multiple meanings are plausible, require selection from a short, curated list to ensure consistency across products, sites, and departments.

Associate each SMS with business rules: prerequisites (training, role), co-signature needs (two-person e-signature for high-risk verifications), and record state transitions (e.g., ‘QA Release’ transitions a batch to Released). Localize labels for operators, but store the canonical meaning code for cross-site analytics. Maintain provenance of the dictionary (who changed, when, and why) in the audit trail. In integration scenarios (e.g., review by exception dashboards, QMS change control), expose SMS codes and descriptions via APIs to maintain semantic fidelity across systems.

• Enumerate and version meanings; prohibit free-text.
• Map meanings to roles and step types; minimize optionality.
• Define gating logic and state transitions per meaning.
• Localize display labels; store canonical codes for analytics.
• Audit dictionary changes with rationale and approvals.

SMS choice should be an explicit control point in the MES procedure. For execution steps (performing a weigh, torque check, pH adjustment), the authorized signer applies ‘Performed.’ A separate user, independent and trained, may be compelled by the workflow to apply ‘Verified/Witnessed’ before the route advances. Reviews (line clearance review, batch data review) use distinct meanings; approvals that change batch or device record state (e.g., QA Release) should be segregated from execution and review signatures. For recalculations or critical re-entry of data, a specialized meaning (e.g., ‘Recalculation Justified’) plus a forced comment and two-person signature mitigate data manipulation risks.

1. Execution: Operator completes step; system enforces ‘Performed’ by operator role; step data locked to user ID and time.
2. Verification: Independent user applies ‘Verified/Witnessed’; system prevents self-witnessing and enforces timing (e.g., within defined window).
3. Review: Supervisor/QA applies ‘Reviewed’; exceptions flagged by rules feed review-by-exception workflows.
4. Approval/Release: QA applies ‘Approved’/‘QA Release’; system transitions batch/device status, stamps signature manifestation on the record header.
5. Rework/Recalculation: System demands ‘Recalculation Justified’ with reason code and second signature before overwriting or superseding data.

This gating pattern aligns with GAMP 5’s risk-based control strategy—segregating duties, constraining who can apply which meanings, and ensuring that signatures are not merely ceremonial but trigger explicit state changes and traceability consequences. Time zone handling, daylight saving, and clock synchronization should be validated to preserve temporal integrity of meaning-bearing signatures across distributed plants.

At the data layer, store SMS as a controlled code and display string bound to the signature object, along with signer identity (user ID, full name), timestamp (UTC plus display time zone), authentication evidence (what factors were used), and record linkage. 21 CFR 11.50 requires that the meaning be displayed when the record is human-read, and 11.70 requires signature/record linking; therefore, include the SMS in the record’s signature pane and in any rendered output (PDF, printed batch record). Maintain a normalized dictionary table for meanings with effective dates and retirement tracking; each signature instance should reference the specific dictionary version used at the time of signing for accurate historical rendering.

Ensure consistent rendering: the SMS should appear adjacent to the signer’s name and timestamp wherever signatures are displayed. If localized labels are used, include the canonical meaning code in machine-readable metadata so downstream systems and inspectors can reconcile meanings across languages and sites.

Per ISPE GAMP 5 (2nd ed), treat SMS configuration and enforcement as a GxP-critical functionality because it affects record integrity and release authority. Translate regulatory requirements (11.50, Annex 11) into URS and functional requirements: controlled vocabulary, rendering of signature manifestation, record linking, role mapping, prevention of self-witnessing, and exception handling (recalculation). Develop risk-based test scenarios to verify correct meaning availability per step, correct display/print of signature manifestations, prevention of unauthorized meanings, and proper state transitions. Negative testing is essential: attempt to sign with an unauthorized role, attempt to perform and verify with the same account, remove a meaning mid-batch, print without meanings, and alter time/date settings.

• Traceability: Map URS to test cases verifying 11.50 manifestation and 11.70 linking.
• Security: Validate access controls preventing assignment of disallowed meanings.
• Workflow: Confirm gating logic, co-signature requirements, and state transitions.
• Data integrity: Ensure audit trail captures meaning selection, comments, and any supersession.
• Rendering: Verify on-screen, PDF, and data export renderings show name, time, meaning.
• Localization/time: Validate multilingual labels and consistent UTC handling.

Maintain objective evidence (protocols, results, deviations) and regression suites, especially when dictionary entries change, SSO/SAML is updated, or time synchronization is altered. Periodically challenge controls (Part 11.200 re-authentication) so that meanings cannot be applied without fresh credentials when required (e.g., session timeouts).

SMS decisions ripple beyond MES. In QMS, signatures with ‘Approved’ or ‘QA Release’ often reference CAPA or change controls; ensure cross-links so approvers see the complete context before applying a high-stakes meaning. In LIMS, analytical result reviews may require ‘Reviewed’ by an analyst and ‘Approved’ by QA before CoA publication—meanings must align across systems to prevent contradictory dispositions. In WMS and Maintenance, physical moves or line readiness can be gated behind ‘Line Clearance Reviewed’ or ‘Equipment Ready/Approved’ meanings to prevent premature starts.

Operational realities to manage include multilingual operators, multi-site operations with different role titles, and time zone differences. Provide localized labels and training materials, but enforce a single canonical meaning dictionary. Train personnel on when each meaning applies and when escalation (e.g., two-person e-signature) is required. For device eDHRs and radiopharma short-lived batches, keep SMS application efficient: design screens that pre-select the expected meaning per step, while still requiring explicit user confirmation and re-authentication where risk dictates.

• Align meanings with SOPs and QMS roles; keep one canonical dictionary.
• Gate physical activities (clearance, start-up) behind required meanings.
• Optimize UI: expected meaning pre-selection, explicit confirmation, re-authentication per risk.
• Synchronize meanings across MES–QMS–LIMS–WMS to avoid conflicting dispositions.
• Provide multilingual labels; preserve canonical codes for analytics and inspection.

Typical observations include free-text meanings that vary by operator (“checked,” “ok,” “done”), rendering of signatures without meanings on printouts, self-witnessing allowed by configuration, and dictionary changes without change control. Another frequent issue is overloading a single meaning (‘Approved’) for distinct intents (technical approval vs. quality release), which obscures accountability and complicates release deferrals. Inspectors also examine whether recalculations or data corrections use a distinct meaning and require rationale and independent approval; absent this, the risk of undetected data manipulation rises.

"“The signed electronic record shall 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 (such as review, approval, responsibility, or authorship) associated with the signature.”"

• Do not permit free-text meanings except as controlled rationale fields accompanying a specific meaning.
• Prevent self-witnessing and enforce independence for critical verifications.
• Ensure rendered records always show name, time, and meaning together.
• Separate ‘Approved’ vs. ‘QA Release’ if they represent different authorities.
• Version and audit the meaning dictionary; train when meanings change.

Treat the SMS dictionary as controlled master data under QMS. Establish ownership (QA/CSV), change control triggers (new SOPs, new product categories, regulatory updates), and impact assessment criteria (validation regression, training needs, SOP updates, integration impacts). When adding or retiring a meaning, evaluate historical records: ensure legacy signatures still render correctly (do not delete codes in use) and that analytics can reconcile old vs. new terms. Apply document control to the dictionary specification, with clear definitions, role mappings, and examples of proper use.

For multi-site enterprises, centralize governance but allow site-level label localization and role mappings, provided the canonical codes remain global. Audit dictionary use periodically: look for anomalous usage patterns (e.g., spikes in ‘Recalculation Justified’), which may indicate training gaps or process drift. Include SMS governance in management review metrics, and tie it to periodic effectiveness checks for CAPA if meanings were changed to address data integrity concerns.

• Assign QA/CSV ownership; manage under formal change control.
• Do not delete meanings; retire and preserve for historical rendering.
• Assess training, SOPs, validation, and integrations with each change.
• Monitor usage analytics for outliers indicating control weakness.
• Include SMS governance in periodic management review.

V5 Ultimate implements a controlled, versioned dictionary of signature meanings across the MES procedure model, QMS approvals, LIMS result sign-offs, WMS holds/releases, and Maintenance readiness checks. Meanings are bound to roles and step types, with optional localization and mandatory canonical codes. The platform enforces independence for verifications, offers specialized meanings (e.g., recalculation with justification), stamps the full signature manifestation (name, time, meaning) on all renderings, and exposes meanings via APIs for reporting and ERP interfaces. Dictionary lifecycle is governed by change control, with audit trails capturing who altered meanings, when, and why.

Configuration options include per-step default meanings, forced comments for certain meanings, re-authentication rules in line with Part 11.200, and two-person e-signature enforcement for high-risk verifications. Exports preserve canonical codes and display labels, ensuring that external reviewers can reconcile meanings irrespective of language or site.