This article shows a practical way to build Class II Software as a Medical Device (SaMD) with IEC 62304, ISO 13485, and ISO 14971 compliance, while keeping engineers focused on shipping real product with minimal overhead. If you are early in the journey and still shaping your first release, we also help teams with medical software MVP development so they can validate concepts without painting themselves into a regulatory corner.
At SiteRocket Labs, we build software that needs to clear the bar for Class II SaMD under FDA and Health Canada, so we can’t treat traceability as a nice‑to‑have. At the same time, we run lean teams, and we actually like shipping features.
For these reasons, we’ve tuned our project management methodology and software development life cycle (SDLC) to make traceability a side‑effect of how we plan and build, instead of a parallel paperwork project.
This balance is especially critical in the early stages of a product; learn more about our approach to medical software MVP development.
A Practical Traceability Framework for Class II SaMD
When developing Class II SaMD applications, we follow three key principles:
- Use existing tools: We use the same core tools to manage our SaMD projects that we use for our non-SaMD work.
- Integrate compliance: Regulatory compliance and traceability are built into our daily development work.
- Utilize checklists: We employ predefined checklists to help ensure that no requirements are overlooked.
This approach allows our engineering teams to remain lean and focus on shipping a quality product, while simultaneously building the versioned, complete Design History File artifacts that regulators expect.
In this post, I’ll demonstrate how we put this into practice, using a fictional client – Acme Biomed – to provide a concrete example.
The Tools We Use
We use Asana as our project management system, and we run our regulated projects out of a single Asana project per product. That project becomes the operational “home” for four distinct types of work:
1. Project Requirements and Specifications
- These are the “design inputs” and System / Software Design Specifications that map directly to IEC 62304 and ISO 13485 expectations.
- We create one task for every major feature (similar to an “epic” in the Scrum/Agile world) and separate subtasks beneath it for each piece of functionality. Asana then automatically adds a unique ticket number to each subtask (e.g. ABS‑1, ABS‑2, etc. for Acme Biomed software design specs).
2. Risks
- Each Asana task is a different risk (in line with ISO 14971) and captures the hazard, hazardous situation, harm; initial risk; risk controls; and residual risk and acceptability rationale.
- Asana assigns an ID for each, which we then prefix with “R” – in the case of Acme Biomed, these would be ABR‑1, ABR‑2, etc. We then link risks to design inputs and specifications via Asana task links.
3. Work Tasks for the Team
- Design, development, QA, DevOps tasks all live here.
- They reference the specification tasks, but we deliberately keep them separate so specs don’t get buried under day‑to‑day chatter.
4. Internal Process and Checklist Tasks
- This part of the project contains tasks relating to our SOPs, as well as predefined security checklists that our various team members go through during each project.
- These are mapped to internal roles (architects, devs, QA, DevOps) and ensure we consistently hit our internal quality and security bar, not just the external standards.
Other Tools
In addition to Asana, we use Google Drive for supporting documents (risk analyses, design docs, meeting notes), Lucidchart for database schema and architecture diagrams, Figma for UX/UI designs, and TestRail for test case management and execution history. We also use GitHub for version control, with pull requests referencing our design specification IDs.
Everything feeds into one versioned Google Sheet that acts as our traceability matrix. That sheet ties together:
- Design inputs (ABI‑1, ABI‑2, …).
- Risk IDs (ABR‑1, ABR‑2, …).
- System/Software design specs (ABS‑1, ABS‑2, …).
- Test cases in TestRail (ABQ‑1, ABQ‑2, …).
- Design outputs (GitHub tags like v1.2.3).
By the time we’re done, that sheet is exported‑ready as part of the design history file.
While this might not be the most sophisticated way to maintain our traceability matrix, it works for us and is relatively quick and easy to deal with.
Our “Stepped Waterfall” SDLC, Optimized for IEC 62304
We describe our SDLC as a “stepped waterfall”: We follow the classical lifecycle that IEC 62304 expects (requirements & risk, architecture & design, implementation, verification, release/maintenance) but we run adjacent steps in parallel across different features to stay efficient.
SaMD Traceability, from Discovery to Launch
This flow shows how we connect IEC 62304 lifecycle stages with ISO 14971 risk controls and ISO 13485 design outputs in a single, audit-friendly traceability chain.
For Acme Biomed, a typical project looks like this:
1. Discovery Sprint
- We start with a high-level discovery sprint to understand clinical workflows, constraints, and regulatory context.
- Out of this, we define the initial design inputs (e.g. ABI‑1: The system shall allow radiologists to approve imaging reports from any device.).
2. Requirements & Risk
- We refine the above design inputs in Asana into a structured set of requirements and System/Software Design Specifications (ABS‑1, ABS‑2, etc.).
- In parallel, we identify and document risks (ABR‑1, ABR‑2) in Asana, as well as risk controls, in line with ISO 14971.
- The risk controls feed back into design inputs – security, privacy, patient safety aspects are requirements, not afterthoughts.
3. Architecture & Design
- We translate those specifications into architecture and database designs (Lucidchart), plus UX/UI flows (Figma).
- We link Asana specification tasks to the relevant diagrams so someone reviewing ABS‑3 can see the associated architecture and UI in one click.
4. Implementation
- Development tasks reference the corresponding design spec IDs so there’s a clear line from ABS‑3 to the code that implemented it.
- GitHub pull requests also reference those IDs (e.g. “Implements ABS‑3, ABS‑4”), giving us a natural hook from design spec to code changes.
5. Verification (QA & Test Automation)
- We design test cases (ABQ‑1, ABQ‑2) that map back to the design specs and their associated risks.
- Test cases and their execution history are stored in TestRail or sometimes a similar system; Asana holds the traceability from specs to tests.
6. Release & Maintenance
- When we deploy a release, we tag it in GitHub (e.g. v1.2.3) and link that tag to the design outputs row in the Google Sheet.
- Each row effectively says, “This output (v1.2.3) satisfies these design inputs (ABX-x), implemented by these design specs (ABS-x), covered by these tests (ABQ-x).”
We’re often designing the next feature while we’re building the current one and refining requirements for the one after that. But for each individual feature, the lifecycle is linear so that auditors can easily follow it end‑to‑end.
Traceability – Without Slowing Developers Down
A lot of teams get stuck because they treat traceability as something you bolt on at the end. We do the opposite: We make traceability the natural by‑product of how we create tickets, PRs, and test cases.
Here’s how that looks in practice for Acme Biomed.
1. IDs Everywhere – but Meaningful Ones
As seen above, we use clear, human‑readable IDs across the board. Those IDs show up in Asana task titles and descriptions, in TestRail test case names, and in GitHub.
This means that our developers don’t need to maintain a separate traceability document. They just follow normal workflow conventions: “If you’re implementing ABS‑3, your Asana development task and your PR both reference ABS‑3.”
2. A Clean Separation Between Specs, Risks and Work Tasks
In Asana, the software design specifications and risks are kept separate from the work tasks and the process/security checklists. This makes it easy for us to export the design inputs and risks into the design history file when needed.
For traceability, the important part is that specification tasks reference risks and design inputs, and that the work tasks reference the specifications. The relationships are encoded in cross‑links within Asana, and not in a giant monolithic spreadsheet.
3. A Versioned Traceability Google Sheet
All those links and IDs come together in a versioned Google Sheet that acts as our traceability matrix. We update it as we go and make sure it’s in good shape at major milestones:
Each row typically looks like:
- Design input ID (ABI‑7)
- Linked risk(s) (ABR‑3, ABR‑8)
- Software design specs that implement it (ABS‑9, ABS‑10)
- Test cases that verify it (ABQ‑12, ABQ‑13)
- Design outputs (e.g. v1.2.3 where the change first shipped)
We export that sheet at the end of each project (or major release) and snapshot it whenever we add significant enhancements. That gives us versioned, audit‑friendly evidence without forcing engineers to live in spreadsheets all day.
Where Risk Management Fits In (ISO 14971)
IEC 62304 and ISO 13485 care a lot about traceability; ISO 14971 cares about risk. In our process, risk is not a separate after‑the‑fact activity; it’s integrated right into the requirements phase as part of our broader focus on medical software regulatory compliance.
For Acme Biomed, that looks like:
- During requirements, we identify hazards and hazardous situations (e.g., wrong dose displayed, missed abnormal result, unauthorized access).
- For each hazard, we define risk controls and translate those into design inputs (ABI‑x) and security/privacy requirements.
- Those risk‑driven requirements then show up as System/Software Design Specifications (ABS‑x) and test cases (ABQ‑x) that specifically validate the risk controls.
In the traceability sheet, you can then trace:
ABR‑3 (Risk: Wrong patient record displayed)
→ ABI‑5 (Design input: System shall verify patient identifiers before displaying sensitive imaging records)
→ ABS‑7 (Design spec: Double‑check mechanism across MRN and DOB)
→ ABQ‑10 (Test: Verify patient header matches MRN + DOB across navigation)
→ v1.2.3 (first release where that control is implemented).
If you’re a CTO or clinical product owner, this is exactly the kind of story you want to tell during an audit or due diligence review, without scrambling to assemble it from scratch.
Keeping the Burden Light for Developers
The line we draw is simple: Developers should not have to become 62304 experts to work efficiently. That’s our job.
We do a few things to keep the cognitive load down:
- We put the “process thinking” into templates and checklists, not into every single ticket.
- We use IDs and links once, in the right place, instead of asking developers to mirror them across five tools.
- We link PRs to design spec IDs, which gives us a clean mapping from requirements to implementation without extra paperwork.
When we need stronger automated regression coverage, we’ll also embed stable locator IDs into front‑end code from the beginning, so test automation isn’t constantly breaking on minor UI tweaks. That improves both traceability and test robustness, especially for large, long‑lived clinical apps.
The result is a dev experience that feels like a well‑structured product team, not a compliance grinder—but still yields the artifacts that regulators expect.
Our Traceability Flow
If we drew our traceability flow on a whiteboard for Acme Biomed, it would look like this:
| Requirements & Risk | Design | Implementation & Tests | Releases |
| Risks (ABR‑x)Design inputs (ABI‑x) | System/Software Design Specs (ABS‑x) Architecture diagrams (Lucidchart)UX flows (Figma) | GitHub PRs (referencing ABS‑x)TestRail cases (ABQ‑x) | GitHub tags (v1.2.3) |
FAQ
What is a traceability matrix in medical software?
A traceability matrix links risks, requirements, design specifications, tests, and releases so that auditors can follow every feature from clinical intent through to verified implementation.
Do regulators require a specific tool for traceability?
No. Regulatory agencies such as FDA and Health Canada typically care about evidence and consistency, not tooling. What matters is showing clear relationships between risks, requirements, implementation, and verification.
How detailed does IEC 62304 traceability need to be?
Enough that an auditor can move from hazard to deployed software version without gaps. The exact format is flexible as long as the chain is complete.
Why This Matters
If you’re developing software that requires a Class II SaMD license, strong traceability and a practical IEC 62304 SDLC are no longer optional. You need software that:
- Can be shown to comply with IEC 62304, ISO 13485, and ISO 14971.
- Survives audits and due diligence without weeks of “let’s reconstruct what we did” panic.
- Still ships at a pace that makes sense for your market.
Our approach at SiteRocket Labs is to embed traceability directly into our projects, rather than layering it on top. By combining Asana, Google Drive, Lucidchart, Figma, GitHub, TestRail, and a disciplined, versioned traceability sheet, we document a clear story from risk and requirements through to tested releases, without grinding day‑to‑day development to a halt.
If you’re planning a Class II SaMD, or modernizing a clinical application that’s starting to hit regulatory headwinds, we would be happy to walk you through how this would look for your product. Contact us today for a free consultation.