Compliance inside your dev tools: the SaMD guide

By the time a software as a medical device (SaMD) team is preparing for a submission, audit, or major release, most of the evidence already exists. Requirements are in Jira. Code changes and reviews are in GitHub. Test results live in the development workflow. Release decisions are scattered across tickets, reviews, approvals, and defect discussions.

The problem is rarely that the engineers failed to document their work. The problem is that the documentation was created for engineering execution, not for a quality system. When quality has to extract, rewrite, and reformat that work after the fact, compliance becomes a parallel workstream instead of a byproduct of good software development.

That gap is the central challenge for SaMD quality operations. SaMD is software that performs a medical purpose without being part of a hardware device. For readers who need the broader classification and regulatory context first, Greenlight Guru's complete SaMD guide explains how SaMD is defined, classified, developed, and regulated. The definition matters, but it is only the starting point. The harder operating question is this: how do you keep every requirement, risk control, code review, test result, release decision, and design record connected as the software changes?

This guide explains how SaMD teams can build compliance inside the developer workflow, expanding on Greenlight Guru's SaMD quality operations in Jira and GitHub framework. The goal is not to pull engineers out of Jira and GitHub. The goal is to connect the work they already do to Greenlight Guru so the quality record stays current without manual reconstruction.

BONUS RESOURCE: Click here to download the cybersecurity gap assessment checklist for medical device teams

Why SaMD compliance breaks when engineering and quality work in separate systems

Traditional medical device quality systems were built around milestone documentation. That model can work for hardware, where design transfer often involves a physical product, controlled manufacturing processes, and relatively discrete design changes. SaMD is different. Design transfer is often the deployment pipeline. Postmarket maintenance is not an exception. It is the normal state of the product.

That difference changes where quality work concentrates. For SaMD teams, a large portion of the quality burden sits in design assurance and change control because every sprint, pull request, defect, and release candidate can affect the design record. If the development workflow and the quality system are disconnected, the team is forced to maintain two versions of reality.

The system of entry vs. the system of record

The system of entry is where work actually happens. Product managers and engineers use Jira to capture requirements, break down work, track defects, and manage release tasks. Engineers use GitHub to review code, approve pull requests, and preserve implementation history. Test results and build evidence are created inside the development workflow.

The system of record is where controlled quality evidence lives. It contains the design and development file, risk management connections, change approvals, audit trails, electronic signatures where required, and the structured records an auditor or reviewer expects to see.

When those two systems are separate, quality becomes translation work. Jira tickets may have to be rewritten as design inputs, or test reports need to be copied into a release package. Each translation introduces delay, ambiguity, and drift.

What IEC 62304 means for the developer workflow

IEC 62304 gives SaMD teams a framework for medical device software lifecycle processes. In day-to-day terms, it directs the team to plan the software work, define requirements, design the architecture, implement and verify the software, control releases, maintain the software after release, resolve problems, and manage configuration.

For developers, that means IEC 62304 is not just a documentation exercise. It is a workflow discipline. A compliant team needs to know which requirement a change supports, which risk control it implements, which test verifies it, which anomaly remains unresolved, and why the release decision is acceptable.

The IEC 62304 workflow map

• Software development planning: define the lifecycle model, responsibilities, tools, deliverables, and release approach.
• Software requirements analysis: identify software requirements that are testable, controlled, and traceable.
• Architecture and design: define the software structure at the right level of detail for the safety class and complexity of the system.
• Implementation and code review: preserve evidence of what changed, who reviewed it, and when it was approved.
• Verification and testing: link tests and results back to the requirements and risk controls they verify.
• Release: document known anomalies, configuration, version, release approval, and acceptance of residual risk.
• Maintenance and problem resolution: keep postmarket changes, defects, cybersecurity issues, and risk updates connected to the existing record.

Safety class should set the depth of evidence

IEC 62304 software safety classes affect the depth of required evidence. Class A software has the lightest burden. Class B adds more detailed requirements, risk analysis, and traceability. Class C requires the most rigorous lifecycle controls because the potential harm is highest.

What belongs in a software DDF for SaMD?

IEC 62304 does not define the design and development file. The DDF requirement comes from the quality system regulations and ISO 13485, but the DDF is where SaMD teams demonstrate that the IEC 62304 lifecycle was followed. For a deeper breakdown of that relationship, see Greenlight Guru's guide to IEC 62304 and the software DDF.

For software, the DDF should not be treated as a static folder assembled at the end of development. Software changes too often for that model to stay accurate. A useful software DDF is a living structure that connects the design record to the development workflow.

Core software DDF contents

• Intended use and indications for use.
• User needs and design inputs.
• Software requirements and acceptance criteria.
• Software architecture, design outputs, and configuration information.
• Risk analysis, hazards, risk controls, and residual risk decisions.
• Traceability from requirements to risk controls, tests, results, and release decisions.
• Verification and validation evidence.
• Code review evidence, including reviewer, change summary, approval, and date.
• Defects, problem reports, and unresolved anomaly decisions.
• Cybersecurity evidence, including vulnerability assessment and SBOM-related records when applicable.
• Release notes, release approval, version information, and configuration status.
• Design reviews, change control records, and postmarket maintenance records.

The DDF fails when these records exist but cannot be followed. A requirement that is not linked to a risk control is a weak record. A risk control that is not linked to verification evidence is a weak record. A release approval that does not account for unresolved anomalies is a weak record. The issue is not volume. The issue is traceability.

A living DDF solves that by making the relationships explicit. Requirements connect to risk controls. Risk controls connect to verification. Pull requests connect to requirements or change requests. Test evidence connects to release decisions. Quality reviews the record instead of rebuilding it.

How SaMD teams manage traceability from requirements to release

Traceability is the connective tissue of SaMD compliance. It is what turns disconnected engineering artifacts into a defensible design record. The strongest traceability model follows the product from the earliest need through the final release decision.

The requirements-to-release traceability chain

User need → design input → software requirement → hazard or risk control → design output → code change or pull request → test case → test result → unresolved anomaly decision → release approval

This chain should not be rebuilt by hand before every submission or audit. It should be maintained as work happens. When a requirement changes, the affected risks and tests should be visible. When a pull request is approved, the related requirement or change request should be clear. When a test fails, the release impact should be visible. When an anomaly is accepted at release, the rationale should connect back to risk.

That is the difference between traceability as a spreadsheet and traceability as a system property. A spreadsheet can describe the relationship at a point in time. A connected workflow maintains the relationship as the product changes.

Traceability should be generated, not reconstructed

• Create or sync controlled requirements so each requirement has a stable identifier.
• Link change requests to the requirements, risks, and tests they affect.
• Connect pull requests to the related requirement, defect, or change request.
• Capture verification evidence from the workflow that runs the tests.
• Keep unresolved anomalies linked to release decisions and risk rationale.
• Use Greenlight Guru's SaMD and SiMD development workflows as the quality system where those relationships become a controlled, reviewable record.

Where compliance evidence should live in the developer workflow

A developer-workflow approach does not ask engineers to abandon the tools they already use. It asks the organization to decide which evidence belongs where and how that evidence becomes part of the quality record.

Jira for requirements, change requests, defects, and anomalies

Jira is often where SaMD work gets translated into execution. That makes it valuable for requirements, change requests, release tasks, defects, and anomaly tracking. The key is to distinguish quality-significant records from ordinary engineering tasks.

A change request is not the same thing as a work order. A change request needs quality review because it may affect intended use, requirements, risk, verification, validation, labeling, cybersecurity, or release status. A work order may simply be the engineering task needed to implement an approved change. If those are treated as the same object, the quality workflow becomes noisy and difficult to govern.

GitHub for code review evidence

Pull requests often contain the evidence a software DDF needs for code review: what changed, who reviewed it, what was approved, when approval happened, and which issue or requirement triggered the change. That record is more reliable than a separate summary created weeks later because it is generated at the moment of review.

The quality system does not need engineers to rewrite a pull request into a document. It needs the relevant code review evidence to be connected to the controlled record, reviewed as appropriate, and preserved with the right context.

Test automation and CI/CD for verification and release evidence

Verification evidence often originates in test automation, build pipelines, and release workflows. That evidence can include test protocols, executed results, failed tests, resolved defects, build identifiers, release candidates, configuration status, and deployment records.

For SaMD teams, release evidence must do more than show that tests passed. It should show which requirements were verified, which anomalies remain open, how risks were evaluated, and why the release decision is acceptable.

Cybersecurity and SBOM evidence

Cybersecurity is part of the SaMD lifecycle because vulnerabilities can emerge after release. That means the quality record should account for threat analysis, security requirements, vulnerability review, software bill of materials information, risk decisions, and postmarket monitoring activities when they apply.

The same principle applies here: cybersecurity evidence should not become a separate documentation sprint. It should connect to the requirements, components, risks, tests, and changes that already define the product.

AI-enabled SaMD needs the same workflow discipline

If the SaMD product includes AI or machine learning, the workflow burden increases because teams need to control model behavior, data-related assumptions, validation evidence, change boundaries, and performance monitoring. But the operating model does not change. The evidence still needs to connect back to intended use, risk, requirements, verification, validation, and change control.

AI-enabled SaMD does not make traceability optional. It makes traceability more important because the team needs to explain what changed, why it changed, how it was evaluated, and whether the change remains within the approved product and risk profile.

Jira plugin vs. eQMS for SaMD: when dev tools stop being enough

A common question for SaMD teams is whether they can solve compliance by extending Jira. The answer depends on the problem they are trying to solve. If the problem is organizing engineering work, a Jira configuration or plugin can help. If the problem is maintaining a compliant quality system, the answer is different.

A plugin can add structure to tickets. It can support templates, trace links, workflow states, and lightweight reporting. Those capabilities are useful, but they are not the same thing as a controlled electronic quality management system (eQMS). SaMD teams still need design controls, risk management, change control, document control, audit trails, approval workflows, electronic signatures where required, and a DDF that external reviewers can follow.

What Jira plugins can help with

• Standardizing requirement ticket fields.
• Linking related tickets for requirements, defects, tests, and releases.
• Creating dashboards for engineering visibility.
• Adding lightweight review steps inside the development workflow.
• Helping engineers keep work organized before it enters the quality record.

Where an eQMS becomes necessary

• Controlled DDF structure and design history review.
• Risk management file linkage across requirements, hazards, controls, and verification.
• Document control, approval workflows, audit trails, and electronic signatures where required.
• Release approval that accounts for verification evidence, unresolved anomalies, and residual risk.
• Quality-system processes beyond development, including complaints, CAPA, audits, suppliers, training, and postmarket quality.
• A single source of truth that quality, engineering, regulatory, and leadership can use without reconciling parallel records.

The question is not whether Jira can be configured to contain compliance-like information. It can. The question is whether the resulting record can stand up as the controlled quality record for a regulated SaMD product. For early teams, a lightweight setup may be enough to stay organized. As the product moves toward submission, external review, Class B or Class C evidence depth, postmarket change, or a faster release cadence, the cost of manual reconciliation rises quickly.

That is when SaMD teams outgrow plugin-only workflows. The team does not need more places to document the same work. It needs a quality system that connects to the work already happening and turns that work into a living, audit-ready record.

How to build compliance inside your dev tools

The path to a better SaMD quality workflow is not a wholesale process rewrite. Start with the highest-friction evidence gaps and move them into a connected workflow one at a time.

1. Map the workflow from user need to release. Identify where requirements, risks, code changes, tests, anomalies, approvals, and release decisions are created.
2. Define the system of entry and system of record for each evidence type. Decide where work is created and where the controlled record must live.
3. Separate quality-significant change requests from ordinary engineering work. This keeps the change control workflow focused and defensible.
4. Establish stable links between requirements, risk controls, code changes, tests, results, anomalies, and releases.
5. Connect Jira and GitHub to Greenlight Guru so engineering evidence can become part of the quality record without manual rewriting.
6. Review the living DDF before release. Confirm that requirements, risks, tests, anomalies, approvals, and release rationale are current before the product ships.

This approach also changes the relationship between quality and engineering. Quality is no longer the team that arrives after development to reconstruct what happened. Quality becomes the team that designs the record structure so development work is captured correctly the first time.

That is the operating model SaMD teams need. Engineers keep working in the tools that support software development. Greenlight Guru maintains the controlled quality record. The DDF stays current because it is connected to the work that created it.

FAQ: SaMD compliance inside developer workflows

Can Jira be used for IEC 62304?

Yes. Jira can support IEC 62304 workflows when it is configured to manage requirements, change requests, defects, anomalies, verification tasks, and release planning in a traceable way. Jira should be connected to Greenlight Guru so those records are governed inside the quality system.

How do SaMD teams manage traceability?

SaMD teams manage traceability by linking user needs, software requirements, risk controls, implementation work, verification evidence, anomalies, and release approvals. The goal is continuous traceability that updates as work happens.

What belongs in a software DDF?

A software DDF should include user needs, design inputs, software requirements, design outputs, risk controls, verification and validation evidence, code review records, unresolved anomaly decisions, cybersecurity evidence, release records, design reviews, and change control documentation.

Is a Jira plugin enough for SaMD compliance?

A Jira plugin may help organize development work, but it is rarely enough for full SaMD compliance. SaMD teams need an eQMS for controlled records, DDF structure, risk management links, approvals, audit trails, electronic signatures where required, and broader quality-system processes.

What is automated traceability in SaMD?

Automated traceability means the relationships between requirements, risks, code changes, tests, anomalies, and releases are created and maintained as work happens. It reduces manual trace matrix maintenance and helps keep the DDF ready for review.

How does Greenlight Guru help SaMD teams work faster?

Greenlight Guru helps SaMD teams connect development work to the quality system so evidence does not have to be recreated manually. Requirements, risks, test evidence, release records, and design controls can stay connected in a living DDF while engineers continue working in their development workflow.

Keep reading

If you are building out your SaMD quality operations, these related guides go deeper on the specific components:

• SaMD quality ops: why Jira and GitHub belong inside your QMS
• IEC 62304 and the software DDF: design controls that do not slow engineers down
• Ultimate guide to software as a medical device (SaMD)
• IEC 62304 software safety classes: what they are and how to apply them
• How to apply IEC 62304 requirements for medical device software
• SaMD and SiMD development on Greenlight Guru

BONUS RESOURCE: Click here to run a structured cybersecurity gap assessment for your device

Final thoughts on SaMD compliance inside your dev tools

SaMD compliance should not require a parallel documentation universe. The evidence exists in the work: the requirement, the risk control, the pull request, the test result, the anomaly decision, the release approval. The job of the quality system is to make those relationships visible, controlled, and reviewable.

Teams that treat compliance as a separate documentation sprint will keep paying the same tax before every audit, submission, and release. Teams that build compliance into the developer workflow get a different outcome: a software DDF that stays current, traceability that is maintained continuously, and a QMS that moves at the speed SaMD development requires.

Greenlight Guru gives SaMD and SiMD teams a way to connect software development work to the quality system, reduce manual documentation, and maintain the traceability required to bring safer software-driven devices to market.

Ready to see how Greenlight Guru supports SaMD development workflows? Get your free demo of Greenlight Guru.