The short answer
A traceability matrix for IEC 62304 shows, for every software requirement, where it came from, which risk controls it carries, how it was verified and in which release it shipped. In Jira you keep these as linked work items and let the matrix come from the links, instead of rebuilding a spreadsheet before every release. Your quality or regulatory lead decides what goes into the design file.
What is a traceability matrix in medical device software?
A traceability matrix is a table that answers one question for any requirement: can you show the whole chain? Where the requirement came from (a user need or a system requirement), how it was designed, which risk control measures it implements, which tests verified it, and which release it went out in. Read the other way, it also shows that every hazard has a control and every control has been verified.
Too often it’s produced the hard way: someone exports work items to a spreadsheet before a release or an audit, fills in the gaps by memory, and the result is out of date the day after. The matrix itself isn’t the goal. The goal is that the links exist while the work happens, so the matrix is just a view of them.
FB-112Clinical feedbackDEC-031Design decisionREQ-014RequirementRC-007Risk controlTST-022VerificationREL-2.4ReleaseWhat does IEC 62304 ask you to trace?
IEC 62304 doesn’t prescribe a matrix format. Clause 5.1.1 asks that your software development plan provides for traceability between system requirements, software requirements, software system tests and the risk control measures implemented in software. The links to plan for:
- System requirements to software requirements. Each software requirement traces back to the system-level need it serves. Under ISO 13485, design inputs come from the intended use, including the user needs; the chain usually starts there.
- Software requirements to architecture and detailed design. The rigor depends on your software safety class: architecture is required from class B, detailed design only for class C.
- Requirements to verification. Which test shows that the requirement is met, and what the result was for this release. Software system tests apply in every class since Amendment 1 (2015); unit and integration verification start at class B.
- Hazards to risk control measures to verification. IEC 62304 clause 7.3.3 asks you to document traceability from each hazardous situation, through the software item and the software cause, to the risk control measure and its verification. This is where your ISO 14971 risk file and your backlog have to meet.
- Everything to a release. When you release (clause 5.8), you need to show what was in it, that it was verified, and which known residual anomalies it ships with.
If you sell in the US, the FDA’s Quality Management System Regulation (in force since 2 February 2026) incorporates ISO 13485 by reference. It dropped the term “design history file”; the FDA treats ISO 13485’s design and development file (clause 7.3.10) as its equivalent. The design-control traceability is essentially the same either way, and a US submission adds FDA’s software documentation expectations (Basic or Enhanced, from its 2023 premarket guidance).
A second edition of IEC 62304 is in drafting and proposes replacing the A/B/C classes with two process rigor levels. It isn’t published yet, so plan on the current edition.
How do you model traceability in Jira?
Keep it small and name things by what they mean. A typical setup uses five work types (issue types, in Jira Data Center), a version per release, and four or five link types, and nothing else:
| Work type or field | What it holds | Links to |
|---|---|---|
| User need | What the user or clinician needs | Requirements that satisfy it |
| Requirement | A testable software requirement with a stable ID | User need, design, risk controls, tests |
| Hazard | A software-related hazard from the risk file | Risk controls that mitigate it |
| Risk control | The measure that reduces the risk | Hazard, requirement that implements it, test that verifies it |
| Test | A verification test case and its result | Requirement or risk control it verifies, release |
| Release (a fix version, not a work type) | The version that shipped | Everything shipped in it |
A few rules keep the links reliable:
- Requirements are not stories. Stories describe work; requirements describe what the software must do. Keep them as separate types so a requirement keeps its ID when the story that built it is closed.
- Name link types by meaning, both ways. “verifies / is verified by”, “mitigates / is mitigated by”, “implements / is implemented by”. Generic “relates to” links can’t be reported on reliably.
- Make the links required where they matter. A workflow validator or condition can stop a requirement from moving to Done without a linked test, or a risk control without a verification. Jira Automation then flags what slips through, since it acts after a change rather than blocking it.
- Put design where design is read. Architecture and detailed design usually live in Confluence pages, linked to the requirements they cover.
- Pick one place for test results. Either a test management app on top of Jira or a Test work item type with a result per release. Not both.
How do you generate the matrix instead of rebuilding it?
Once the links exist, the matrix is a query. There are three common ways to produce it:
- Jira filters and dashboards. A JQL filter per release shows requirements, their links and their status; gaps (requirements without a test, controls without verification) become their own saved filters that the team watches every sprint.
- A Confluence report. A page that pulls the linked items for a fix version into a table, reviewed and approved as part of the release. The page version becomes the record for that release.
- A traceability or test management app. Apps built on Jira can render the full matrix, coverage and test results per release. Worth it when you have many requirements or several products.
Whichever you choose, freeze it per release: the matrix for version 2.4 should still read the same after version 2.5 ships. Fix versions and approved Confluence page versions do that for you.
Which gaps do we look for first?
When we take a SaMD team’s flow apart in a Teardown, these are the five gaps we check first:
- Requirements live inside stories or Word documents. No stable IDs, no acceptance criteria you can test, so nothing reliable to link to.
- The risk file is a spreadsheet. Hazards and controls are updated at a different pace from the backlog, and nobody can show which story implements which control.
- Test results aren’t tied to a release. Tests exist, but you can’t say which ones ran for version 2.4, or what the result was.
- Changes skip the impact check. A requirement changes mid-sprint and nobody records which tests and risk controls are affected.
- Third-party software (SOUP) sits in a separate list. Versions and known issues aren’t linked to the releases that ship them.
None of these needs a new tool. Each one is a work item type, a link type or a workflow rule that isn’t there yet.
How do you get there without stopping delivery?
Don’t migrate everything at once. Take one feature that matters and trace it end to end, from the user need to the release, with the real team in real sprints. That pilot shows which types, links and rules you actually need. Then roll the pattern out to the rest of the backlog, area by area, and backfill links for what’s already shipped only where your quality lead needs it.
This is how the Product Ops Flywheel runs: Teardown maps where the chain breaks today, Blueprint traces one feature live, Implement sets it up in Jira and Confluence and trains the team.
Who owns what?
The setup makes the evidence easy to produce; it doesn’t decide what the evidence must be. Your quality or regulatory lead owns your interpretation of IEC 62304 and ISO 13485, decides what goes into the design and development file, and signs off releases. Lottusa is an Atlassian consulting firm, not a regulatory consultancy: we build the flow in Jira and Confluence around the decisions your team makes.
The SaMD Traceability Check: 18 questions, about six minutes, your score right away.
Questions people ask
Can Jira be used for medical device software development?
Yes. Jira and Confluence are widely used for medical device software development and documentation. What matters is that your process, not the tool, meets IEC 62304 and ISO 13485: defined work types, required links, controlled approvals and a validated way of using the tools. Jira gives you the structure; you still decide and document how you use it.
Do I need a separate requirements management tool?
Not necessarily. If requirements live as their own work item type in Jira, with stable IDs, testable acceptance criteria and links to tests and risk controls, a separate tool is often not needed. Teams with very large requirement sets or heavy reuse across products sometimes add a dedicated app on top of Jira.
Does Jira need to be validated?
ISO 13485 asks you to validate computer software used in your quality management system, for its intended use and in proportion to the risk (clause 4.1.6). That means validating how you use Jira and Confluence (your workflows, required fields, approvals), not the products in general. FDA's Computer Software Assurance guidance (final, September 2025) describes a similar risk-based approach. Because Atlassian Cloud changes continuously, plan how you re-check, not just the first validation.
Can Confluence hold the design history file (design and development file)?
Confluence can hold the documents that make up your design and development file, the ISO 13485 term the FDA now uses in place of the design history file, with page versions, review and approval. An app usually adds controlled approvals or electronic signatures. Your quality lead decides which records count as the file and how they're approved; the setup should make that easy to show.