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?” Because the real challenge isn’t learning the standard—it’s operationalizing it in a way that still feels like modern engineering: PRs, CI/CD, infra-as-code, containers, SBOMs, automated tests, and rapid releases.
The one thing IEC 62304 really wants from engineering teams
IEC 62304 defines software life cycle processes for medical device software. But from an engineering perspective, it boils down to one non-negotiable requirement:
You must be able to prove—end-to-end—that software risk controls are implemented and verified, and that changes are controlled.
That “proof” is your evidence pipeline.
Step 0: Establish your safety class and let it drive rigor
IEC 62304 introduces software safety classes:
- Class A: no injury possible
- Class B: non-serious injury possible
- Class C: serious injury or death possible
Your class impacts how deep you go on unit verification, independence, trace depth, review rigor, anomaly handling, and more.
Engineering translation: define a “compliance profile” in your repo (docs + CI rules) that changes based on class and feature risk.
Architecture: treat compliance like a graph problem (not a doc problem)
The fastest compliant teams model IEC 62304 as a directed graph of artifacts and evidence.
The minimum viable traceability graph
At a high level:
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 how you survive audits without heroics. (IEC 62304 and ISO 14971 are commonly implemented together exactly for this mapping.)
A practical “IEC 62304-ready repo” layout
Here’s a repo layout that maps nicely to the lifecycle and supports automation:
/docs
/planning
software-development-plan.md
toolchain.md
verification-strategy.md
/risk
hazard-log.md
risk-controls.md
/requirements
srs.md
trace-matrix.csv
/design
architecture.md
interfaces.md
/release
release-checklist.md
known-anomalies.md
/src
/tests
/unit
/integration
/system
/.github (or /ci)
workflows/
Why this works
- It aligns to lifecycle expectations (plan → reqs → design → verification → release).
- It allows CI to enforce evidence, instead of humans chasing it later.
- It’s tool-agnostic and works with GitHub/GitLab/Bitbucket.
The engineering way to do traceability (without ALM pain)
You don’t need heavyweight tooling on day 1. You need stable identifiers and machine-checkable links.
Recommended pattern: typed IDs + PR gating
Define IDs like:
- Risk controls: RC-###
- Requirements: SRS-###
- Design: SDS-###
- Tests: TST-###
- Anomalies: ANOM-###
Then enforce:
- PR description must include at least one SRS-###
- If PR touches safety-critical modules, require linked RC-###
- Tests must reference SRS-### in test metadata/docstring
- CI builds a trace report and fails if 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.
Risk controls as code: make them explicit and testable
A huge compliance gap is “risk controls exist in a PDF” but not in the engineering workflow.
Instead, represent risk controls as:
- requirements (with acceptance criteria)
- design constraints (architecture decisions)
- automated verification (tests + CI evidence)
Example: alarm timing risk control
Risk control RC-012: “Alarm shall trigger within 2 seconds.”
Engineering artifacts:
- Requirement: SRS-041 (timing spec)
- Design: SDS-010 (event loop + prioritization)
- Tests: TST-201 (integration), TST-202 (system)
Release evidence:
- CI test report + performance logs archived as artifacts
This provides a clean chain from risk to verification.
SOUP in 2026: dependency risk is your default state
IEC 62304 calls out SOUP (Software of Unknown Provenance)—open-source libraries, OS components, third-party SDKs, etc.
Engineering translation: if you ship it, you own the safety impact—whether you wrote it or not.
Minimal SOUP control strategy that doesn’t slow teams down
- Maintain a dependency inventory (SBOM is ideal)
- Pin versions and lockfiles
- Define update rules (scheduled, reviewed, tested)
- Validate safety impact for critical dependencies
- Add compensating controls: sandboxing, timeouts, retries, watchdogs
*CI idea: “SOUP gate”
*
Fail build if a dependency is introduced without:
- recorded purpose
- owner
- version pin
- risk note (even brief)
This is the difference between “we use open source” and “we control SOUP.”
Verification strategy: tiered testing with evidence you can hand to auditors
For IEC 62304, you want verification evidence across:
- unit tests (logic-level)
- integration tests (interfaces, data flow)
- system tests (requirements-level behavior)
- plus non-functional: performance, reliability, security (as risk demands)
The trick: make CI produce audit-friendly artifacts
In CI:
- export a test summary (JUnit XML, HTML report)
- archive versioned logs (performance, coverage, static analysis)
- embed build metadata (commit hash, environment, tool versions)
- Now every build becomes a reproducible “mini release package”.
And yes—this maps well to FDA’s use of recognized consensus standards like IEC 62304 (Edition 1.1 consolidated version including Amendment 1 is explicitly in FDA’s recognized standards database).
If you want a deeper explanation of the standard itself—what IEC 62304 is, how safety classes change the rigor, and what artifacts teams typically maintain—this guide is a solid companion to the DevOps approach above:
[https://citrusbits.com/what-is-iec-62304/]
Change control: treat every merge like a regulated change request
IEC 62304 expects controlled change management and maintenance.
Engineering translation: your Git workflow is your change control system—if you structure it correctly.
A regulated PR checklist (lightweight, but powerful)
- What changed and why?
- Impacted requirements (SRS-###)?
- Impacted risk controls (RC-###)?
- Regression scope (what tests rerun)?
- Any new anomalies?
- Any SOUP changes?
Change impact analysis: automate the boring parts
- map touched modules → required test suites
- enforce mandatory reviewers for safety-critical areas
- block merging if trace links missing
Release: generate a “release dossier” automatically
Instead of assembling release 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 and artifact hashes
Store it with immutable retention (artifact store, signed releases, or controlled storage).
This turns audits from “storytelling” into “here’s the evidence bundle.”
What makes this approach “more compliant” than traditional docs?
Because it eliminates the #1 audit failure mode:
documentation that diverges from reality.
If evidence is produced directly by the engineering pipeline, it’s hard for it to lie.
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/]
Top comments (0)