The scenario every QA director recognises
A 200-person medical device company replaced its paper QMS three years ago. The team picked a respected eQMS, ran a careful implementation, paid for the training package, and migrated cleanly. Two years later the QA director runs a CAPA cycle-time report. The median is 87 days. The mean is 134. The QA team is already maxed out.
The director's first instinct is to hire. Her CFO's first instinct is to add overtime. The COO's first instinct is to commission a Lean Six Sigma project on CAPA. All three are wrong. The cycle-time decomposition shows that 71 of the 87 days are wait-states — records sitting in queues between modules, between approvers, between integrations the team has no visibility into. The QA team is processing as fast as the system feeds them. The architecture is what's slow.
If your eQMS's cycle-time report looks anything like that, open it next to the seam between your Deviation module and your CAPA module. That seam is usually where most of those 87 days live.
What "slow CAPA" actually means
"Slow CAPA" is a misleading phrase because it implies the CAPA itself is slow. In practice the work-time on a typical CAPA — the time someone is actively investigating, writing, reviewing, signing — totals five to twelve days. The rest is wait-states. Records sitting in queues. Records waiting for an upstream module to push them downstream. Records waiting for a human to remember they exist.
Decompose any honest CAPA cycle-time report and the table looks like this:
| Wait-state queue | Typical duration | Owned by |
|---|---|---|
| Deviation closure → CAPA intake | 3–14 days | The seam between modules (often manual) |
| CAPA assignment → investigator pickup | 1–7 days | Notification / routing logic |
| Investigation → root cause sign-off | 5–10 days (mostly work-time) | The team |
| Root cause → CAPA plan approval | 2–10 days | The QA approver queue |
| CAPA plan → Change Control trigger | 2–20 days | The seam between CAPA and CR (often manual) |
| Change implementation → Training assignment | 3–14 days | The seam between CR and Training (often manual) |
| Training completion → Effectiveness check | 14–60 days | The wait for verification data |
| Effectiveness check → CAPA closure | 5–14 days | The final sign-off queue |
Six of the eight queues are seams between modules. Two are the QA team's own queues. The "team is slow" diagnosis explains at most two of the eight. The architecture explains six.
Why teams get blamed for an architecture problem
Three reasons every leadership conversation about slow CAPAs lands on the QA team.
First, the team is the visible label on every CAPA record. The investigator's name is at the top. The approver's name is on the signature. When the report says "owner: J. Smith — 47 days overdue," the answer looks like J. Smith. Second, the team is the easiest variable to change. You can hire. You can train. You can run a Lean project. You cannot replace your eQMS in a quarter. Third, vendors prefer this framing — a post that says "your team needs better root cause analysis" sells training; a post that says "your eQMS architecture is the problem" sells churn.
The team is rarely the problem. The team is almost always processing as fast as the system feeds them.
The sub-requirements of a CAPA system (ISO 13485 §8.5.2, via QMSR)
Since QMSR took effect on February 2, 2026, the operational CAPA requirements a US device firm is inspected against live in ISO 13485:2016 §8.5.2, incorporated by reference under 21 CFR Part 820 — the same substance the old §820.100(a) spelled out as seven sub-requirements. Read either way, each requirement assumes data is flowing between system components. Each one is an integration seam.
| CAPA sub-requirement | Integration seam it assumes |
|---|---|
| Analysing process and quality data sources | Quality data sources push to a CAPA-eligible queue automatically |
| Investigating the cause of nonconformities | Investigation records link bidirectionally to the originating record |
| Identifying the action needed | Action records link to a Change Control or document-update record |
| Verifying or validating CAPA effectiveness | Effectiveness records carry timer-driven SLAs and verification evidence pointers |
| Implementing and recording the change | Implementation events flow into Document Control and Training assignment |
| Disseminating the information | Training assignments are auto-created from change records |
| Feeding relevant information to management review | Management review pulls live CAPA aggregate state, not manual reports |
A CAPA system that does each sub-requirement well at the module layer but stitches the seams with email and quarterly reviews fails the integration spirit of §8.5.2 — even when every individual record looks compliant. ICH Q10 §3.2.2 names this explicitly as a pharmaceutical quality system element, not a process.
A regulator's view of CAPA cycle time
An FDA investigator doesn't ask about your average CAPA cycle time. They ask for one specific record and trace it end to end:
Complaint intake → MDR decision → Deviation → Investigation → CAPA → Change Control → Training → Effectiveness check → CAPA closure.
Eight stages. Seven arrows between them. Each arrow is an integration seam. The investigator pulls each arrow and asks: who carried this record across this boundary, when, with what authorisation, with what audit-trail evidence. If the answer to any arrow is "the QA admin emailed the next owner," the investigator has just found a 21 CFR Part 11 §11.10(e) gap — the audit trail for the cross-module transfer doesn't exist because the transfer wasn't a system event.
The seams aren't bureaucracy. They're the regulated control surface. If the architecture doesn't capture them as events, the firm doesn't have the evidence the regulator is asking for. The slow cycle time is the visible symptom. The audit-trail gap is the citation.
Five architectural antipatterns
These five show up in most eQMS deployments. None are unfixable. All five extend CAPA cycle time by weeks.
1. Deviation closure does not auto-open CAPA. It emails a QA inbox. Someone has to read the email, decide whether to create the CAPA, and remember to do it. Median delay: 3–7 days, longer over weekends and holidays.
2. CAPA plan approval does not trigger Change Control. The CAPA owner navigates to a different module, manually re-enters the change details, and requests approval. Median delay: 2–10 days, plus the data re-entry error rate.
3. Change Control approval does not trigger Training assignment. The CR owner has to remember which roles need training and create assignments manually. Median delay: 3–14 days, plus the omission rate.
4. Effectiveness check has no SLA timer. It sits as an open task in someone's queue until they remember it or until quarterly management review surfaces it. Median delay: 14–60 days.
5. The audit trail for cross-module transfers lives in email, not in the eQMS. The eQMS shows when Deviation #4271 closed and when CAPA #198 opened. It doesn't show that the human transfer between them took five days. The cycle-time report misses five days because the system doesn't know they happened.
Each antipattern is an architectural choice. Each is fixable. Each is invisible until someone reads the cycle-time decomposition.
What buyers usually get wrong post-purchase
The eQMS is in. CAPAs are still slow. The buyer's instinct is one of four reactions; three of them are wrong.
| Buyer's instinct | What actually happens |
|---|---|
| "We need more configuration." | Most configuration changes the form fields. It doesn't change the integration pattern between modules. |
| "We need more training." | Training reduces work-time. It does nothing to wait-state queues, which are 70–85% of cycle time. |
| "We need a process consultant." | A consultant can document the seams. They cannot rebuild the architecture. The recommendation lands back on "buy a different eQMS." |
| "We need to read our cycle-time data as a system-architecture diagnosis." | This is the only instinct that surfaces the real problem. Decompose the cycle time. The seams are where the days live. |
The leverage to change the eQMS architecture is highest before signature and lowest after. Post-purchase, the leverage is asking the vendor what's on their roadmap and how to escalate. Some vendors respond. Many don't.
The workflow primitives that actually matter
Five primitives separate an eQMS that handles seams well from one that doesn't. None of them are marketing language. All five are architectural commitments.
Workflow engine. A first-class workflow engine (BPMN-based or equivalent) that owns the state of every multi-stage record. Without it, "workflow" is form fields and tracking columns. With it, the system knows what state a CAPA is in, what comes next, and what conditions trigger the next state.
Event bus. A pub/sub layer that lets modules emit events ("Deviation #4271 closed") and other modules subscribe ("Open a CAPA if severity ≥ 2"). Without an event bus, integration is point-to-point custom code or manual hand-off.
State machine per record type. A typed state machine for CAPA, Change Control, Deviation, Effectiveness. Invalid transitions are rejected. The audit trail captures every transition. The cycle-time decomposition is automatic because every transition is timestamped.
Escalation timers. First-class timer constructs that fire when a record sits in a state too long. Not cron jobs. Not weekly reports. Timer-driven escalation that wakes up an approver, a manager, or a quality lead automatically.
Cross-module event sourcing. The history of every record is stored as a sequence of events (owen-it/laravel-auditing and equivalent libraries do this at the framework level), so the cycle-time decomposition is reconstructible months later — and the regulator's cross-module trace runs against system data instead of someone's memory.
If your eQMS lacks any of the five, the integration seams between modules are fundamentally manual. The cycle time follows.
What good architecture changes
In an eQMS with the five primitives wired in correctly, the median wait-state in each integration queue drops from days to seconds. The Deviation closure event fires; the CAPA intake listener creates the CAPA record automatically. The CAPA plan approval event fires; the Change Control intake listener opens a CR. The CR approval event fires; the Training assignment listener creates the assignments. The Effectiveness timer fires; the check is queued with an SLA. Every transition is event-sourced.
The QA team's work-time is unchanged. The work-time was never the problem. The wait-states collapse because they were artefacts of the integration pattern, not artefacts of the team. In the scenario we opened with, the median CAPA cycle time drops from 87 days to 18–22 days without hiring, without process redesign, without a Lean project.
What to ask of your current eQMS
Even without changing vendors, you can surface the architecture problem and decide whether to escalate. Four questions to put to your current eQMS account manager and engineering contact:
- How is each cross-module transfer triggered today? Email? Polling? Event subscription? Get the answer per pair (Deviation → CAPA, CAPA → CR, CR → Training, CR → Effectiveness).
- Where do escalation timers live? In the workflow engine? In a separate scheduler? In a quarterly report?
- Show me the audit trail for one cross-module transfer. Who carried Record A to Module B, when, under what authorisation. If the trail goes silent at the seam, that's the gap.
- What's on the roadmap for event-driven module integration? A vendor who treats this as a "considering it" item is a vendor whose architecture is fixed.
Complere fit
Complere is built so the seams between modules are system events, not email hand-offs — which is where the days in a CAPA cycle-time report actually accumulate.
- The Events module carries deviations with investigation ownership, severity classification, and root cause, linked directly to CAPA — so a closed deviation opens its CAPA as a recorded transition rather than a message someone has to remember to send.
- The CAPA module carries action items, due dates, effectiveness review, and linked training evidence, with escalation timers and TAT reminders that fire when a record sits in a state too long instead of waiting for the next quarterly review to surface it.
- The Controlled Change module links change requests to their document updates and training assignments, so the CAPA → change → training path stays connected across module boundaries.
- Every transition is written to a per-record-type, append-only audit trail at the application layer, so the regulator's cross-module trace runs against system data — who carried the record across each seam, when, under what authorisation — instead of against someone's memory.
That is the point for this post — not a pitch, just the architecture. Where the five primitives are wired in, the wait-states at the seams collapse from days to seconds; where they aren't, the cycle-time report keeps hiding them.
