← All engineering posts

What Is SaMD? Software as a Medical Device Explained

By Tammo Mueller

What Is SaMD? Software as a Medical Device Explained

A radiation oncologist spends a median of 55 minutes per patient manually drawing contours around Organs at Risk on CT scans. Spinal cord, parotid glands, brainstem, optic nerves. Miss a boundary by a few millimeters and the treatment planning system routes radiation through tissue that should have been spared.

Quantaras licensed research from Penn Medicine's Medical Image Processing Group to build ContourCompanion, an AI that automates this contouring. The algorithm came out of decades of work by Jayaram Udupa and Drew Torigian at the University of Pennsylvania. Quantaras brought the clinical relationships and domain expertise. We productized it: took a research prototype and turned it into an FDA-cleared, cloud-deployed, production-grade software as a medical device running on AWS. Within months of engaging, Quantaras submitted to the FDA and received 510(k) clearance.

That meant building everything the FDA requires around the algorithm: QMS compliant to FDA design controls, risk management, cybersecurity, clinical validation, cloud infrastructure, CI/CD pipelines, traceability, and an Algorithm Change Protocol so the AI could be retrained without filing a new 510(k) each time. The algorithm was maybe 20% of the work. The other 80% was making it auditable, safe, and deployable in a clinical environment where Varian and Elekta treatment planning systems expect DICOM RT Structure Sets to show up formatted exactly right.

This is the first post in an eleven-part series that documents how we did it, from regulatory strategy and risk management through cloud architecture, CI/CD, cybersecurity, and AI/ML validation. New posts publish weekly through April.

What Software as a Medical Device Actually Means

The IMDRF defined SaMD in December 2013 as "software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device."

The key phrase is "without being part of." ContourCompanion doesn't live inside a CT scanner or a linear accelerator. It runs on AWS, receives DICOM data over the network, runs inference, and sends contours back. It's a standalone piece of software that makes clinical decisions on its own. That makes it SaMD, not SiMD (Software IN a Medical Device).

The distinction shapes everything about how you build and regulate the product. SaMD means you can deploy globally from a single cloud region and ship updates without recalling hardware. But it also means you carry the full regulatory burden yourself. There's no device manufacturer to share it with.

Some examples to calibrate:

  • SaMD: an app that analyzes retinal images to detect diabetic retinopathy
  • SaMD: software that reads ECG data from a consumer smartwatch to flag atrial fibrillation
  • SaMD: ContourCompanion, processing CT scans to generate radiation therapy contours
  • Not SaMD: firmware inside an infusion pump that controls drug delivery
  • Not SaMD: a fitness app that counts steps (no medical purpose)

Where ContourCompanion Lands on the Risk Matrix

The FDA doesn't treat all SaMD equally. The IMDRF N12 framework uses a two-axis matrix. One axis: what your software does with its output (inform, drive clinical management, or treat/diagnose). The other: severity of the healthcare situation (non-serious, serious, or critical).

SaMD FunctionCriticalSeriousNon-serious
Treat or DiagnoseCategory IVCategory IIICategory II
Drive Clinical ManagementCategory IIICategory IICategory I
InformCategory IICategory ICategory I

ContourCompanion calculates OAR boundaries and radiation dose constraints. If the AI under-contours the spinal cord, the treatment planning system will route radiation through it. That's a severity S5 hazard: death or serious disablement. "Treat or Diagnose" on a critical healthcare situation. Category IV, the highest risk tier.

Here's an important nuance: IMDRF categories don't map 1:1 to FDA device classes. The FDA classified ContourCompanion as a Class II device (product code QKB) and cleared it via 510(k). Category IV from the IMDRF framework drove the rigor of our risk management, clinical evidence, and cybersecurity packages, but the regulatory pathway was still 510(k) because FDA had predicate devices in the radiology panel category. That distinction between IMDRF risk categorization and FDA regulatory classification trips up a lot of teams.

For context: there are now at least 15 FDA-cleared autocontouring products on the market, from Mirada's DLCExpert to Limbus AI (now Radformation) to Manteia's AccuContour. The competitive landscape is real. Getting cleared is table stakes for market entry.

Everything Around the Algorithm

Most articles about SaMD focus on the algorithm or the regulatory pathway. In practice, the algorithm was the part Quantaras already had. Penn Medicine's research group had been refining the contouring models for years. The hard part, and the part we were brought in for, was everything else. This is where teams without regulated software experience lose months.

Risk management is the connective tissue of the entire submission. ISO 14971:2019 requires you to identify every hazard, assess probability and severity, implement controls, and verify the controls work. For autocontouring, the hazard chains are specific and consequential. Organ under-contoured? Radiation hits healthy tissue. Target under-contoured? Tumor margin isn't fully covered. We catalogued dozens of hazards and traced each one through to a verified control. The risk management file isn't a compliance checkbox. It's the document FDA reviewers spend the most time on, and the one that ties your entire submission together.

Then there's clinical system integration, which is where most teams underestimate the effort. ContourCompanion doesn't exist in isolation. It receives DICOM CT data, runs inference, and produces DICOM RT Structure Sets that feed into treatment planning systems like Varian's Eclipse and Elekta's Monaco. Every field in those RT Structure Sets has to be exactly right, or the TPS silently drops the contour. DICOM conformance issues have nothing to do with AI and everything to do with byte-level formatting of structure set metadata. If you're building SaMD that integrates with clinical systems, budget serious engineering time for this.

The QMS has to exist before you write code. Not after. Not in parallel. Before. 21 CFR Part 820 requires design controls from the start of development. Every design decision needs a traceable record: what was the requirement, what was the design input, what was the verification result. We set up a phased QMS, starting with design controls, SDLC procedures, and risk management on day one, layering in CAPA, supplier controls, and management review as the project matured. Teams that skip this step and try to retrofit a QMS onto an existing codebase burn months reconstructing design history files after the fact.

Cybersecurity rounds out the picture. The FDA's September 2023 guidance made SBOM submission mandatory and the Secure Product Development Framework a baseline expectation. For ContourCompanion, that meant a threat model covering every attack vector on the DICOM ingestion pipeline, the inference engine, and the data path back to the treatment planning system.

And clinical validation requires real numbers, not benchmarks. For an AI autocontouring SaMD, the FDA expects Dice Similarity Coefficients, Hausdorff distances, and dosimetric impact analysis across a representative patient dataset. Published studies show AI contours achieving mean DSC of 0.81-0.86 with 69% time savings. Those are the industry benchmarks. Your submission needs to show your specific algorithm meets or exceeds them on your specific intended-use population.

How Quantaras Got This Done on $3M

A 2010 Stanford study estimated the average cost to bring a 510(k) medical device to market at $31 million. Quantaras raised roughly $3M in total funding, a mix of STTR grants from NCI and NSF, SBIR funding, and private investment from Phase 1 Ventures and Ben Franklin Technology Partners. That's an order of magnitude less.

Here's what made the difference on this specific project:

Quantaras established the quality management system and procedures. We executed within it, integrating electronic signatures, audit trails, and document control into the development workflow rather than running a parallel paper-based system. Design history file management, CAPA tracking, and supplier controls all mapped to 21 CFR Part 820 without a dedicated quality staff. The alternative is hiring a full-time quality team or paying a consultant to maintain binders, either of which would have consumed a significant chunk of that $3M budget.

Filing a Pre-Submission (Q-Sub) early was another force multiplier. Q-Subs are free. You submit a package with your proposed classification, intended use, and testing plan, and FDA gives you direct written feedback 60-75 days later. For ContourCompanion, the Q-Sub confirmed our regulatory pathway before we committed engineering resources to the wrong evidence package. A well-prepared Pre-Sub can prevent six months of rework. It's the single most underutilized tool in the FDA regulatory toolkit.

Infrastructure as Code gave us the audit trail as a byproduct. We defined the entire AWS deployment in CDK, with cdk-nag HIPAA packs catching compliance violations at synthesis time. Every infrastructure change was versioned, reviewed, and traceable. That's exactly what Part 820 requires, and we got it from building software the way we'd build it anyway.

The FDA itself has also made this more feasible. Computer Software Assurance (CSA) replaced exhaustive documentation with risk-based testing. The eSTAR template standardized submissions. As of December 2024, the FDA has authorized 1,016 AI-enabled devices, up from 6 in 2015. The regulatory environment is more accessible than it's ever been. But the bar for quality hasn't dropped.

What This Series Covers

We structured the series around a pattern we observed building ContourCompanion: SaMD complexity stacks in layers, and each layer multiplies the regulatory surface area.

Level 1: SaMD fundamentals. QMS, risk management, SDLC. Posts 1-4: what SaMD is, how to pick your regulatory pathway, IEC 62304 in practice, and ISO 14971 risk management.

Level 2: Cloud-native SaMD. AWS architecture, shared responsibility, HIPAA, infrastructure qualification. Posts 5-7: cloud architecture, Infrastructure as Code, and CI/CD for regulated environments.

Level 3: Cybersecurity. Threat modeling, SBOMs, SPDF, vulnerability management. Post 8.

Level 4: AI/ML SaMD. Algorithm validation, bias assessment, clinical study design, PCCPs. Posts 9-11.

Level 5: Post-market. Surveillance, CAPA, real-world evidence. Posts 12-13.

If you're building a non-AI on-premise SaMD, you might only need levels 1-2. If you're building what we built, a cloud-based AI SaMD that integrates with clinical systems like Varian Eclipse, you need all five.

Every post includes specific tools, specific regulation sections, and specific decisions we made, including the ones we'd make differently with hindsight.

Next up: FDA Regulatory Pathways for SaMD(coming March 10), where we walk through the pathway decision that shapes your entire project timeline and evidence burden.

Frequently Asked Questions

What is the difference between SaMD and SiMD?

SaMD (Software as a Medical Device) runs independently of any hardware medical device. SiMD (Software in a Medical Device) is embedded in or controls a hardware device, like firmware inside an infusion pump. The regulatory distinction matters because SaMD manufacturers carry the full regulatory burden themselves, while SiMD is regulated as part of the parent device.

How does the FDA classify SaMD risk?

The FDA uses the IMDRF N12 framework to categorize SaMD risk on two axes: what the software does with its output (inform, drive clinical management, or treat/diagnose) and the severity of the healthcare situation (non-serious, serious, or critical). This produces four risk categories (I through IV), with Category IV being the highest risk. IMDRF categories influence the rigor of your regulatory submission but don't directly determine the FDA device class or regulatory pathway.

Can a SaMD be FDA-cleared without clinical trials?

Yes. Most SaMD products are classified as Class II and cleared through the 510(k) pathway(coming March 10), which requires demonstrating substantial equivalence to a predicate device, not a full clinical trial. Clinical validation data (such as performance testing against expert-annotated datasets) is still required, but it's not the same as a prospective clinical trial. Only Class III devices going through PMA typically require clinical trials.

How much does it cost to get a SaMD FDA-cleared?

A realistic budget for a 510(k) SaMD submission ranges from $75,000 to $250,000+, including the FDA user fee ($6,084-$24,335), performance testing, and regulatory preparation. The largest variable is clinical validation: AI/ML SaMD with multi-site performance data across multiple anatomical structures will be at the high end. The total cost to build and clear a SaMD product, including engineering, QMS, and infrastructure, depends heavily on complexity. ContourCompanion was built and cleared on roughly $3M in total funding.

References

SaMDFDAMedical Device SoftwareRegulated Software