Medical Software Design Controls (ISO 13485 & FDA §820)

Last Audited: 2026-08-14
Tier-2 Authoritative (ISO 13485:2016 / FDA 21 CFR §820)
In Plain Language

Medical device software must prove that it is safe, reliable, and built exactly as intended. Design controls are a structured set of checkpoints that connect what users need to what engineers build and test. Instead of waiting until the end of a project to assemble paperwork, teams capture clear requirements, conduct peer reviews, and run automated tests continuously. This ensures every piece of code has documented proof showing why it was written and how it was tested before reaching patients.

1. How Medical Design Controls Work

When software directly affects patient care or clinical decisions (often called Software as a Medical Device, or SaMD), regulators like the United States Food and Drug Administration (FDA) and international bodies following ISO 13485 require a formal development process.

Design controls ensure three fundamental rules:

  • Every feature starts with a real user need: You cannot add unapproved code or undocumented features.
  • Every requirement has a test: Automated tests and clinical checks prove the code functions correctly.
  • Every change is reviewed: Updates are reviewed for safety risks (using the risk management standard ISO 14971) before release.

2. The Design History File (DHF) Flow

The Design History File (DHF) is the complete collection of evidence proving your software followed its planned development process. The diagram below illustrates how work flows from user needs to verified release artifacts:

Design History File (DHF) Traceability Process FlowFlowchart showing User Needs leading to Software Requirements, System Architecture, Testing & Verification, and the completed Design History File index.1. Define User NeedsClinical Intended UseFDA §820.30(c)2. Write RequirementsSoftware Spec (SRS)ISO Cl. 7.3.33. Design ArchitectureDesign Spec (SDS & ADR)ISO Cl. 7.3.44. Verify & ValidateAutomated V&V TestingISO Cl. 7.3.6 / 7.3.75. DHF IndexAudit RecordsFDA §820.30(j)Risk Management (ISO 14971) — Hazard Analysis & Mitigation runs across every stageEvery identified safety hazard must have a corresponding verification test in the final release package
Figure 1: Plain-Language Traceability Pipeline — from User Needs to formal DHF audit index.

3. Verification vs. Validation (V&V)

A common mistake in regulated software is confusing Verification with Validation. While they sound similar, they answer two completely different questions:

ISO Clause 7.3.6

Verification: “Did we build the system right?”

Testing whether the code matches its technical specifications. Verified using automated unit tests, static code analysis, API integration tests, and database schema validation.

ISO Clause 7.3.7

Validation: “Did we build the right system?”

Testing whether the software actually solves the user’s real-world problem and functions safely in clinical workflows. Verified through user acceptance testing (UAT) and clinical trials.

4. Auditor Readiness Checklist

Release Quality Gate Checklist
✓Every requirement in the Software Specification has a unique, immutable ID (e.g. SRS-101).
✓Risk mitigation controls from ISO 14971 are tied directly to automated test cases.
✓Peer reviews and design sign-offs are documented with reviewer names and timestamps.
✓Automated test execution logs are locked in version control alongside the exact Git commit SHA.
✓Production deployment pipelines automatically check that all verification gates pass before release.

Community Discussion & Feedback

Attributed peer feedback and official Netspective architecture notes.

Was this documentation helpful?(100% found this helpful • 0 ratings)

Leave Feedback or Question

○ Loading user info...
0/2000 chars

Discussion (0)

Loading discussion thread...