Introduction
If you’re developing health-related software, you’ve likely asked yourself: “Is my software a medical device?” This seemingly simple question can determine whether you need FDA clearance, CE marking, or can launch freely as a wellness product.
The answer impacts your:
- Time to market (6 months vs. 2+ years)
- Development costs ($50K vs. $500K+)
- Regulatory obligations
- Market access strategy
- Liability exposure
This comprehensive guide will help you determine if your software qualifies as a Software as a Medical Device (SaMD) and what that means for your business.
What is Software as a Medical Device (SaMD)?
Official Definition
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.”
In simpler terms: If your software diagnoses, treats, prevents, or monitors disease independently (without controlling a hardware device), it’s likely SaMD.
Key Distinction: SaMD vs. Software in a Medical Device (SiMD)
| Feature | SaMD (Software AS a Medical Device) | SiMD (Software IN a Medical Device) |
|---|---|---|
| Function | Performs medical purpose alone | Controls or enables hardware device |
| Example | Diagnostic radiology AI app | Software controlling an MRI scanner |
| Regulation | Regulated as medical device | Part of hardware device regulation |
| Distribution | Can be downloaded/cloud-based | Embedded in physical device |
The Critical Question: Does Your Software Have a Medical Purpose?
What Qualifies as a “Medical Purpose”?
According to FDA and EU MDR, medical purposes include software that:
✅ Diagnoses disease or medical conditions
✅ Treats or mitigates disease
✅ Prevents disease
✅ Monitors patients for disease management
✅ Predicts risk of developing a disease
✅ Screens for medical conditions
What Does NOT Qualify as Medical Purpose?
❌ General wellness (fitness tracking, meditation apps)
❌ Healthy lifestyle maintenance
❌ Information or education (drug reference libraries)
❌ Administrative functions (appointment scheduling)
❌ Communication tools (patient portals)
❌ Electronic health records (data storage only)
Real-World Examples: Medical Device or Not?
✅ MEDICAL DEVICE SOFTWARE (Requires Regulation)
1. AI Radiology Assistant
- Function: Analyzes X-rays to detect pneumonia
- Why regulated: Diagnoses disease
- Classification: Class II (FDA 510(k) required)
2. Diabetes Management App
- Function: Calculates insulin dose based on blood glucose
- Why regulated: Treats disease (dose calculation)
- Classification: Class II-III depending on risk
3. ECG Analysis Software
- Function: Detects atrial fibrillation from wearable data
- Why regulated: Diagnoses cardiac condition
- Classification: Class II
4. Clinical Decision Support
- Function: Recommends cancer treatment protocols
- Why regulated: Directly influences treatment decisions
- Classification: Class II
5. Remote Patient Monitoring
- Function: Alerts clinicians to deteriorating vital signs
- Why regulated: Monitors disease progression
- Classification: Class II
❌ NOT MEDICAL DEVICE SOFTWARE (Wellness/Unregulated)
1. Fitness Tracker App
- Function: Counts steps and tracks calories
- Why not regulated: General wellness, no disease claim
- Status: Wellness product
2. Medication Reminder App
- Function: Sends notifications to take prescribed medication
- Why not regulated: Administrative function, doesn’t analyze or recommend
- Status: Not a medical device
3. Drug Reference Guide
- Function: Provides drug information for healthcare professionals
- Why not regulated: Information only, no patient-specific analysis
- Status: Reference material
4. Meditation App
- Function: Guides breathing exercises for stress reduction
- Why not regulated: General wellness, mental health maintenance
- Status: Wellness product
5. Patient Portal
- Function: Allows patients to view lab results and message doctors
- Why not regulated: Data display and communication only
- Status: Healthcare IT system
The Gray Zone: Clinical Decision Support Software
Clinical Decision Support (CDS) is the trickiest category. The FDA distinguishes between regulated and non-regulated CDS based on:
Non-Device CDS (NOT Regulated)
Software that:
- Provides information for healthcare professionals to independently review
- Shows underlying data and information sources
- Does not interpret patient-specific data
- Allows clinician to make final decision without software influence
Example: Drug interaction checker showing known interactions from databases
Medical Device CDS (REGULATED)
Software that:
- Analyzes patient-specific data
- Provides specific recommendations for diagnosis or treatment
- Intended for patient use (self-diagnosis)
- Uses algorithms to interpret complex data
Example: AI analyzing ECG and recommending immediate cardiology referral
FDA vs. EU: Regulatory Differences
United States (FDA)
Key Framework:
- Based on intended use and risk
- 21st Century Cures Act (2016) excludes certain low-risk software
- Digital Health Software Precertification Program (for established companies)
FDA Exclusions (NOT regulated):
- Administrative support functions
- Clinical decision support meeting specific criteria
- Wellness software with no disease claims
- EHR software (data storage/transfer)
Enforcement Discretion: The FDA exercises enforcement discretion (won’t require submission) for:
- Low-risk wellness apps
- Some clinical decision support tools
- Apps that duplicate existing medical devices (like electronic thermometers)
European Union (EU MDR)
Key Framework:
- EU Medical Device Regulation (MDR) 2017/745
- Rule 11: Specific classification rule for software
- Generally broader scope than FDA
EU MDR Rule 11:
- Software for diagnosis/therapy decisions → Class IIa or higher
- Software with serious impact on patient health → Class IIb or III
- Software for monitoring physiological processes → Class IIa
Key Difference from FDA: EU tends to classify more software as medical devices, with fewer exemptions.
The IMDRF Risk Framework for SaMD
The IMDRF created a risk-based classification framework based on two factors:
1. State of Healthcare Situation
- Critical: Life-threatening or serious deterioration
- Serious: Long-term irreversible impairment
- Non-serious: No long-term or reversible impairment
2. Significance of Information Provided
- Treat or Diagnose: Software drives clinical management
- Inform: Software informs clinical management (human decides)
- Aggregate: Provides information on groups, not individuals
Risk Classification Matrix
| Healthcare Situation | Treat/Diagnose | Inform | Aggregate |
|---|---|---|---|
| Critical | Class IV (highest) | Class III | Class II |
| Serious | Class III | Class II | Class I |
| Non-serious | Class II | Class I | Class I |
Example Applications:
- Class IV: AI that recommends cancer treatment doses (critical + treat)
- Class III: Software diagnosing stroke from imaging (critical + diagnose)
- Class II: App detecting skin cancer from photos (serious + diagnose)
- Class I: Population health analytics dashboard (aggregate data)
Mobile Medical Apps: Special Considerations
When is a Mobile App a Medical Device?
FDA Policy (2015 Guidance):
Mobile apps are medical devices if they:
- Use phone’s built-in sensors (camera, microphone) to make diagnoses
- Control medical devices remotely
- Perform patient-specific analysis for diagnosis/treatment
- Display images from medical imaging systems for diagnosis
Common Mobile App Scenarios
📱 Fitness & Wellness Apps
- Status: Generally NOT medical devices
- If you claim: “Tracks your daily steps and calories”
- Regulatory: None (wellness)
📱 Apps With Sensors
- Status: DEPENDS on claims
- If you claim: “Uses camera to detect melanoma”
- Regulatory: Medical device (diagnostic claim)
📱 Remote Monitoring Apps
- Status: Usually medical devices
- If you claim: “Monitors heart rhythm and alerts to arrhythmias”
- Regulatory: Medical device (monitors disease)
📱 Symptom Checkers
- Status: GRAY ZONE
- If you claim: “Provides general health information”
- Regulatory: Probably NOT a device
- If you claim: “Diagnoses your condition”
- Regulatory: Medical device
AI and Machine Learning: Special Rules
Why AI Software Needs Extra Scrutiny
AI/ML algorithms present unique challenges:
- Can change over time (adaptive algorithms)
- May be trained on biased datasets
- “Black box” decision-making
- Performance degrades with new data
FDA’s AI/ML Action Plan
Predetermined Change Control Plans:
- Define types of modifications allowed
- Establish risk-based thresholds
- Describe update methodology
- Enable continuous learning post-market
Example: An AI radiology tool can improve its algorithm monthly based on new data, without submitting new 510(k)s, if changes stay within pre-specified boundaries.
EU Approach to AI
EU AI Act (2024) + MDR:
- High-risk AI (medical diagnosis) = strict requirements
- Transparency and explainability mandated
- Human oversight required
- Post-market monitoring obligations
6 Questions to Determine if Your Software is a Medical Device
Question 1: What is Your Intended Use?
Ask yourself:
- What medical purpose does the software serve?
- What are you claiming in marketing materials?
- How will users understand the software’s purpose?
Red Flag: Any mention of “diagnose,” “treat,” “detect,” “monitor disease”
Question 2: Who is Your Target User?
Healthcare Professionals:
- Lower likelihood of regulation IF they independently review the information
- Higher likelihood IF software provides specific diagnostic/treatment recommendations
Patients/Consumers:
- Higher likelihood of regulation
- FDA concerned about patients making incorrect medical decisions
Question 3: Does Your Software Analyze Patient Data?
Just displays data: Likely NOT a medical device
Analyzes and interprets: Likely IS a medical device
Example:
- Displaying glucose readings → NOT a device
- Analyzing trends and recommending insulin adjustments → DEVICE
Question 4: What’s the Risk if the Software Fails?
High risk (death/serious harm): Definitely regulated
Moderate risk (reversible harm): Probably regulated
Low risk (no/minimal harm): May not be regulated
Question 5: Are You Making Medical Claims?
Review your:
- Website copy
- App store descriptions
- Marketing materials
- Sales presentations
- Investor pitches
Even if you designed it as wellness, making medical claims = medical device regulation
Question 6: Does a Predicate Device Exist?
If similar software has FDA clearance or CE mark:
- Your software likely needs the same
- Search FDA’s 510(k) database
- Check EU EUDAMED database
What to Do If Your Software IS a Medical Device
Step 1: Confirm Classification
US Market:
- Review FDA guidance documents
- Search for predicate devices (510(k) database)
- Consider Pre-Submission (Q-Sub) meeting with FDA
- Determine pathway: 510(k), De Novo, or PMA
EU Market:
- Apply EU MDR classification rules (particularly Rule 11)
- Determine class: I, IIa, IIb, or III
- Identify required conformity assessment route
- Select Notified Body (for Class IIa and above)
Step 2: Develop Required Documentation
Quality Management System:
- ISO 13485 certification
- Design controls (21 CFR 820 or ISO 13485)
- Risk management (ISO 14971)
- Software development lifecycle (IEC 62304)
Technical Documentation:
- Software description and architecture
- Verification and validation protocols
- Cybersecurity documentation
- Usability/human factors engineering
- Clinical evaluation (EU) or clinical data (US)
Step 3: Clinical Evidence Requirements
FDA:
- May require clinical studies for novel devices
- Literature reviews may suffice for predicates
- Real-world evidence increasingly accepted
EU MDR:
- Clinical Evaluation Report (CER) mandatory
- Literature review + clinical data
- Post-market clinical follow-up (PMCF) plan
Step 4: Submit Application
FDA:
- 510(k): ~$12K fee, 3-6 month review
- De Novo: ~$100K fee, 6-12 month review
- PMA: ~$350K fee, 12-18 month review
EU:
- Notified Body assessment (Class IIa+)
- Technical documentation review
- Quality system audit
- Timeline: 6-18 months
What If You Want to AVOID Medical Device Regulation?
Strategy 1: Redefine Your Intended Use
Change claims from:
- “Detects atrial fibrillation” → “Tracks heart rate patterns”
- “Diagnoses depression” → “Mood tracking for wellness”
- “Recommends treatment” → “Educational information about conditions”
⚠️ Warning: Your actual use must match your claims. If users rely on it medically, regulators may still consider it a device.
Strategy 2: Position as Healthcare Professional Tool
Shift from patient-facing to HCP-facing:
- Provide information, not recommendations
- Show data sources and reasoning
- Allow independent clinical judgment
- Clear that it’s a decision support TOOL, not decision maker
Strategy 3: Focus on Wellness
Stay in the wellness lane:
- General fitness and health maintenance
- No disease-specific claims
- Focus on healthy populations
- Preventive health (not disease prevention)
Examples that work:
- “Improve your sleep quality”
- “Track your daily activity goals”
- “Learn meditation techniques”
Strategy 4: Hybrid Approach
Offer two versions:
- Consumer version: Wellness features only
- Professional version: Medical device with clearances
Example: Continuous glucose monitor
- Consumer version: “Track your glucose trends” (wellness)
- Medical version: “Manage diabetes” (Class II device)
Common Mistakes to Avoid
❌ Mistake #1: “We’ll Launch as Wellness and Add Medical Features Later”
Problem: Once you make medical claims, you’re retroactively a medical device. FDA can force recall.
Solution: Plan regulatory strategy from day one.
❌ Mistake #2: “Nobody Will Notice Our Medical Claims”
Problem: Competitors report you. App store reviews mention medical use. FDA monitors.
Solution: Be consistent in ALL communications about intended use.
❌ Mistake #3: “We’re Just Software, Not a Real Medical Device”
Problem: Regulators don’t distinguish. SaMD has same requirements as hardware devices.
Solution: Budget and plan for full medical device regulatory process.
❌ Mistake #4: “We’ll Get FDA Clearance Later”
Problem: Costly redesign if you didn’t follow design controls from start.
Solution: Implement IEC 62304 and design controls from first prototype.
❌ Mistake #5: “Our AI Isn’t a Medical Device, It Just Helps Doctors”
Problem: Clinical decision support WITH patient-specific analysis IS regulated.
Solution: Carefully review FDA’s CDS guidance and IMDRF framework.
How Much Does Medical Device Regulation Cost?
Development Phase
Quality System Setup: $50K-150K
- ISO 13485 certification
- Design control procedures
- Software development lifecycle
Technical Documentation: $100K-300K
- Verification/validation testing
- Cybersecurity assessments
- Usability studies
- Clinical evaluation/evidence
Total Development: $150K-450K before submission
Submission & Review
FDA:
- 510(k): $10K-50K (mostly consulting, $12K FDA fee)
- De Novo: $100K-250K ($100K FDA fee)
- PMA: $300K-1M+ ($350K FDA fee)
EU:
- Notified Body fees: €15K-100K depending on class
- Technical documentation review
- Annual surveillance fees
Post-Market
Ongoing Compliance: $50K-200K/year
- Quality system maintenance
- Post-market surveillance
- Annual reports/updates
- Cybersecurity monitoring
Timeline: How Long Does It Take?
Pre-Submission Development
With medical device in mind from start: 12-18 months Retrofitting existing software: 18-24 months
Includes:
- Requirements definition
- Design & development
- Verification & validation
- Documentation
Regulatory Review
FDA:
- 510(k): 3-6 months (90-day goal, often longer)
- De Novo: 6-12 months
- PMA: 12-24 months
EU:
- Class IIa: 6-9 months
- Class IIb/III: 9-18 months
Total Time to Market
Fast track: 18 months (simple 510(k))
Typical: 24-36 months (De Novo or EU Class IIb)
Complex: 36-48 months (PMA or AI/ML)
Industry Examples: Real SaMD Case Studies
Case Study 1: IDx-DR (First Autonomous AI Diagnostic)
What it does: Analyzes retinal images to detect diabetic retinopathy
Classification: Class II (De Novo pathway)
Key point: Fully autonomous (no physician review needed)
Approval: FDA 2018
Timeline: 7 years from concept to clearance
Case Study 2: AliveCor KardiaMobile
What it does: Mobile ECG monitoring via smartphone
Classification: Class II (510(k))
Key point: FDA-cleared mobile app detecting AFib
Approval: Multiple 510(k) clearances
Timeline: ~18 months per new indication
Case Study 3: Babylon Health GP at Hand
What it does: AI-powered symptom checker and triage
Classification: Class I (EU) / Not FDA cleared
Key point: Different regulatory strategies UK vs. US
Status: Controversy over medical claims without device classification
Case Study 4: Viz.ai Stroke Detection
What it does: AI analyzes CT scans, alerts stroke team
Classification: Class II (510(k))
Key point: SaMD that coordinates care delivery
Approval: FDA 2018, expanded indications 2020-2023
The Future: Regulatory Trends for SaMD
1. Real-World Evidence Acceptance
FDA increasingly accepting post-market data as clinical evidence for software modifications.
2. Predetermined Change Control Plans
FDA’s approach to adaptive AI: pre-approve types of algorithm changes, reducing need for new submissions.
3. Software as a Medical Device Precertification (Pre-Cert)
FDA pilot program: Established companies with strong quality systems get streamlined review.
4. International Harmonization
IMDRF working to align US, EU, Canada, Australia, Japan approaches to SaMD classification.
5. EU Medical Device Regulation (MDR) Enforcement
Stricter enforcement post-2021 transition. More software being classified as devices.
Decision Tree: Is Your Software a Medical Device?
START HERE:
Q1: Does your software have a medical purpose?
(Diagnose, treat, prevent, monitor, predict disease)
→ NO → Not a medical device (Wellness/general purpose)
→ YES → Continue to Q2
Q2: Is it Software AS a Medical Device (standalone) or Software IN a Medical Device?
→ IN a device (controls hardware) → Part of hardware device regulation
→ STANDALONE → Continue to Q3
Q3: Does it meet FDA exclusion criteria?
- Administrative function only?
- Displays data without analysis?
- General wellness with no disease claims?
- Healthcare IT (EHR, patient portal)?
→ YES to any → Likely NOT regulated (Confirm with legal review)
→ NO to all → Continue to Q4
Q4: Is it Clinical Decision Support Software?
→ YES → Does it:
- Provide info for HCP independent review? → Possibly NOT regulated
- Analyze patient data and recommend specific actions? → Probably REGULATED
→ NO → Continue to Q5
Q5: What’s the risk level?
→ High risk (death/serious harm if fails) → Class III/IIb – Regulated
→ Moderate risk (temporary/reversible harm) → Class II/IIa – Regulated
→ Low risk (minimal/no harm) → Class I – May be regulated
Conclusion: Getting It Right From the Start
Determining whether your software is a medical device is critical for your business strategy. Getting it wrong can result in:
- Delayed launches (18+ months to fix regulatory gaps)
- Wasted development (rebuilding without design controls)
- FDA warning letters or forced recalls
- Inability to market in US or EU
- Liability exposure if users are harmed
The Smart Approach:
- Assess early: Don’t wait until after development
- Seek expert guidance: Regulatory consultants save time and money
- Plan conservatively: If borderline, plan for regulation
- Document everything: Design controls from day one
- Monitor your claims: Ensure marketing matches regulatory strategy
Need Expert Guidance?
Still uncertain whether your software qualifies as a medical device? The regulatory landscape is complex and constantly evolving.
AptSkill MedTech offers:
- SaMD classification assessments
- Regulatory strategy consulting
- FDA and EU MDR guidance
- Complete regulatory training programs
Schedule a 1:1 Consultation
Get personalized advice for your specific software product.
📧 Email: contact@aptskillmedtech.com
🌐 Website: AptSkillMedTech.com
Our regulatory experts will help you:
✅ Determine if your software is a medical device
✅ Identify the correct regulatory pathway
✅ Develop a cost-effective compliance strategy
✅ Avoid common pitfalls and delays
Don’t gamble with your product’s future. Get clarity from experts.
Additional Resources
Official Regulatory Guidance
FDA:
- Policy for Device Software Functions (2019)
- Clinical Decision Support Software Guidance (2022)
- Mobile Medical Applications Guidance (2015)
- Artificial Intelligence/Machine Learning Software Action Plan (2021)
EU:
- MDR 2017/745 (Medical Device Regulation)
- MDCG 2019-11: Software Qualification and Classification
- MDCG 2020-1: Clinical Evaluation for SaMD
IMDRF:
- SaMD: Key Definitions (2013)
- SaMD: Risk Categorization (2014)
- SaMD: Clinical Evaluation (2017)
Professional Organizations
- RAPS (Regulatory Affairs Professionals Society)
- MHRA (UK Medicines and Healthcare products Regulatory Agency)
- Health Canada Medical Devices Directorate
- TGA (Australian Therapeutic Goods Administration)
Frequently Asked Questions
Is a fitness tracker app a medical device?
No, if it only tracks general fitness metrics (steps, calories, activity). Yes, if it detects or monitors disease conditions (e.g., irregular heartbeat detection).
Do I need FDA clearance for a symptom checker?
It depends. If it only provides general health information without patient-specific diagnosis, probably not. If it analyzes symptoms and provides specific diagnoses, yes.
Can I launch as wellness and add medical features later?
Not recommended. Once you make medical claims, you’re retroactively a medical device. FDA can issue warning letters or require recalls.
How long does FDA clearance take?
510(k): 3-6 months (if no major deficiencies)
De Novo: 6-12 months
PMA: 12-24 months
Plus 12-24 months development time beforehand.
What if I only sell outside the US?
You still need compliance for each market:
- EU: CE marking under MDR
- Canada: Medical Device License
- Australia: TGA registration
- UK: MHRA registration (post-Brexit)
Does HIPAA compliance mean I’m compliant as a medical device?
No. HIPAA covers data privacy. Medical device regulation covers safety and effectiveness. They’re separate requirements.
Can I use FDA enforcement discretion as my strategy?
Risky. Enforcement discretion is FDA’s choice not to require submissions for low-risk devices. It’s not formal approval, and FDA can change its mind. Not accepted in EU.
What happens if FDA finds out I’m marketing an uncleared device?
- Warning letter requiring you to stop sales
- Mandatory recall
- Fines up to $15,000+ per violation
- Criminal charges for willful violations
- Inability to ever get approval for that device
About AptSkill MedTech
AptSkill MedTech provides practical regulatory training and consulting for medical device and digital health companies. Our team of certified regulatory professionals helps software companies navigate FDA, EU MDR, and global medical device regulations.
Contact us for:
- SaMD classification assessments
- Regulatory pathway guidance
- Quality system implementation
- Clinical evaluation support
- Submission preparation
📧 contact@aptskillmedtech.com
🌐 AptSkillMedTech.com
Advancing MedTech, One Course at a Time