In brief
IEC 62304 requires lifecycle processes and evidence, not a particular tool. SaMD teams already working in Jira and GitHub can map requirements, design, verification, configuration, maintenance and problem resolution there, provided they close traceability gaps. A compliance / eQMS layer orchestrates that evidence without forcing an ALM migration. Edition 1 remains the published reference; Edition 2 is approaching (see where the revision stands).
What IEC 62304 expects (today)
The standard structures the medical device software lifecycle: planning, requirements analysis, architecture and detailed design, implementation, verification, configuration management, problem resolution, maintenance, and treatment of software of unknown provenance (SOUP). Software safety classification (classes A, B or C in Edition 1) modulates activity depth. Nothing in the text mandates Jira, GitHub or an ALM suite: what matters is that processes exist, are proportionate to class, and that evidence is recoverable for audit.
In practice, the pain is rarely “missing tickets”: it is the desync between the development flow, the QMS and the technical file. The right move is to decide which artefacts live where, then make requirements → design → verification → release links explicit.
Mapping the lifecycle in Jira
Jira carries planned work and priority decisions well. A useful mapping (adapt it; do not copy blindly):
-
Epics / initiatives
Feature batches or software versions, linked to the software development plan.
-
Stories / requirements
Software requirements (safety / performance), status, owner, link to risk analysis.
-
Tasks / sub-tasks
Design, implementation, review, unit or integration tests.
-
Bugs / problem reports
Anomalies, severity, patient / user impact, CAPA when the QMS requires it.
-
Workflows
Review and acceptance (not only Done), transitions by role.
Add fields or labels for safety class (A/B/C), software system / subsystem, and 62304 artefact type. Without that metadata minimum, audit export becomes a manual rebuild at every milestone.
Mapping evidence and configuration in GitHub
GitHub carries code, reviews and often CI. For IEC 62304, the value is not commit volume: it is the ability to recover, for a given release, what changed, who reviewed it, and which tests passed.
Pull requests
A PR linked to a Jira ticket, with review, impact description and test criteria, is evidence of design / implementation and partial verification. Require the ticket link in the PR template.
Commits and tags
Conventional messages and release tags (semver or equivalent) anchor software configuration. The release tag must point to the tested, documented build, not only to “main”.
CI and releases
Build / test / static analysis pipelines archived per release, plus release notes, form a verification and configuration-management baseline. Keep logs and artefacts recoverable.
For SOUP: dependency inventory (lockfiles, SBOM), use justification, tracking of vulnerabilities and known anomalies, and impact on classification. Dependency tools help; they do not replace documented evaluation.
The most common traceability gaps
Audits rarely fail on “there is no Jira”. They fail on broken chains:
- software requirement with no link to a verification test or to risk;
- code change merged without a ticket, or a ticket closed without test evidence;
- release deployed without a configuration baseline (commit, SBOM, environment);
- field problem handled in chat, never reopening the problem-resolution process;
- maintenance and patches outside QMS change control.
A requirements ↔ design ↔ verification ↔ release matrix, generated or kept current from Jira/GitHub, reduces that risk. If the matrix only exists in a disconnected spreadsheet, it drifts at the first high-pressure sprint.
Where DevTools stop, and the compliance layer starts
Jira and GitHub excel at producing development artefacts. They do not replace the QMS (CAPA, training, doc control, management review) or the orchestration of evidence for a notified body. That is where a layer such as Qapsule, connected to the existing stack, and eQMS in your tools, make sense: centralise evidence and traceability without forcing an ALM migration. To situate that choice against other market references, see Qapsule vs Ketryx and alternatives.
Edition 2: anticipate without switching too early
Edition 2 is still under revision (publication forecast 2028 per the IEC tracker); drafts converge toward two rigor levels instead of classes A/B/C, plus cloud and AI clarifications. Keep the A/B/C mapping operational, and already sketch a correspondence table to future levels. Timeline and impacts: IEC 62304 Edition 2: where does the revision really stand?
Action plan
- List IEC 62304 clauses applicable to your class and the master document / tool for each.
- Define Jira issue types, fields (class A/B/C, software system) and review workflows.
- Enforce ticket ↔ GitHub PR linkage, and archive CI + release tags per software version.
- Keep a current SOUP inventory, linked to releases and anomalies.
- Build (or generate) the requirements ↔ verification ↔ release matrix and test it in a dry-run audit.
- Connect problem resolution and maintenance to QMS change control / CAPA.
- Decide whether a compliance / eQMS layer on the current stack is enough before considering an ALM suite.
Conclusion
IEC 62304 is won on evidence discipline, not on a tool brand. Jira and GitHub can carry the SaMD lifecycle if traceability is designed on purpose; the quality layer closes what DevTools alone do not.
FAQ
Do Jira and GitHub make you IEC 62304 compliant?
No. Tools do not certify you. They can carry lifecycle artefacts (requirements, tasks, PRs, releases, problem tickets) if your procedures, classifications and evidence are defined and kept current.
Must SaMD teams migrate to an ALM suite?
Not necessarily. Many teams keep Jira and GitHub and add a compliance / eQMS layer to industrialise evidence and traceability. A native suite only fits if you truly lack a system of record and accept migration. See our comparison.
Where should software safety classification be documented?
In the software file / development plan, with justification linked to risk analysis. In Jira, a class field or label (A/B/C today) on relevant items helps consistency, without replacing the master document.
How should SOUP be handled in GitHub?
Maintain a SOUP inventory (dependencies, versions, justification, known anomalies) linked to components and releases. Manifests (lockfiles), SBOM and anomaly tickets provide evidence, not automatic conformity.
Does Edition 2 already change the Jira mapping?
Not operationally yet: Edition 1 remains the published reference. Monitor the revision (classes to rigor levels) and prepare a documentation mapping. See IEC 62304 Edition 2.
QARA PULSE guide on the operational application of IEC 62304 (Edition 1) with Jira and GitHub. This is not a certification, nor personalised legal advice. Adapt the mapping to your classification, QMS and notified-body expectations.