I learned the hard way that "it was closed in Jira" is not a compliance argument.
We had a low-severity software anomaly that a developer fixed, pushed, and marked as resolved in Jira. Six months later a notified body auditor asked for the CAPA record and the supporting evidence that the change had been considered in our Technical File and risk management. The developer's Jira ticket existed, but the audit trail through our QMS was fragmented: the CAPA reference was missing, the impact assessment was a Word file on a shared drive, and the Technical File did not show the follow-up. That was the one that triggered a full weekend of catch-up.
Since then I've built a simple, enforceable chain: anomaly → impact assessment → decision → implementation → verification → Technical File update. The difference now is that the chain is traceable, auditable, and — crucially — resilient to developers closing tickets in Jira.
Why this matters (standards and audits)
MDR requires manufacturers to maintain technical documentation demonstrating conformity (see Annex II) and to operate a quality management system that ensures post-market surveillance and corrective actions (Article 10 obligations, and the related QMS expectations). ISO 13485:2016 explicitly places corrective action and verification in the QMS (see clause 8.5.2 for corrective action).
In practice this means an auditor or a notified body should be able to follow a single thread from the original anomaly report to the final verification and see the evidence that the Technical File or Design History File was updated (where applicable), that risk was re-assessed, and that the action was effective.
To be fair, developers are not trying to break the traceability — they simply use tools (Jira) that are optimised for engineering workflow, not regulatory continuity. The gap is the hand-off.
The minimal chain that survives audits
I now insist on these discrete items for every anomaly that may affect safety, performance, or regulatory status:
- Anomaly record: original ticket ID, time-stamped, owner, description, severity.
- Impact assessment: documented risk reassessment (link to risk file), decision (CAPA or no action), and justification.
- Decision/CAPA: CAPA record or justification for no-CAPA (with review and sign-off).
- Implementation evidence: code commits, change control records, verification test logs.
- Verification: effectiveness checks, monitoring plan changes, PMCF/PSUR notes if relevant.
- Technical File / DHF update: versioned artefacts and cross-reference to the originating anomaly.
Each item must reference the originating ticket ID so the chain is unambiguous. Auditors love a single identifier they can follow.
How the tooling change helped — TIL: linking Jira to the QMS
We used to export Jira PDFs and manually paste links into the CAPA folder. That failed when tickets were closed or restructured.
TIL: qmsWrapper can link Jira and the QMS so defects closed in Jira do not simply disappear from the CAPA history or the Technical File. The practical benefits we saw:
- Persistent cross-reference: the QMS stores the original ticket metadata (ID, summary, timestamps) so the CAPA record shows the Jira origin even after closure.
- Evidence snapshot: when the anomaly is captured into the QMS, a snapshot of the ticket (attachments, comments up to that moment) is archived with the CAPA, preventing later edits in Jira from erasing context.
- Connected workflow: the CAPA and change-control workflows are aware of the Jira ticket state; when the developer closes a fix, the QMS still enforces verification and documentation before final CAPA closure.
- AI-assisted impact analysis flags: the system suggests documents likely affected by the change (risk files, IFU, clinical evaluation sections), which reduced oversight misses during the initial impact assessment.
This is not magic. It is controlled assistance: one place where the anomaly, the CAPA, the change, and the Technical File actually link to each other, preserving reviewability and traceability.
Practical steps to implement the chain (what we changed day-to-day)
- Require an intake step: an anomaly is not an "engineering-only" ticket until it's reviewed for regulatory impact. That review uses a templated impact assessment in the QMS.
- Enforce a single identifier: the CAPA must record the Jira ID; the Technical File update references the CAPA number.
- Snapshot evidence early: when an anomaly is flagged as potentially impacting safety/performance, snapshot the Jira state into the QMS immediately.
- Make verification a gating item: closure in Jira does not close the CAPA. The CAPA owner must verify outcomes and link verification artefacts back into the QMS.
- Update the Technical File promptly: if the impact assessment requires it (per Annex II expectations), update the Technical File or DHF and log the version change.
- Train developers and product owners: explain that their Jira closure is necessary but not sufficient; the QMS has its own closure criteria tied to regulatory obligations.
What changed for audits and notified bodies
Notified bodies now find a neat, single-thread narrative. We can point to the anomaly, open the CAPA, show implementation evidence, and demonstrate the Technical File update — all without cross-checking multiple shared drives.
More importantly, we reduce post-audit corrective actions that stem from missing links. Auditors are not interested in how your team organises tasks; they need to see that your quality system captured the change, assessed risk, and verified effectiveness per your own procedures and MDR requirements.
Closing thought
If you're juggling Jira and a QMS: make the hand-off explicit and automated where possible. It saves weekends and avoids uncomfortable audit conversations.
How do you ensure your engineering tickets become first-class evidence in your QMS, not just a closed item in Jira?
