The line between "software" and "medical device" has blurred dramatically. Diagnostic algorithms, clinical decision support tools, patient monitoring apps, and AI-powered imaging analysis all potentially qualify as Software as a Medical Device (SaMD) — a classification that triggers FDA regulatory oversight, quality management requirements, and development process controls that most software teams have never encountered.
This guide covers what SaMD is, how to determine if your software qualifies, which regulatory pathway applies, and how to build compliant medical device software.
What Is Software as a Medical Device?
The International Medical Device Regulators Forum (IMDRF) defines SaMD as:
Software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.
Key distinction: SaMD is the medical device. It's not software that controls a hardware device (that's Software in a Medical Device, or SiMD). SaMD runs on general-purpose computing platforms — smartphones, tablets, cloud servers — and performs medical functions independently.
What Qualifies as SaMD
| Category | Examples | Typically SaMD? |
|---|---|---|
| Diagnostic algorithms | AI that analyzes medical images, ECG interpretation, pathology slide analysis | Yes |
| Clinical decision support | Tools that recommend treatments, flag drug interactions, calculate risk scores using patient data | Often yes (depends on specifics) |
| Patient monitoring | Apps that detect abnormal vital signs and alert clinicians | Yes |
| Treatment planning | Radiation therapy planning software, surgical navigation | Yes |
| Companion diagnostics | Software that determines eligibility for specific treatments | Yes |
What Does NOT Qualify as SaMD
| Category | Examples | Why Not SaMD |
|---|---|---|
| Administrative | EHR systems, scheduling, billing | Not performing a medical function |
| General wellness | Fitness trackers, calorie counters, meditation apps | General wellness, not disease-specific |
| Clinical communication | Secure messaging between providers, telehealth video (alone) | Communication tool, not diagnostic |
| Data display | Software that only displays data without interpretation | No medical decision-making function |
| Clinical decision support (exempt) | Tools that display information without making recommendations, intended for clinician review | Exempt under 21st Century Cures Act (section 3060) |
FDA Classification and Risk Framework
The FDA and IMDRF classify SaMD based on two dimensions: the significance of the information the software provides and the seriousness of the healthcare situation it addresses.
IMDRF Risk Categories
| Risk Category | Healthcare Situation | Information Significance | Examples |
|---|---|---|---|
| Category IV (highest) | Critical or life-threatening | Treats or diagnoses | AI that detects pulmonary embolism on CT scan |
| Category III | Serious | Treats or diagnoses | Algorithms recommending cancer treatment protocols |
| Category II | Non-serious | Treats or diagnoses | Acne severity grading for treatment recommendations |
| Category I (lowest) | Any | Informs clinical management | Dashboard aggregating vital signs for clinical review |
FDA Device Classification
| FDA Class | Risk Level | Regulatory Pathway | Timeline | Cost |
|---|---|---|---|---|
| Class I | Low | Generally exempt from premarket submission | N/A | Minimal |
| Class II | Moderate | 510(k) Premarket Notification | 3-12 months | ,000-,000 |
| Class III | High | Premarket Approval (PMA) | 1-3 years | ,000-,000,000+ |
De Novo Classification
If your SaMD is novel (no predicate device exists) but lower risk, the De Novo pathway creates a new Class I or Class II classification. This is increasingly common for AI/ML-based SaMD with no equivalent predicate.
Quality Management System: ISO 13485
SaMD development requires a Quality Management System (QMS) that meets ISO 13485:2016 requirements. This standard defines processes for:
Design Controls (21 CFR 820.30)
| Phase | Deliverable | Purpose |
|---|---|---|
| Design Input | Requirements specification | Document what the software must do |
| Design Output | Architecture, code, documentation | The actual software and its documentation |
| Design Review | Review records | Formal review at defined stages |
| Design Verification | Test results | Confirm software meets specifications |
| Design Validation | Clinical evidence | Confirm software meets user needs |
| Design Transfer | Manufacturing/deployment procedures | Controlled release process |
| Design Changes | Change control records | Track and approve all changes |
IEC 62304: Software Lifecycle Processes
IEC 62304 defines the software development lifecycle for medical device software. It classifies software by safety:
| Safety Class | Hazard | Requirements |
|---|---|---|
| Class A | No injury or damage to health | Basic requirements |
| Class B | Non-serious injury | Detailed requirements, unit-level architecture |
| Class C | Death or serious injury | Full requirements at all levels, including unit-level verification |
Key IEC 62304 requirements:
- Software development planning
- Software requirements analysis
- Software architectural design
- Software detailed design (Class B and C)
- Software unit implementation and verification
- Software integration and integration testing
- Software system testing
- Software release
- Software maintenance
- Software configuration management
- Software problem resolution
Building SaMD with Elixir Phoenix
The backend architecture for SaMD must meet the same regulatory requirements as the client-facing software. We use Elixir Phoenix for SaMD backends because the BEAM VM's architecture aligns with the reliability and traceability demands of medical device software.
Fault Tolerance via the BEAM VM
The BEAM (Bogdan/Bjorn's Erlang Abstract Machine) was designed by Ericsson for telecom switches requiring extreme reliability. Ericsson's AXD301 switch achieved 99.9999999% uptime (nine nines) over 20 years — the kind of reliability that medical device regulators want to see.
How BEAM fault tolerance maps to SaMD requirements:
- Process isolation: Each computation runs as an isolated lightweight process (~2KB). A fault in one diagnostic algorithm execution cannot corrupt another patient's analysis. This directly supports IEC 62304's requirement for software unit isolation.
- Supervision trees: Hierarchical process monitoring with automatic restart strategies. When a process crashes, its supervisor restarts it in a known-good state within microseconds. This provides the fault recovery mechanism that regulators assess during design verification.
- "Let it crash" with recovery: Instead of hiding failures behind try/catch blocks (which can mask bugs and create partial state corruption), Elixir processes crash and restart cleanly. Every crash is logged, creating the audit trail that FDA reviewers need to see.
- Hot code upgrades: Deploy security patches and bug fixes without stopping the application — critical for Class II and III devices that cannot have unplanned downtime.
Traceability and Audit Trails
IEC 62304 and 21 CFR 820 require traceability from requirements through implementation to testing. Elixir's design supports this:
- Immutable data structures: Elixir's functional nature means data transformations are explicit and traceable. No hidden mutations.
- Pattern matching: Explicit handling of all expected data shapes. The compiler warns about unhandled cases, reducing the risk of unexpected behavior.
- OTP behaviors: GenServer, Supervisor, and other OTP behaviors provide well-tested, documented patterns that simplify design documentation.
Real-Time Processing
Many SaMD applications require real-time or near-real-time processing:
- Continuous vital sign monitoring with threshold alerts
- Real-time ECG analysis
- Live medical image processing during procedures
The BEAM's preemptive scheduler ensures no single computation blocks others. Phoenix Channels provide proven WebSocket infrastructure (benchmarked at 2 million concurrent connections) for pushing results to clinicians in real-time.
HIPAA Compliance for SaMD
If your SaMD handles Protected Health Information, HIPAA requirements layer on top of FDA requirements. This is common — most diagnostic and decision support tools process patient data.
Key HIPAA requirements for SaMD:
- Encryption at rest (AES-256) and in transit (TLS 1.3)
- Role-based access controls with audit logging
- Business Associate Agreements with all infrastructure vendors
- Breach notification procedures
- Annual risk assessments (updated 2026 requirement)
The Outsourcing Risk for SaMD Development
SaMD development outsourcing to developing nations creates a compound compliance risk: both FDA QMS requirements and HIPAA obligations must be maintained across borders.
FDA Perspective
The FDA requires that:
- Software development processes follow IEC 62304
- Design controls are documented and traceable
- The Quality Management System is auditable
- Corrective and Preventive Actions (CAPA) are timely
Offshore development teams may not have experience with medical device regulations. Design control documentation, risk management files (ISO 14971), and traceability matrices require training and discipline that general software shops may lack.
HIPAA Perspective
As detailed in our HIPAA compliance guide, offshore development introduces:
- Unenforceable Business Associate Agreements
- Data sovereignty conflicts with GDPR, PIPL, and other regulations
- Developer PHI access without proper controls
- Breach notification complications across jurisdictions
- Audit trail gaps across time zones
Combined Risk
For SaMD that also handles PHI (which is most SaMD), the risks compound. An offshore team that lacks FDA QMS experience AND doesn't understand HIPAA's technical safeguards creates dual regulatory exposure. The covered entity faces both FDA enforcement actions and HIPAA penalties.
Our approach: All SaMD development at Of Ash and Fire is performed by US-based engineers experienced in both FDA QMS (IEC 62304, ISO 13485, ISO 14971) and HIPAA technical safeguards.
The EU MDR Perspective
If you plan to market your SaMD in the European Union, the Medical Device Regulation (MDR 2017/745) applies.
Key Differences from FDA
| Aspect | FDA | EU MDR |
|---|---|---|
| Classification | Based on risk category and predicate | Based on Rules 9-11, often higher classification |
| Review body | FDA directly | Notified Body (BSI, TUV, etc.) |
| Marking | FDA clearance/approval | CE marking |
| QMS standard | 21 CFR 820 (FDA QSR) | ISO 13485 (accepted by both) |
| Clinical evidence | Depends on pathway | Always required for Class IIa+ |
| Post-market surveillance | 510(k) updates as needed | Periodic Safety Update Reports |
The EU MDR generally classifies software at higher risk levels than the FDA. Software intended for diagnosis is typically Class IIa or higher, requiring Notified Body involvement.
If you plan to sell in both markets, design your QMS to satisfy both FDA QSR and EU MDR from the start. ISO 13485 provides the foundation for both.
Regulatory Pathway Decision Tree
-
Does your software perform a medical function?
- No → Not SaMD. Standard software regulations apply.
- Yes → Continue.
-
Is it exempt under 21st Century Cures Act Section 3060?
- Displays, analyzes, or transmits data without making recommendations? → Likely exempt.
- Makes treatment or diagnostic recommendations? → Not exempt. Continue.
-
Does a predicate device exist?
- Yes → 510(k) pathway (Class II)
- No → De Novo pathway or PMA (depending on risk)
-
What is the risk classification?
- Category I (inform) → Class I, likely exempt from premarket submission
- Category II-III → Class II, likely 510(k) or De Novo
- Category IV → Class III, likely PMA
-
Do you also handle PHI?
- Yes → Layer HIPAA compliance onto FDA requirements
- No → FDA requirements only
Getting Started with SaMD Development
SaMD development requires expertise in both software engineering and medical device regulation. Our discovery process helps healthcare organizations:
- Determine if your software qualifies as SaMD and which classification applies
- Identify the regulatory pathway (510(k), De Novo, PMA)
- Design a Quality Management System that satisfies both FDA and EU MDR if needed
- Plan the development lifecycle per IEC 62304 and ISO 13485
- Assess HIPAA requirements for PHI-handling SaMD
Whether you're building a diagnostic algorithm, clinical decision support tool, or patient monitoring system, contact us to discuss how we can build FDA-compliant medical device software with the fault tolerance that healthcare demands.