Software as a Medical Device (SaMD): What Health-Tech Builders Need to Know

TL;DR: A product becomes software as a medical device based on its intended use, not simply because it handles healthcare data. Getting SaMD FDA classification wrong early can trigger costly rework across architecture, documentation, validation, and testing.

Most health tech teams treat classification as paperwork to handle after the product works. That order is backwards. SaMD FDA classification is a product and architecture decision that shapes validation depth, risk controls, documentation, testing, and ultimately the regulatory pathway. When teams delay it, a late FDA finding can force them to redesign features, repeat testing, or expand evidence requirements after significant development spend.

This guide explains software as a medical device classification, FDA’s device software function approach, and how AI and CDS products fit. It also helps leaders decide when to use internal expertise or external regulatory support.

What FDA Classification Actually Determines

FDA classification of custom software development for medical devices shapes far more than the regulatory label assigned to your software. It influences:

• Premarket pathway: Whether your product may follow a 510(k), De Novo, or PMA pathway.
• Software development requirements: How risk and safety considerations should be addressed alongside IEC 62304 software lifecycle processes.
• Documentation and post-market obligations: The level of risk documentation, evidence, monitoring, and ongoing regulatory responsibilities your team may need.
• Product roadmap: How early regulatory strategy, risk controls, validation, and compliance requirements need to be incorporated into product development.

Is Your Software Actually an FDA-Regulated Device?

Not every healthcare software development project qualifies as software as a medical device. FDA focuses on intended use and clinical function, not simply the industry or technology involved. A calorie tracker and diagnostic algorithm can therefore fall into very different regulatory categories.

Start With Intended Use and Clinical Function

Your intended use and claims can influence classification more than your technical architecture. Software designed to diagnose, treat, or directly inform clinical decisions may fall under software as a medical device, regardless of how simple the underlying code is.

A symptom logger may remain outside device regulation if it only records information. Add symptom scoring or urgency recommendations, and its regulatory position can change.

The Four-Part Non-Device CDS Test

FDA's four-part test for software as a medical device determines whether clinical decision support software can remain outside device oversight. The software must provide medical information to a healthcare professional, support their judgment, and let them independently review the recommendation's basis.

Test Criteria	Meets Non-Device Standard	Becomes Regulated SaMD
Displays medical information only	Yes	No
Targets healthcare professional user	Yes	No
Professional can review basis independently	Yes	No
Software drives the decision directly	No	Yes

Where AI Triage and Risk Scoring Cross the Line

AI triage, sepsis risk scoring, and automated treatment recommendations can create greater regulatory exposure when clinicians cannot independently review the basis for an output. Teams building AI clinical tools should assess software as a medical device status early rather than treating regulation as a post-development decision.

How FDA Classifies SaMD Risk

FDA sorts software as a medical device into three risk classes using the same framework it applies to physical devices. The severity of harm from a malfunction, combined with how critical the software's output is to a clinical decision, sets your class and your entire submission path.

Class I, Class II, and Class III at a Glance

Class I products still need a quality management system and proper labeling even without a formal submission. 

Founders frequently assume low complexity code means low classification, but a simple algorithm tied to a high-stakes clinical outcome still lands in Class II or III for software as a medical device. 

Complexity of code and severity of harm are not the same measurement, and confusing the two is a common SaMD FDA classification mistake.

510(k), De Novo, or PMA: Which Pathway Fits

A 510(k) works when your product resembles an existing cleared device with the same intended use, called a predicate. De Novo applies to novel low- to moderate-risk products with no predicate to compare against. 

PMA covers Class III products, including certain software such as medical device products,  where FDA requires clinical evidence proving safety and effectiveness before market entry. Choosing the wrong pathway wastes months, since a De Novo product mistakenly filed as a 510(k) gets rejected outright for lacking a valid predicate.

How IMDRF Risk Categorization Supports the Assessment

The International Medical Device Regulators Forum framework asks two questions that sit underneath FDA's own clinical software risk classification work: how significant is the information your software provides for a clinical decision, and how serious is the healthcare situation it addresses. 

Software as a medical device informing a treatment decision in a critical condition sits at the top of that scale. Software informing routine wellness choices sits at the bottom. This layered logic explains why two apps with similar features can land in different classes once you factor in the condition being addressed.

What the Device Software Function Shift Means for Product Teams

SaMD FDA classification has started using the term FDA device software functions alongside software as a medical device, and the shift is not cosmetic. It reflects how FDA now evaluates software that sits inside broader digital health products rather than treating every function as a standalone device.

SaMD vs Device Software Function: What Changed

A device software function is any software function that meets FDA's device definition under the FD&C Act, whether it operates as a standalone application or as part of a larger platform.

Software as a medical device still describes fully standalone products. The distinction matters because modern digital health platforms often combine regulated and non-regulated functions, and FDA can assess these functions separately rather than applying one classification to the entire application.

Separating Regulated and Non-Regulated Software Functions

A single platform can include a medication reminder, appointment scheduler, and dosage calculator, yet only the dosage calculator may trigger medical device software regulation.

Product teams should map each function against FDA's device definition individually rather than classify the entire platform under one label.

This function-level thinking is now central to accurate SaMD FDA classification, and skipping it means either over-regulating harmless features or missing a regulated one entirely.

What Mixed Function Products Mean for Architecture

Build regulated and non-regulated functions as separate modules from day one instead of embedding them into tangled logic within a single codebase, following the principles of custom software solutions.

A separable architecture allows you to apply IEC 62304 controls based on actual risk, keep documentation proportional to regulatory requirements, and classify new features without reworking the entire quality system.

For software as a medical device, teams that separate functions early can reduce unnecessary compliance effort while making future product expansion easier to manage.

How Classification Changes Your Development Requirements

Your FDA class does not directly dictate your engineering process, but it sets the ceiling for how much rigor your development lifecycle needs. Understanding that connection early saves teams from either underbuilding safety controls or over-engineering documentation for a low-risk product.

FDA Device Class vs IEC 62304 Software Safety Class

• IEC 62304 assigns software safety classes A, B, or C based on the severity of harm a software failure could cause, independent of but closely related to your FDA device class and software development lifecycle.
• Class A software cannot contribute to a hazardous situation, Class B could contribute to a non serious injury, and Class C could contribute to death or serious injury. 
• A Class II software as a medical device product frequently maps to IEC 62304 Class B or C depending on failure severity, and that mapping decides your documentation depth.

Connecting IEC 62304, ISO 14971, and ISO 13485

• These three standards work as one connected system rather than separate checklists. ISO 14971 drives your risk management file, identifying hazards and mitigations. 
• IEC 62304 translates those risk controls into software development lifecycle requirements, dictating what gets designed, coded, and tested at each safety class. 
• ISO 13485 wraps both inside a quality management system covering document control, change management, and organizational accountability for software as a medical device. 
• Treating these as three disconnected compliance exercises instead of one integrated system is where most medical device software regulation timelines fall apart.

Documentation and Verification You Need to Plan Early

• Plan your risk management file, software requirements specification, and verification protocols alongside software testing and QA before writing production code, not after a feature freeze. 
• Every requirement, test case, and design decision needs traceability back to a documented risk control. 
• Retrofitting this traceability onto code already built typically takes longer than building it alongside development from the first sprint, and it is the single largest source of submission delay for software as a medical device team.

What AI/ML Adds to SaMD Compliance

Adding AI development or machine learning to your product does not automatically raise your FDA class, but it adds an entirely separate layer of oversight FDA evaluates independently. Teams building AI features need to plan for this layer alongside standard SaMD compliance work, not instead of it.

AI Does Not Automatically Determine Classification

An AI-powered symptom checker and a rule-based symptom checker with the same intended use can fall under the same FDA class. What changes is the evidence required to support the model's outputs, not the mere use of AI.

What changes is the evidence software as a medical device expects to see behind the model's outputs. Assuming AI automatically pushes a product into Class III is a common and costly misunderstanding among first time builders.

Locked vs Adaptive AI/ML Software

A locked algorithm produces consistent outputs for the same inputs and can be evaluated against a defined version during submission, an important consideration when implementing generative AI in healthcare. An adaptive algorithm can change its behavior after deployment, creating performance drift that requires ongoing oversight.

For adaptive AI/ML products, teams need a clear plan for monitoring, validating, and controlling post-market changes. This makes the documentation and compliance strategy more demanding than for a fixed model.

PCCP and Managing Planned Model Changes

A Predetermined Change Control Plan lets manufacturers define in advance what future model updates will look like and how they get validated, avoiding a new submission for every retrain. 

Building your PCCP early, alongside your original classification work, prevents a costly gap between how your model actually evolves and what your cleared submission describes. 

Products without a PCCP need a fresh review for changes that a properly planned one would have already covered.

What Happens When You Get Classification Wrong

Misclassifying software as a medical device at the architecture stage can trigger costly rework across code, testing, documentation, and risk management. Teams often discover the impact only when regulatory review exposes the gap.

Rework From Architecture to Validation

A product planned as Class I but later requiring Class II controls may need additional risk analysis, software testing, logging, and traceability. Engineers may also need to revisit architecture decisions made months earlier.

How Misclassification Affects Cost and Timeline

Mid-development reclassification can add months as teams rebuild documentation, testing, and controls while development continues. 

A product planned for a simpler pathway may suddenly require 510(k) clearance, disrupting both budget and launch timelines. That is why SaMD FDA classification should happen before architecture and development decisions are locked.

Classification Questions to Resolve Before Development Starts

• Does the software provide information that directly supports diagnosis or treatment decisions?
• Can clinicians independently review and verify the basis for each recommendation?
• Does any feature use adaptive AI that can change its behavior after deployment?
• Which software as a medical device pathway and IEC 62304 software safety class does the current design indicate?

Do You Need a SaMD Development and Regulatory Partner?

Whether you handle classification internally or bring in outside expertise depends on your team's prior regulatory experience, not company size. A well-funded startup with no prior submission history carries the same risk as a small team in this specific area.

When Your Internal Team Can Handle Classification

Teams with prior 510(k) or PMA experience, an existing quality management system, and dedicated regulatory staff can typically manage SaMD FDA classification without outside support. 

The deciding factor is whether someone on the team has personally carried a product through software as a medical device review before, not whether the team understands the regulations conceptually.

When External Expertise Becomes the Better Option

First-time submissions, novel AI-driven clinical functions, and teams operating on a tight funding runway benefit most from bringing in regulatory and development expertise early. 

A partner who has already classified similar products spots misclassification risks during architecture discussions rather than during a rejected submission, which is a meaningfully cheaper place to catch the problem.

Build, Partner, or Hybrid Strategy

Most teams land on a hybrid approach: internal engineering handles the build while an outside regulatory partner owns classification strategy, risk documentation, and submission preparation. 

This keeps product knowledge in-house while covering the specialized medical device software regulation expertise most engineering teams do not have on staff. Full outsourcing works for teams entering a completely new regulatory category with no internal precedent to build from.

How to Vet a SaMD Development Partner

The right partner has demonstrable classification and submission experience, not just general healthcare software and data privacy compliance claims. Ask for specifics before signing anything, because vague healthcare positioning is the biggest red flag in this space.

FDA Submission and Classification Experience

• Ask how many products the team has personally taken through classification and submission, and ask for the outcome, not just the attempt. 
• A partner who can walk through a specific classification decision they made and explain their reasoning demonstrates real experience. 
• General claims about healthcare industry knowledge without a submission track record are not the same thing.

IEC 62304, Risk Management, and QMS Capabilities

• Confirm the partner has hands-on experience applying IEC 62304 safety classes to real projects, not just familiarity with the standard's structure. 
• Ask how they integrate ISO 14971 risk files with development sprints, and whether their quality management system has supported an actual software as a medical device submission before.

AI/ML, Cybersecurity, and Post-Market Support

• If your product includes AI features, confirm the partner understands PCCP planning, adaptive model documentation, and healthcare software security specifically, since this is where general software partners fall short.
• Ask what post-market surveillance support looks like after launch, since medical device software regulation obligations do not end at clearance.

Patoliya Infotech Helps You Classify Before You Build

Patoliya Infotech helps healthcare technology teams address regulatory classification before architecture and development decisions become expensive to change. 

Our team aligns intended use with FDA requirements, integrates IEC 62304 and ISO 14971 practices into the development lifecycle, and supports regulatory-ready software development from the start.

• Early classification assessment before development begins.
• Risk and compliance documentation integrated into the software lifecycle.
• AI/ML regulatory planning, including considerations for adaptive models and PCCP.

Plan your SaMD development with the right regulatory foundation from day one.

Conclusion

Classification influences your regulatory pathway, documentation, development process, and launch timeline long before your first submission. For a software as a medical device team, getting the intended use, risk class, and IEC 62304 requirements right early can prevent costly changes later. 

It also gives your engineering and regulatory teams a clearer foundation for validation, risk management, and submission planning. Before another sprint adds complexity to the product, make sure its regulatory direction is clear.