Change Control¶

Change management sits alongside CAPA as a core element of any pharmaceutical quality system, and "show me your change control" is a standard inspection request. Document revisions are covered in Quality Documents, but most quality-relevant change is operational — new equipment, a process parameter change, a switch of raw-material supplier, a move to a new contract lab, an upgrade to a GxP computerized system. Those changes need to be proposed, risk-assessed, approved before implementation, implemented with evidence, and verified. QStack provides one fixed flow: Request → Impact Assessment → Approval → Implementation → Verification → Closure.

You'll use this module as a Requestor proposing a change, a Change Owner carrying it end-to-end, an Impact Assessor evaluating a specific impact area, an Implementer owning an implementation action, or a Quality role holder approving before implementation and signing closure.

Raise a change request¶

1. Click New Change Request and fill in:

   Field	What to enter
   Title and description	What is changing, in plain language
   Reason for change	Why — cost, compliance, a CAPA outcome, a supplier event, an improvement
   Proposed classification	Minor / Major / Critical — Quality confirms this at assessment
   Affected items	Links to documents, equipment records, vendors, processes, computerized systems
   Requested implementation date	A target date, non-binding until approval
   Source links	Optional links to the CAPA, deviation, complaint, or audit finding that prompted this

2. Submit. The change starts in Draft and no implementation action can begin until it reaches Approved — QStack enforces this by locking implementation actions while the change is in Draft or Assessment.

Impact assessment¶

As Change Owner, route the request to one or more impact assessors. The assessment form is a fixed checklist — each area gets a yes/no plus justification:

• Product quality impact — specifications, stability, validation status
• Regulatory impact — does this touch a filing, licence, or commitment? (The regulatory action itself happens outside QStack; the assessment records the determination.)
• Validation impact — does anything need re-validation or re-qualification, and which protocols?
• Document impact — which controlled documents need revision. This creates linked draft revisions in Quality Documents.
• Training impact — who needs training before go-live. This creates linked ad-hoc assignments in Training.
• Supplier impact — does this change vendor status or qualification? This links to Vendors & Audits.

Once the assessment is in, the Quality role confirms the final classification:

Approve a change¶

Approvers sign through the standard signature workflow with meaning Authorised for release. A rejection requires a written rationale and is preserved permanently as part of the quality record — rejected changes don't disappear.

Implement a change¶

Implementation works the same way as CAPA actions: one or more implementation actions, each with an owner, a target date, and an evidence requirement. Evidence links to records, revised documents, completed training, or validation records. Each action is signed Performed the work by its owner and Verified the information by a reviewer.

Verify and close a change¶

When every implementation action is complete, the Change Owner summarizes the outcome and confirms the pre-implementation assessment held true — or documents where reality diverged from plan. The Quality role signs closure with meaning Authorised for release.

For Major and Critical changes, the Quality role may require a post-implementation effectiveness review, using the same mechanics as a deviation effectiveness check — default 90 days.

Change states¶

Draft → Assessment → Approved → Implementation → Verification → Closed, with a shortcut from Assessment to Rejected. A rejection is preserved permanently, with its written rationale, rather than deleted — rejected changes are part of the quality record just as much as approved ones.

Cross-module linkages¶

• A CAPA action of "replace the supplier" raises a change request linked to the CAPA.
• A change's document-impact assessment spawns draft revisions in Quality Documents, linked back to the change.
• Training-impact items spawn ad-hoc assignments in Training, source-linked to the change.
• A complaint investigation or an audit finding can originate a change request.

Reporting¶

• Open changes by classification and age
• Changes awaiting approval (dashboard tile)
• On-time implementation rate
• Changes by originating source — CAPA / complaint / audit / improvement

Tenant configuration¶

A few things about how this module behaves are set once for your whole organization, typically during onboarding:

• The classification definitions themselves (starter text is provided, but your tenant can adopt it as-is or adjust it)
• The default approver set per classification
• Whether Major changes require a post-implementation effectiveness review by default

If you're unsure why a change is asking for a signature from someone you didn't expect, it's usually because of one of these tenant-level defaults — check with your Quality role holder or Org Admin.

What an inspector sees¶

QA shows the change register filtered by period, then picks a Major change so the inspector can follow request → impact assessment (including the regulatory determination) → approval signatures → implementation evidence → verification → closure. If the inspector asks what document revisions the change drove, the linked-items panel shows those revisions with their own approval trails.

What this module doesn't do¶

• It doesn't manage project plans, Gantt charts, or resourcing — it tracks the quality decision and evidence, not the project.
• It doesn't execute validation activities — protocols and reports are records linked as evidence.
• It doesn't file regulatory variations or amendments — the impact assessment records the determination; the filing itself happens outside the system.