Configuration Specification

A Configuration Specification (CS) is the controlled, versioned definition of how an MES and its dependent components are parameterized to meet documented requirements, manage quality risk, and produce compliant electronic records. It covers site-specific workflows, master data, recipes, role-based access, e-signature settings, audit trail options, interfaces, and system options that influence data integrity and product quality. The CS is not a vendor manual; it is your authoritative build blueprint and acceptance basis.

Regulatory expectations anchor the CS. 21 CFR 211.68 requires appropriate controls over computerized systems used in GMP operations; 21 CFR Part 11 and EU GMP Annex 11 define technical and procedural controls for electronic records and signatures. GAMP 5 (2nd ed.) calls for risk-based specification and verification with traceability from user requirements through configuration and testing. The CS operationalizes ISA-95 scope and, for batch, ISA-88 recipe structures, enabling consistent, reproducible, and testable MES behavior.

The CS should be modular, mapping to MES functional domains and integration points. It must be precise enough to rebuild the system from scratch and unambiguous for validation testers. Good practice is to structure the CS by domain (e.g., master data, execution, quality records, security, interfaces) and include normative references and a change log. Each configuration item should include a unique identifier, purpose, requirement trace, risk classification, default values, allowed ranges, and test references.

• Master data and catalogs: materials, specifications, BOM/BOP, units of measure, equipment classes and states, electronic record metadata.
• Execution logic: operation steps, workflows, interlocks/permissives, exception handlers, timers, recipe parameters and limits (ISA‑88 units/phases).
• Quality and records: in-process checks, holds, deviation triggers, eBMR/eDHR templates, sampling plans, device history data capture.
• Data integrity controls: audit trail scope, event granularity, system clock/time zone, e-signature prompts, reason/meaning codes.
• Security and SoD: RBAC roles, privileges per function and record, dual-person controls, administrator segregation, account lockout policies.
• Interfaces and integration: ISA‑95 L3/L4 data exchanges, master data sources, identifiers/keys, middleware endpoints, retry/error handling.
• Environmental and infrastructure: environments (DEV/TEST/QA/PROD), configuration deployment method, backups, disaster recovery parameters.

Avoid overloading the CS with procedure text; operating instructions belong in SOPs and training. The CS should focus on deterministic system behavior, enumerated parameters, and testable acceptance criteria that collectively implement the intended use and manage identified risks.

ISA‑95 defines enterprise–control integration and the functional model for MES (Level 3) interacting with Level 4 (ERP) and Levels 2/1 (control). The CS should reflect these layers by clearly separating enterprise master data consumption, MES orchestration, and equipment interactions. For batch, ISA‑88 models (procedural control, physical model, recipes) provide the vocabulary and decomposition used to specify MES configuration—site/master/recipe variants, unit procedures, operations, and phases with parameters and limits.

This alignment ensures consistent term usage and enables portable testing: a phase parameter or interlock defined in the CS should be traceable to a requirement, visible in the recipe, and verifiable through execution logs and audit trails.

In GAMP 5 terms, a commercial MES is typically Category 4 (configured) with possible Category 5 extensions. The CS is the primary vehicle for documenting Category 4 configuration decisions. It should be bi-directionally traceable: from URS through Functional/Design Specifications into CS items, and from each CS item to risk controls and test cases. The CS also drives test design—defining acceptance criteria and negative/edge conditions for OQ and PQ.

1. Establish URS with risk: Define intended use, data integrity needs, and quality risks (ICH Q10 alignment).
2. Derive FS/DS: Articulate how MES capabilities will address URS; reference ISA‑95/88 structures.
3. Author CS: Enumerate exact configurations; assign unique IDs, risk class, and test references.
4. Verify OQ: Challenge configured behavior, including boundary and failure modes; confirm Part 11/Annex 11 controls.
5. Qualify PQ: Demonstrate fitness in representative production scenarios with trained users and typical data.
6. Baseline and release: Lock CS version, capture build/configuration records, and implement change control.

Traceability matrices should include CS item identifiers, requirement IDs, risk rankings, test case IDs, and evidence locations. 21 CFR 211.68 and Annex 11 expect appropriate controls over computerized functions and validation evidence; Part 11 guidance emphasizes validation, audit trails, and security—the CS is the anchor for demonstrating these controls are designed and tested.

The CS must explicitly configure and justify data integrity controls. Per FDA Part 11 guidance, scope and application of electronic records/e-signatures require validated workflows, secure, computer-generated, time-stamped audit trails, and appropriate system checks. EU GMP Annex 11 requires periodic evaluation, access control, change/incident management, and audit trail review. MHRA’s data integrity guidance (ALCOA+) adds expectations for legibility, contemporaneity, and enduring records. These translate into concrete CS settings and procedural linkages.

• Audit trail scope and granularity: events for create/modify/delete, parameter changes, exceptions, holds, review/approval, with user/time/meaning codes.
• Electronic signatures: prompt points, signing reasons/meanings, dual-person signatures where required, signature manifestation on records.
• Time and synchronization: system time source, time zone, DST handling; evidence that clocks are synchronized across MES nodes.
• Security: RBAC role design, privilege mapping per function/record, account policies, disabled direct DB access for end users.
• Record lifecycle: status model (draft/in-process/approved/archived), retention, export format, and backup/restore procedures with checksum/integrity verification.
• Review processes: defined audit trail review intervals and filtered views to support routine oversight without data omission.

Each control should be mapped to requirements in the CS with acceptance tests (e.g., demonstrate that a changed critical limit triggers an audit trail entry with old/new values and requires authenticated re-approval).

The CS must define how configuration is versioned, baselined, and promoted across environments. Configuration items should have semantic versioning and release notes. A baseline ties a CS version to a specific build (environment, database schema, recipe versions, interface endpoints). Changes proceed via formal change control, with impact/risk assessment, regression test selection, and approvals before deployment to production. Build and migration records (who/when/what) are retained as GMP data.

Annex 11 expects change and configuration management with appropriate segregation (developers vs. approvers vs. operators). For high-risk CS items (e.g., release permissives, limit calculations), mandate independent verification and targeted PQ after deployment. Keep retired CS versions retrievable to support batch investigations and lookbacks.

Because MES sits at ISA‑95 Level 3, the CS must codify how master data (materials, specs, equipment, work orders) flow from Level 4 and how execution data returns. Define ownership (system of record), synchronization strategy, and conflict handling. Specify identifiers and key mapping (e.g., material codes, lot/serial formats, equipment IDs) and data validation rules at interface boundaries. Include error handling logic, retries, quarantine queues, and controls for partial failures to prevent silent data loss.

• Interface contracts: message schemas, mandatory fields, value lists, and versioning policy.
• Idempotency and reconciliation: deduplication keys, sequence numbers, and daily reconciliation reports.
• Data provenance: capture and expose source system and message identifiers on MES records to support traceability.
• Security: authentication methods, least-privilege service accounts, encrypted transport, and interface audit logs.
• Time semantics: event time vs. processing time handling to avoid chronology errors in batch genealogy.

Document interface test harnesses and scenario sets in the CS (happy-path and failure modes). Validate that master data updates do not retroactively alter previously approved records and that version ties are explicit (e.g., recipe v3 applied to orders created after cutover).

The CS drives test design. For each configuration item, define objective acceptance criteria and link to test cases. OQ should include boundary, negative, stress, and security tests; PQ proves suitability with trained users and realistic datasets. Part 11/Annex 11 controls (audit trail, signatures, security) warrant targeted, repeatable tests with documented evidence and screen prints/logs that show record linkage and timestamps. Retain raw test evidence and objective results tied to CS item IDs.

Align test rigor with GAMP 5 risk-based approach. Where vendor OQ is leveraged, confirm its applicability to your configured state and supplement with site-specific tests for unique configurations and procedural controls.

Once live, the CS becomes part of the GMP record set. Govern it with document control, training, periodic review, and metrics (e.g., change throughput, test defect leakage). Define formal ownership (process owner and system owner), and ensure segregation of duties between authors, builders, and approvers. Establish a schedule for periodic evaluation (Annex 11) and security review (access recertification, role drift checks) with evidence that CS settings still reflect current practice.

• Access governance: RBAC recertification, administrator activity reviews, and SoD policy checks.
• Audit trail oversight: defined review cadence with sampling plans and exception reports.
• Backup/restore: periodic restores to non-production to verify record integrity and recoverability.
• Incident/change linkage: deviations or CAPAs that imply configuration fixes must reference CS items.
• Retention: maintain superseded CS versions and build logs to support investigations and regulatory inspections.

NIST SP 800‑82 guidance on ICS security can inform hardening baselines (e.g., disabling unused services, patching cadence) and should be cross-referenced where MES interacts with control networks. Ensure system time is authoritative and stable to protect signature and audit trail validity.

Frequent gaps include treating the CS as a narrative rather than a parameterized, testable blueprint; failing to capture environment-specific overlays; omitting negative tests for high-risk functions; and letting RBAC drift away from least privilege. Other anti-patterns: using uncontrolled spreadsheets as the de facto CS; retroactively modifying master data that change approved records; and deploying configuration piecemeal without tamper-evident logs. Each of these undermines traceability and data integrity.

Mitigations include rigorous document control, hash-verifiable configuration exports, routine reconciliation of live settings to the approved CS, and test automation that produces durable, reviewable evidence for each high-risk CS item.

V5 Ultimate treats the Configuration Specification as a first-class, versioned object tied to environments, recipes, and records. Configuration items are uniquely identified, risk-classed, and linked to requirements and tests. Deployments generate immutable build logs with checksums; access and signature controls are set from centrally governed RBAC policies. OQ/PQ evidence, audit trail scopes, and periodic evaluations are attached to the CS, creating a single chain from intent to execution and release.

Interfaces are modeled at ISA‑95 boundaries with explicit ownership and idempotency. V5 automates role recertification and audit trail review workflows, preserving evidence required by Part 11 and Annex 11. Periodic evaluations compare live settings to the approved CS and flag drift for corrective action.