IEC 62304 Traceability in Jira: What Medical Device Teams Need to Know

If you're developing software for a medical device, your team probably already uses Jira to manage requirements, development work, bugs, and testing.

But there's an important question that comes up during audits:

Can you prove how a requirement became software, and how that software was verified?

That's where traceability becomes critical.

What is IEC 62304?

IEC 62304:2006+AMD1:2015, Medical device software - Software life cycle processes, defines processes for developing, maintaining, and decommissioning software used in medical devices.

The standard covers activities including:

• Software development planning
• Software requirements analysis
• Software architectural design
• Detailed design
• Unit implementation and verification
• Integration and integration testing
• System testing
• Software release

The important point for Jira teams is that these aren't isolated activities. They need to be connected. A requirement shouldn't simply exist in Jira - you should be able to determine what implements it and what verifies it.

For example, consider a medical device containing software that controls an infusion pump. A high-level requirement might eventually connect to:

System Requirement → Software Requirement → Software Architecture → Software Design → Implementation → Unit Test → Integration Test → System Test

That chain is the evidence.

Why safety classification matters

IEC 62304 defines three software safety classes:

The higher the safety class, the deeper the expected traceability chain becomes. Class C software — like a dose calculation engine — needs a traceability chain that can withstand a regulator asking "prove it" about any single requirement.

What does traceability actually mean?

At a practical level, traceability means maintaining relationships between the artifacts created throughout development. For example:

Software Requirement → Software Item → Test Case → Test Evidence

You should also be able to follow those relationships in reverse. A test should tell you which requirement it verifies. A requirement should tell you which test verifies it.

This is bidirectional traceability — the core traceability chain running system requirements → software requirements → architecture → detailed design (where applicable) → implementation → verification, readable in either direction.

Why Jira alone can become difficult

Jira is excellent at managing development work. But simply having requirements, stories, and tests in Jira doesn't automatically give you an audit-ready traceability matrix.

Teams often end up doing this:

1. Development happens in Jira.
2. Requirements are linked to other issues.
3. An audit approaches.
4. Someone exports Jira data.
5. They build an Excel traceability matrix.
6. They manually check missing links.
7. The matrix is reviewed.
8. Jira changes again.

Now you have two sources of truth. Jira says one thing. The spreadsheet may say another.

The better approach

Instead of treating traceability as something you create immediately before an audit, make it part of the development process.

• Structure Jira around your development artifacts.
• Use explicit relationships.
• Monitor missing links.
• Generate your traceability evidence directly from the current Jira data.

That way, traceability isn't an audit exercise. It's part of your development workflow.

This is exactly the gap Links Explorer was built to close — turning the issue links already sitting in your Jira projects into a live, audit-ready traceability view, instead of a spreadsheet someone has to rebuild by hand.

What's next?

In the next article, we'll look at exactly how to structure Jira issue types and link types for an IEC 62304 traceability process.