Case Study · Fictional teaching example

A weekly SaaS eQMS update

A medical-device manufacturer uses an eQMS for controlled documents and CAPA. A weekly supplier release changes dashboard colors, conditional CAPA routing, and the signature block in exported records. The system owner has five working days before deployment.

Author
Sandip Thorat
Published
12 September 2026
Last reviewed
12 September 2026
Version
1.0
Content type
Practitioner guidance
Primary references
See related regulations, guidance, and approved procedures

Standard case study record

Scope and decision fields

Read these fields before the detailed worked case. All organizations, identifiers, test outcomes, and decisions are fictional teaching material.

GxP Assessment
The configured eQMS supports controlled CAPA records, approval decisions, electronic signatures, and retained quality records. The affected routing and export functions are GxP-relevant.
Change or Issue
A supplier release changes dashboard presentation, conditional CAPA routing, and the signature block used in exported records.
Functions Affected
  • CAPA routing and approval
  • Electronic-signature display and record association
  • Dashboard status interpretation
  • Open-record transition after release
Potential Impact
A record could bypass a required Quality approval, show an incorrect status, or associate a signature with the wrong record revision.
Deviations / Known Issues
A legacy blank site field bypasses required review in the fictional execution. Deployment is restricted until the mapping is corrected and targeted retest passes.

Situation and intended use

A medical-device manufacturer uses an eQMS for controlled documents and CAPA. A weekly supplier release changes dashboard colors, conditional CAPA routing, and the signature block in exported records. The system owner has five working days before deployment.

First question: what is actually affected?

Read the release notes and available evidence. Identify the local routing rules, export uses, open records, integrations, and shared components. Ask whether the color change also alters status labels or accessibility. A visual change can matter if users depend on color alone to identify overdue work.

Failure and evidence plan

FailureProposed assurance activityEvidence gap addressed
Severe CAPA bypasses required approvalTest approved routing branches, invalid values, and attempted bypassLocal conditional rules
Existing CAPA changes route unexpectedlyTest representative open states before and after updateTransition of existing records
Export associates signature with wrong revisionCompare source approval and exported version/contextLocal record use and export behavior
Status meaning becomes unclearFocused review with representative users and accessible labelsOperational interpretation

Supplier workflow-engine evidence may support standard mechanics. It does not automatically support the local conditions.

Worked outcome — fictional

CAPA tests find that records with a blank legacy site field skip a required review. The team prevents affected records from advancing while correcting the mapping and reassessing coverage. Because the defect affects a required control, a general statement that “most tests passed” is insufficient.

After correction, targeted retesting and relevant regression demonstrate the approved behavior. Export checks confirm the expected record associations. The dashboard retains explicit text labels. The authorized owners approve deployment with defined monitoring for routing exceptions.

Residual risk and monitoring

Monitor unexpected route changes, stuck tasks, and export complaints. Assign an owner and response process. If the supplier cannot delay deployment, evaluate operational restrictions and escalation before exposure; a rollback plan must account for data and workflow changes, not just software version.

Questions a reviewer should be able to answer

Why were these branches selected? How were legacy open records represented? What supplier evidence was reused? What happened to the defect? Who approved continued use and under what conditions?

Challenge: Only the dashboard changes next week. Must this entire lab be repeated?

Worked answer: Reassess the actual release and dependencies. Reuse relevant evidence when justified and address the new uncertainty. Do not mechanically repeat or mechanically waive testing.