How to Implement IEC 62304 in a Modern DevOps Pipeline (Traceability, SOUP, Risk Controls, and CI/CD Evidence)

Source: Dev.to

If you’re building SaMD or software inside a medical device, you’ve probably searched:

“How do I implement IEC 62304 in an Agile/DevOps workflow?”

The real challenge isn’t learning the standard—it’s operationalizing it while still feeling like modern engineering: PRs, CI/CD, IaC, containers, SBOMs, automated tests, and rapid releases.

IEC 62304 in a Nutshell

• Purpose: Defines software life‑cycle processes for medical‑device software.
• Non‑negotiable requirement: You must be able to prove end‑to‑end that software risk controls are implemented, verified, and that changes are controlled.
• Evidence pipeline = your traceability graph.

Safety Classes

The class determines how deep you go on unit verification, independence, trace depth, review rigor, anomaly handling, etc.

Engineering translation: Define a “compliance profile” (docs + CI rules) that changes based on class and feature risk.

Minimum Viable Traceability Graph

Hazard (ISO 14971) → Risk control → Software requirement → Design element
      → Code change → Test case → Test result → Release

This isn’t busywork—it’s how you prove risk controls are effective and survive audits without heroics. (IEC 62304 and ISO 14971 are commonly implemented together exactly for this mapping.)

Suggested Repository Layout

/docs                # compliance docs, risk analyses, etc.
/src                 # source code
/.github   (or /ci)  # CI/CD pipelines, GitHub Actions, etc.

Why This Works

1. Lifecycle alignment – plan → reqs → design → verification → release.
2. CI enforces evidence – no manual chasing later.
3. Tool‑agnostic – works with GitHub, GitLab, Bitbucket, etc.
4. No heavyweight tooling needed day 1 – just stable identifiers and machine‑checkable links.

Recommended Pattern: Typed IDs + PR Gating

Identifier Scheme

Enforced Rules (via CI / PR template)

• PR description must include at least one SRS-###.
• If the PR touches safety‑critical modules, a linked RC-### is required.
• Tests must reference the associated SRS-### in their metadata or docstring.
• CI builds a traceability report and fails if required links are missing.

Example PR Template Snippet

### Linked items
- **Requirements:** `SRS-041`, `SRS-044`
- **Risk controls:** `RC-012`
- **Tests:** `TST-201`, `TST-205`
- **Anomalies (if any):** `ANOM-033`

You’ve now turned “traceability” into an enforceable contract.

From Risk Controls to Engineering Artifacts

A common compliance gap: risk controls exist only in a PDF and are never part of the engineering workflow.

Represent risk controls as:

1. Requirements (with acceptance criteria)
2. Design constraints (architecture decisions)
3. Automated verification (tests + CI evidence)

Example: Alarm‑Timing Risk Control

• Risk control RC-012 – “Alarm shall trigger within 2 seconds.”
• Requirement SRS-041 – timing specification.
• Design SDS-010 – event loop + prioritization.
• Tests – TST-201 (integration), TST-202 (system).
• Release evidence – CI test report + performance logs archived as artifacts.

This creates a clean chain from risk → verification.

Managing SOUP (Software of Unknown Provenance)

IEC 62304 treats SOUP (open‑source libraries, OS components, third‑party SDKs, etc.) as part of the safety impact—if you ship it, you own it.

Minimal SOUP Control Strategy

1. Maintain a dependency inventory (SBOM is ideal).
2. Pin versions and lockfiles.
3. Define update rules – scheduled, reviewed, tested.
4. Validate safety impact for critical dependencies.
5. Add compensating controls – sandboxing, timeouts, retries, watchdogs.

CI “SOUP Gate”

Fail the build if a new dependency is introduced without:

• Recorded purpose
• Owner
• Version pin
• Risk note (even a brief one)

This distinguishes “we use open source” from “we control SOUP.”

Verification Evidence Required by IEC 62304

Making CI Produce Audit‑Friendly Artifacts

In your CI pipeline:

• Export a test summary (JUnit XML, HTML report).
• Archive versioned logs (performance, coverage, static analysis).
• Embed build metadata (commit hash, environment, tool versions).

Every build becomes a reproducible “mini release package.”

Further Reading

A deeper dive into IEC 62304, safety classes, and typical artifacts can be found here:

What is IEC 62304? – CitrusBits

Change Management & Release Documentation

IEC 62304 expects controlled change management and maintenance.

Engineering Translation

Your Git workflow is your change‑control system—if you structure it correctly.

Regulated PR Checklist (lightweight but powerful)

• What changed and why?
• Impacted requirements (SRS-###)?
• Impacted risk controls (RC-###)?
• Regression scope (which tests to rerun)?
• New anomalies?
• SOUP changes?

Automating the Boring Parts

• Map touched modules → required test suites.
• Enforce mandatory reviewers for safety‑critical areas.
• Block merging if trace links are missing.

CI‑Generated Release Bundle

Instead of assembling docs manually, have CI generate:

• Trace report (requirements ↔ tests ↔ results)
• SBOM / dependency inventory
• Test summary + environment metadata
• Known anomalies list (with risk‑assessment notes)
• Version ID & artifact hashes

Store these in an immutable artifact store (signed releases, controlled storage).

This turns audits from “storytelling” into “here’s the evidence bundle,” eliminating the #1 audit failure mode: missing or inconsistent documentation.

Happy compliant coding!

Conclusion

IEC 62304 isn’t something you “do once.” It’s something you embed:

• Traceability enforced via PR + CI
• Risk controls implemented as requirements + tests
• SOUP managed as part of dependency engineering
• Releases packaged with reproducible evidence

If you want a team that can help you implement IEC 62304 in a way that still feels like modern software delivery (Agile, CI/CD, cloud), explore CitrusBits here:

https://citrusbits.com/