Jira (Design Tool) is Atlassian’s issue and project tracking software, widely used in medical device development as an application lifecycle management (ALM) backbone for planning work, managing requirements, and linking design tasks for traceability. On its own, it is not IEC 62304 compliant; teams add plugins, overlays, or integrations to meet the traceability and audit-trail evidence regulated software demands.
What is Jira (Design Tool)?
Jira is a workflow and issue-tracking platform built by Atlassian. It organizes work into issues (stories, tasks, bugs) that move through configurable statuses on boards. Application lifecycle management (ALM) means managing a product from requirements through development, testing, and release in a connected way. Engineering teams use it as the day-to-day system of record for what needs to be built and who owns it.
In a medical device software program, Jira usually sits at the planning and execution layer. It holds user stories, design tasks, defects, and test tickets. By default, it is not a formal design history repository or a validated traceability system. That distinction matters because regulators expect specific, demonstrable links between requirements, design, code, and verification that a stock Jira configuration does not produce on its own.
Why Jira (Design Tool) matters in medical device development
Traceability is not optional in regulated software. IEC 62304 Section 5.7.1 requires documented links between software requirements, architecture, detailed design, and test results. ISO 13485 Clause 7.3 requires design outputs to trace to design inputs. Under the FDA Quality Management System Regulation (QMSR), effective February 2, 2026, ISO 13485:2016 is incorporated by reference, so that traceability expectation now carries the weight of US federal law.
The audit stakes are concrete. During an FDA inspection or Notified Body audit, an assessor will pick a high-risk requirement and ask a team to trace it down to the code module and the verification test, then back up to validation. A single break in that chain can render a device non-compliant. Because Jira is familiar to developers, teams reach for it first. The risk is treating a general-purpose tracker as if it already satisfies design controls, when the compliance evidence still has to be built around it.
How Jira (Design Tool) works in a regulated workflow
Used well, Jira maps cleanly onto parts of the design controls process:
- Requirements as issues. User needs, design inputs, and software requirements can each be issue types, with parent-child and “relates to” links forming the trace structure.
- Design and build tasks. Development work items link back to the requirement they satisfy, creating an implementation trail.
- Test tickets. Verification and validation cases link to the requirements they exercise, supporting the traceability matrix (RTM).
- Workflows as review gates. Custom statuses and transitions can enforce review and approval steps that mirror phase gates.
The gaps show up around evidence. Stock Jira does not generate a compliant RTM, provide electronic signatures aligned to FDA 21 CFR Part 11, or keep immutable, time-stamped audit trails of who changed what. Teams close these gaps three ways: compliance plugins that add signatures and locked records; validated overlays that turn Jira into a regulated platform in the same interface; or integration with a purpose-built ALM system (for example, Jama Connect, Polarion, or Codebeamer) that holds the formal traceability while Jira handles execution. Whichever path a team picks, the tool must be validated for its intended use, and that validation documented.
Common challenges and best practices
The most common failure is building the RTM by exporting Jira data into spreadsheets and reconciling it by hand: error-prone, and it falls apart as the software grows. Another recurring mistake is generating traceability retroactively, near submission, which invites rework and audit findings. Sprints also get confused with design planning; they execute work but do not replace the design plan, the software safety classification (IEC 62304 Class A, B, or C), or the verification strategy.
Good practice keeps the trace chain current as work happens, not after. Agile is compatible with design controls: AAMI TIR45 supports Agile, provided each sprint produces the required documentation. Configure issue types and link types to match your design controls SOP, restrict who can close records, and decide early whether a plugin, an overlay, or an external ALM will own the formal evidence. Fixing the tooling model at the start is far cheaper than remediating a broken matrix during an audit.
How SJML helps with Jira (Design Tool)
Syrma Johari MedTech (SJML) supports the underlying discipline that a tool like Jira has to serve: design controls and software lifecycle management for regulated devices. SJML’s engineering and QARA teams work across the IEC 62304 software lifecycle, ISO 14971 risk management, and design verification and transfer, with phase-gate program management and structured change control. That work includes defining the requirements, traceability, and review-gate structures a device program needs and aligning them with ISO 13485 and EU MDR expectations, so evidence holds up under audit regardless of which ALM tooling a client runs.
Talk to SJML’s engineering team →
Frequently asked questions
No. Jira is a general-purpose issue and project tracking tool, and a stock configuration does not meet IEC 62304 on its own. It lacks native requirements traceability matrix generation, electronic signatures, and immutable audit trails. Teams reach compliance by adding validated plugins or overlays, or by integrating Jira with a purpose-built ALM system validated for its intended use.
Teams model user needs, requirements, design tasks, and test cases as linked Jira issues so each requirement connects to its implementation and verification. Because stock Jira does not export a compliant matrix, most add a compliance plugin or integrate with an ALM platform that generates the RTM automatically. Maintaining these links as work happens avoids rework near submission.
Yes. Agile development is compatible with design controls when each sprint produces the documentation regulators expect. AAMI TIR45 provides guidance on aligning Agile with regulated device software. Jira suits this model, since boards and sprints match how Agile teams already work. The requirement is that user needs, risk controls, and verification stay traceable throughout, not reconstructed afterward.
Stock Jira lacks three things regulated software needs: automated, current requirements traceability; electronic signatures aligned to FDA 21 CFR Part 11; and locked, time-stamped audit trails showing who changed each record and when. Teams fill these gaps with compliance plugins, validated overlays, or integration with a dedicated ALM tool that owns the formal design evidence.
Related terms
- Requirements Traceability Matrix (RTM)
- IEC 62304
- Design Controls
- Application Lifecycle Management (ALM)
- Design History File (DHF)
