The Device Is Software. The Factory Is Your SDLC.
Regulatory strategy for SaMD — software that diagnoses, drives, or informs clinical care on its own, cleared under a framework written for hardware.
Your Product Ships Monthly. The Framework Was Written for Devices That Ship Once.
Software as a Medical Device is software that performs a medical purpose without being part of a hardware device — reading images, flagging deterioration, computing a dose. The law treats it like any other device: classification, premarket review, a quality system, design controls. What the law does not do is slow your release cadence down to match.
That mismatch is the whole discipline. A submission describes a version; your roadmap describes a stream. The companies that do this well don’t fight the framework — they build an SDLC that produces regulatory evidence as a by-product of normal engineering, so that every release is either inside the cleared envelope or knowingly, deliberately outside it.
For SaMD, the audit walks your repository, your backlog, and your release pipeline — not a production line.
Two Questions Place Your Software. Everything Else Follows.
The IMDRF framework crosses the state of the patient with what your output does to the clinical decision. The answer calibrates evidence, review intensity, and oversight worldwide.
The grid is a conversation, not a statute. FDA never codified the IMDRF categories, but reviewers think in them; the EU wrote them into MDR Rule 11 almost verbatim, which is why most medical software lands Class IIa or higher in Europe. Where your product sits on this grid is the first thing we establish — because it decides the clinical evidence, the pathway, and how much of your roadmap needs the agency’s permission.
Six Disciplines That Carry a SaMD File.
From the qualification question — is this a medical device at all? — to the change discipline that keeps version 4.2 legal.
Classification & Qualification
Whether your software is a device, which regulation captures it, and where it lands on the risk grid — settled in writing before you build to it.
Pathway Strategy
Predicate selection on intended use rather than feature lists, De Novo when the class doesn’t exist yet, and Pre-Sub meetings that ask answerable questions.
Lifecycle & Documentation
A software lifecycle that emits the file — safety classification, documentation level, and verification records produced by the pipeline, not reconstructed after it.
Clinical Evaluation for Software
Analytical validation, then clinical validation sized to the risk category — including standalone performance studies where the output drives care.
Rule 11 & MDCG 2019-11
European classification that routinely surprises US teams: the same product, one class higher, with a notified body in the loop.
Version & Change Discipline
The release-by-release call — inside the cleared envelope, a letter-to-file, or a new submission — made by procedure instead of by argument.
The cleared version is one frame of a moving product. The file has to say how the next frame stays legal.
One Early Call — Basic or Enhanced — Sets the Spine of the Submission.
FDA’s premarket software guidance asks one structural question: could a failure, before any mitigation, lead to serious harm? The answer selects Basic or Enhanced documentation and with it the depth of architecture views, hazard analysis, and testing records the reviewer expects. Get it wrong in the optimistic direction and the deficiency letter writes itself.
The rest of the spine is standards: IEC 62304 for the lifecycle, ISO 14971 for risk, IEC 82304-1 for the product-level view, usability under IEC 62366-1. We map each one to artifacts your engineers already produce — because a standard implemented as a parallel paperwork universe fails its first audit.
The Facts a SaMD Program Plans Around.
None of them are negotiable, and all of them are cheaper to respect on day one.
The EU classification rule that puts most diagnostic or therapeutic software at Class IIa or above — notified body review, not self-certification.
The documentation-level decision in FDA’s software guidance. It is made once, early, and every artifact in the submission inherits it.
The lifecycle standard your development process is audited against — retrofitting it after the code exists costs more than the code did.
Six Failure Modes We Are Brought In to Prevent.
Most of them are decisions that felt like engineering shortcuts and turned out to be regulatory ones.
62304 retrofitted after the build
A finished codebase with no lifecycle records — so the “documentation” becomes archaeology, performed under submission deadline.
Agile pitted against design controls
Treating design controls as waterfall paperwork instead of mapping them onto sprints — both systems lose, and the auditor notices.
A predicate chosen on features
510(k) equivalence argued on what the software does rather than its intended use and technology — the mismatch surfaces in review, at full price.
“Decision support” that drives care
A product positioned as advisory while the UI leaves the clinician nothing to independently review — the CDS carve-out does not stretch that far.
The EU discovered late
A US-cleared product that meets Rule 11 for the first time during launch planning, and loses a year to notified body scheduling.
Releases that were really submissions
Updates shipped as maintenance that changed the intended use or the algorithm — each one a new 510(k) question answered by nobody.
SaMD Regulatory Leadership That Speaks Engineering.
Our software leads have qualified products, negotiated documentation levels, and built 62304 lifecycles inside real release pipelines.
“In software, the quality system isn’t a department that reviews the product. It is the pipeline that produces it — and the submission is whatever that pipeline can prove.”
The discipline we bring to diagnostic, therapeutic, and monitoring software.
Shipping Software That Treats or Diagnoses? Classify It Before You Build the File.
Bring senior SaMD leadership in while the architecture is still cheap to change — not after the deficiency letter.
Senior-led. Embedded in your team. No junior hand-offs.