#1What actually counts as SaMD
SaMD is software intended to perform a medical purpose without being part of a physical device. The IMDRF definition is broad and the FDA's interpretation has continued to expand. The litmus test we run with founders is: 'Could a clinician's decision change because of what the software outputs?' If yes, the product is in scope and the regulatory clock starts now.
- Diagnostic decision support → almost always SaMD.
- Patient-facing symptom checkers → frequently SaMD, often higher risk than founders expect.
- Workflow tools that surface clinical information without recommending an action → usually out of scope.
- Monitoring dashboards that trigger alerts → SaMD if the alert influences clinical action.
#2Classifying risk before you classify your feature backlog
The IMDRF SaMD framework classifies risk by combining the significance of the information provided (treat / diagnose / drive clinical management / inform clinical management) with the severity of the condition (non-serious / serious / critical). The classification you land on dictates the rigour of your software lifecycle, your verification evidence, and the depth of your pre-submission package.
#3Process overhead that is worth its weight
Regulated software does not require you to abandon agility. It requires you to make a handful of artefacts a permanent part of your engineering rhythm: a living risk file, a software development plan, traceability between requirements and tests, and a documented change-control process. We treat each one as code: stored in the same repository as the product, reviewed in the same pull-request workflow.
- Risk management file aligned to ISO 14971, updated every time a hazard analysis changes.
- Software requirement specifications written next to user stories, not in a separate doc system.
- Verification evidence collected from CI; every regulated requirement maps to a test that runs on every commit.
- Cybersecurity assessment refreshed before each substantive release, mapped to the FDA pre-market cyber guidance.
#4Engineering cadence under IEC 62304
IEC 62304 is the international standard for medical device software lifecycle, and it is more compatible with continuous delivery than its reputation suggests. The trick is to wire its required activities — planning, requirement analysis, architectural design, verification, configuration management, problem resolution — into the day-to-day engineering loop so they happen naturally rather than as a sprint to a milestone.
- Architectural decision records capture the design rationale auditors look for.
- Pull-request templates remind engineers to update the trace matrix before merge.
- Release notes auto-generate from labelled commits, satisfying the change history requirement.
- Post-market surveillance hooks feed real-world signals back into the risk file.
