The lean SaMD regulatory approval starter kit: like an MVP but for documentation

Once you understand your intended use and identify the right predicate device, the next question founders face is immediate and urgent: “What documentation do we actually need for our FDA submission?”

This is often the moment when innovators discover ISO 13485, IEC 62304, ISO 14971, FDA’s cybersecurity expectations, postmarket controls, and the long list of documents that seem to accompany every regulatory requirement. Many respond by assuming they need a massive QMS platform and dozens of processes before they can move forward.

The truth is more encouraging: your first SaMD submission needs a lean, targeted set of documents built around ISO 13485, not a heavyweight quality system. When done correctly, ISO 13485 acts as the backbone of your documentation, and the other standards slot in like modular components that attach only where required.

This article explains how to build your MVP documentation package, centered on ISO 13485 and expanded just enough to satisfy FDA expectations for software and AI, and nothing more.

Why ISO 13485 Should Be the Foundation of Your SaMD Documentation

ISO 13485 is the global quality management standard for medical devices, and it provides the structure regulators expect:

• Design controls

• Risk management integration

• Document control

• Verification and validation

• Supplier management

• Postmarket surveillance

• Corrective and preventive action

When implemented in a lightweight, early-stage way, ISO 13485 gives you:

• A controlled place to store all of your submission evidence

• Traceability across your entire software lifecycle

• A clear narrative that FDA reviewers immediately understand

• A stable framework that can scale with your company

Every other software or AI-related standard attaches to this foundation. If ISO 13485 is the skeleton, the other standards are the organs that make it function.

The Modular Approach: Layering Standards on Top of ISO 13485

FDA does not expect startups to implement every standard in full. Instead, they expect:

• ISO 13485 as the overarching quality system

• ISO 14971 as the risk management engine within it

• IEC 62304 as the software lifecycle structure

• Cybersecurity documentation as needed for your connectivity

• AI/ML documentation when algorithms influence clinical output

• Usability engineering when clinicians interact with the software

These standards work together, not separately.
And they can be implemented incrementally, not all at once.

This modular approach is what makes an MVP documentation set possible.

Your MVP Documentation Package (Built on ISO 13485)

Below is the leanest, regulator-ready document set you need for your first 510(k) or De Novo submission. Every document fits into ISO 13485, and the other standards extend it where appropriate.

1. Intended Use & Indications for Use (ISO 13485 + FDA requirement)

The core statement that defines everything: classification, pathway, testing, and risk.

2. Design and Development Plan (ISO 13485)

A simple, high-level plan that shows you understand your development stages, reviews, and responsibilities.

3. Risk Management File (ISO 14971, integrated into 13485)

The cornerstone of your documentation:

• Hazard identification

• Risk estimation and control

• Residual risk evaluation

• Traceability to requirements and tests

Regulators expect ISO 14971 to be fully embedded into your 13485 design controls.

4. Software Development Documentation (IEC 62304 + 13485 design controls)

IEC 62304 defines your software lifecycle, but it fits neatly inside ISO 13485.
Your MVP includes:

• Software architecture diagram

• Software itemization and classification

• Requirements specification

• Unit, integration, and system testing

• Maintenance and bug-handling procedures

IEC 62304 provides structure, and ISO 13485 provides the control.

5. Verification & Validation Evidence (ISO 13485 + IEC 62304)

FDA cares less about your development style and more about your proof. Your MVP V&V package includes:

• Verification against each software requirement

• Validation in clinically relevant scenarios

• Usability/human factors testing if clinician-facing

• Dataset validation for AI models

A simple traceability matrix connects all of this, satisfying ISO 13485 design control requirements.

6. AI/ML Documentation (Built on 13485 + ISO 42001 principles)

If your software uses AI in a medically meaningful way, you need:

• Model training description

• Dataset representativeness and bias evaluation

• Performance metrics across subgroups

• Drift monitoring plan

• Change control strategy for future retraining

ISO 42001 is not required, but its governance concepts help you create a structured, reviewer-friendly narrative within your QMS.

7. Cybersecurity Documentation (FDA guidance + ISO 27001 principles)

Modern SaMD is rarely offline. Your MVP cybersecurity package includes:

• Threat modeling

• Vulnerability assessment

• Authentication/authorization strategy

• Encryption approach

• Update/patching workflow

• Secure development practices

These documents expand your ISO 13485 processes to cover digital safety.

8. Configuration & Change Management (ISO 13485 + IEC 62304)

FDA needs to see that software updates are controlled and traceable.
A small, well-organized process is enough at MVP stage.

Why You Do Not Need a Heavy QMS Platform for Your First Submission

Many early-stage companies think regulatory compliance requires:

• A high-cost QMS platform

• Automated document management

• A full set of enterprise workflows

• Formal CAPA boards and monthly reviews

This is simply not true.

A lean ISO 13485 system, built with lightweight tools and expert guidance, is fully acceptable to FDA.
You can maintain:

• Document control

• Traceability

• Design reviews

• Risk management integration

• V&V evidence

• Change management

…all without a thousand-dollar-per-month QMS subscription.

Expensive platforms are useful later, when:

• Your engineering team grows

• You need formal collaboration tools

• You manage multiple submissions

• You enter international markets

But for your first submission, the priority is clarity, not software.

You need the right documents, not the fanciest system.

ISO 13485 Is Your Foundation and Everything Else Builds on It to Suit your Intended Use

Your first SaMD submission does not require a complex, enterprise-grade quality system. It requires:

• A lean ISO 13485 foundation

• Layered, modular additions from IEC 62304, ISO 14971, cybersecurity, and AI governance

• Focus on traceability, risk, and software performance

• Clear documentation, not expensive tools

By treating ISO 13485 as the core and adding only what applies to your product, you keep your documentation tight, efficient, and submission-ready.

If you want help building a lean, modular QMS aligned with ISO 13485, or assembling the complete MVP documentation package for your SaMD, Unigen can guide you through each step and help you avoid unnecessary cost and complexity. Contact us to get started.

Choosing the Right Predicate Device: The Most Important Step in Your 510(k) Strategy

Once you decide your product is a good candidate for the 510(k) pathway, the next critical decision is which predicate device you will compare yourself to. For many SaMD and AI teams, this choice feels abstract at first. In reality, it is one of the most strategic calls you will make.

Your predicate device anchors your claim of substantial equivalence. It influences your risk classification, what testing you need, how much data you must generate, and how comfortable FDA feels with your overall approach. A smart predicate choice can keep you on a relatively fast track. A poor one can push you toward a Not Substantially Equivalent (NSE) decision and into De Novo or PMA territory.

This guide walks through the key questions you should ask when selecting a predicate for a SaMD or AI-enabled device.

1. What is a predicate device and what does “substantial equivalence” really mean?

In a 510(k), you are not trying to prove your device is perfect in a vacuum. You are trying to show that it is as safe and effective as an appropriate device already on the US market, known as the predicate.

FDA considers a device substantially equivalent if:

• It has the same intended use as the predicate, and

• Either the technological characteristics are the same, or any differences do not raise new questions of safety or effectiveness, and

• The information you submit shows your device is as safe and effective as the predicate.

For SaMD and AI products, “technological characteristics” include your algorithms, software architecture, data inputs, user interface, connectivity, and any embedded AI models. Small differences are allowed. Large shifts require careful justification and strong performance data.

2. Is the predicate truly and clearly “legally marketed”?

Your first filter is simple: the predicate has to be legally marketed in the US.

FDA allows several types of devices to serve as predicates, including:

• Devices cleared through 510(k)

• Preamendment devices that were on the market before May 28, 1976

• Certain devices originally approved as Class III that were later down-classified

• Some 510(k)-exempt devices, if used correctly for comparison

Using a device that is not legally marketed as your predicate will almost certainly lead to an NSE decision. That can force you into a De Novo request or PMA pathway, with more time, cost, and complexity.

For software products, it is also worth checking:

• Whether the predicate is still actively marketed and supported

• Whether it has major safety issues, recalls, or cybersecurity incidents in its history

FDA has draft guidance on best practices for predicate selection that explicitly encourages choosing predicates that do not carry known safety problems or outdated technology.

3. Does the predicate’s intended use align with your real product vision?

Predicate selection is not just a technical exercise. It is a claims strategy.

FDA requires that your device have the same intended use as the predicate. If your intended use diverges, it becomes difficult or impossible to show substantial equivalence.

Questions to ask:

• Does the predicate target the same condition or clinical scenario?

• Is the user population similar? (for example, adults vs pediatrics)

• Does it occupy the same position in the workflow? (screening, triage, diagnosis, treatment guidance)

• Are the claims about performance and clinical impact similar to what you are aiming for?

If your software uses AI, be careful not to write an intended use that sounds more autonomous or high-risk than the predicate you want to use. A claim like “assists clinicians in evaluating X” is very different from “automatically diagnoses X.” Those differences can shift you into a different risk category and away from your desired predicate.

In practice, many startups adjust their Version 1 claims to better match a solid predicate, then plan enhancements and broader claims for later updates.

4. How similar are the technological characteristics, especially for SaMD and AI?

Even when intended use matches, FDA will examine whether your device achieves that use with similar technological characteristics.

For SaMD and AI systems, this means comparing:

• Input data types and sources (EHR data, imaging, sensor streams, wearables, etc.)

• Core algorithms and processing steps

• AI model structure and outputs

• User interface and decision support workflow

• Connectivity, cloud components, and interoperability

• Cybersecurity controls and data handling

Differences are allowed, but they matter. FDA will ask whether these changes introduce new questions of safety or effectiveness compared with the predicate.

Examples that can trigger new questions:

• Moving from rule-based logic to deep learning classification for the same task

• Shifting from retrospective analysis to real-time monitoring

• Adding automated treatment recommendations where the predicate only flags results for review

• Introducing fully remote or home use where the predicate is used only in supervised clinical settings

With recent AI guidance, FDA is also looking more closely at training data, generalizability across populations, and how you manage model updates and drift over time.

When technological differences become too large to comfortably bridge, that is a signal that you may be heading toward De Novo instead of 510(k).

5. What performance data will you need to bridge the gaps?

Once you know how your device differs from the predicate, the next question is what evidence is needed to show that those differences do not make the device less safe or effective.

FDA will look at:

• Whether your test methods are appropriate and robust

• Whether you have adequately challenged the device under realistic and worst-case conditions

• Whether results demonstrate performance that is at least as good as the predicate

For SaMD and AI, this often includes:

• Software verification and validation

• Bench testing using representative datasets

• Human factors and usability testing

• Cybersecurity testing and threat modeling

• For AI models, validation across different demographic and clinical subgroups

If your data show clear, comparable performance and no new safety concerns, FDA can still find substantial equivalence even when the tech stack is not identical. If the data expose unresolved safety or effectiveness issues, an NSE outcome becomes more likely, and you may be pushed toward De Novo or PMA.

This is where predicate choice becomes critical. A predicate that is closer to your technology often requires less complex testing to bridge the gap.

6. Is this predicate strategically aligned with your long-term roadmap?

Finally, even if a predicate is legally marketed, has aligned intended use, and similar technology, you should ask whether it is strategically the right choice for your product and company.

Consider:

• Is the predicate in a device family you want to be associated with long term?

• Does it represent a level of performance you can match or exceed comfortably?

• Does it support your plans to expand indications or move into other regions later?

• Is it recent enough that FDA is comfortable using it as a touchstone for current practice?

For AI and SaMD, there is an extra dimension: you want a predicate that is conceptually similar to how regulators already think about your type of algorithm. Picking something too far removed can make your story harder to tell.

Putting it all together

Predicate selection is not a checkbox exercise. It is one of the most strategic regulatory choices you will make:

• It locks in your intended use and risk envelope

• It shapes your testing plan and evidence burden

• It influences how FDA views your AI or software architecture

• It can be the difference between a focused 510(k) review and an unexpected detour into De Novo

For first-time founders, this is not something you should improvise in a weekend. The most efficient teams treat predicate selection as a structured decision, grounded in FDA guidance and aligned with their product roadmap.

If you are planning a 510(k) for a SaMD or AI-enabled device and want help identifying and evaluating predicates, aligning your claims, and mapping out the testing needed to support substantial equivalence, Unigen can work with you to design a predicate strategy that supports both fast clearance and long-term growth. Contact us to schedule an introductory call.

How Intended Use Shapes Your SaMD Classification and FDA Pathway

As software takes over more clinical functions that were once performed by hardware, the definition of Software as a Medical Device, or SaMD, has expanded across nearly every area of healthcare. Modern SaMD tools can screen for chronic diseases, triage patients, analyze imaging data, track physiologic signals, and increasingly incorporate artificial intelligence to guide clinical decision making. This shift has opened the door to faster innovation, but it has also created challenges for manufacturers who must demonstrate that these digital tools are safe, reliable, and appropriate for their intended role in patient care.

For first-time founders in MedTech, few decisions have more influence on your regulatory pathway than how you define the intended use of your software and how you classify its risk. These two concepts determine your FDA pathway, the evidence you need, the depth of your documentation, and the expectations regulators will apply during their review. Getting this right early can save months of time, avoid expensive redesigns, and prevent an accidental leap into a higher risk category.

What Counts as SaMD? A Quick refresher

Most regulatory agencies follow the IMDRF definition of SaMD: software that performs a medical function on its own, without being part of a hardware medical device.

Common examples include software that:

• Analyzes medical images to detect abnormalities

• Classifies physiologic signals to support diagnosis

• Calculates risk scores for clinical conditions

• Recommends treatment options or guides therapy

• Processes biometric data from wearables in a clinically meaningful way

On the other hand, software that supports administrative tasks, billing, scheduling, or workflow tracking is not considered SaMD. General wellness apps that provide lifestyle guidance without a medical purpose also fall outside the definition.

AI-enabled tools can fall into either category depending on what they claim to do. A predictive algorithm that identifies sleep stages is often not SaMD. A predictive algorithm that flags potential respiratory distress very likely is.

Why Intended Use Is the First Step in SaMD Classification

Your intended use statement is a brief description of what your SaMD does, who it is for, and the clinical purpose it serves. Although it is usually only one or two sentences, it determines:

• Whether your product is a medical device at all

• FDA risk classification

• Your regulatory pathway (510(k), De Novo, or PMA)

• Clinical evidence requirements

• Verification and validation expectations

• Applicability of standards like IEC 62304, ISO 14971, and ISO 42001

• Whether your AI model poses higher regulatory concern

For AI-driven systems, intended use statements also shape how FDA evaluates model behavior, training data, bias, drift management, and whether the algorithm is considered locked or adaptive.

A poorly defined intended use can inadvertently elevate your device into a higher risk category or require unnecessary clinical data. A narrow, well-controlled intended use keeps you on the fastest and most appropriate path.

Using a Structured Framework to Categorize SaMD Risk

Regulators evaluate SaMD not only by what it does, but also by the clinical situations in which it is used. To help manufacturers classify risk consistently, the IMDRF created a four-tier framework that considers:

1. The significance of the information the software provides

   • Does the software inform, drive, or directly diagnose and treat?

2. The clinical condition or scenario in which the information is used

   • Is it non-serious, serious, or critical?

Using these criteria, SaMD falls into one of the following categories:

• Category IV (very high impact): Software that diagnoses or treats conditions in critical scenarios, where incorrect output could result in immediate and severe harm.

• Category III (high impact): Software that drives clinical decisions for serious conditions, where harm from incorrect recommendations is still significant.

• Category II (medium impact): Software that informs clinical management in non-serious contexts.

• Category I (low impact): Software that provides supplemental information for non-serious situations, where risks are minimal.

AI systems often move into higher categories more quickly because of their increased influence on clinical decision making and the difficulty of fully characterizing model behavior.

Correctly applying this framework early helps you understand your regulatory obligations and assemble the right evidence before you ever speak to a regulator.

Special Considerations for AI-Enabled SaMD

AI brings new capabilities to software, but it also introduces new risk factors. When AI influences your intended use statement or your risk categorization, regulators evaluate additional aspects such as:

• Training and test data quality

• Representativeness and potential bias

• Explainability and transparency

• Performance in edge cases

• Model drift and retraining strategy

• Human oversight and fallback mechanisms

For example, a model that “assists clinicians in identifying abnormal cardiac rhythms” is very different from a model that “automatically detects and labels arrhythmias.” The former may be eligible for Category II or III, while the latter might fall into Category III or IV, requiring more rigorous testing and regulatory scrutiny.

In short, AI amplifies both capability and regulatory responsibility.

Why Intended Use and Risk Category Determine Everything That Comes Next

Once intended use and risk category are established, your regulatory pathway becomes much clearer:

• Low-risk SaMD (Category I or II) is more likely to fit into a 510(k) pathway if a predicate exists.

• Novel moderate-risk SaMD may require a De Novo classification before it can enter the 510(k) ecosystem.

• High-risk SaMD with direct diagnostic or treatment functions often requires PMA.

From there, your classification drives requirements for:

• Software lifecycle documentation (IEC 62304)

• Risk management (ISO 14971)

• Cybersecurity controls and threat modeling

• Human factors testing (IEC 62366)

• AI governance and transparency (ISO 42001)

• Verification and validation activities

• Clinical evidence, if applicable

This is why founders should define intended use early and treat it as part of product strategy, not an afterthought.

In conclusion

For any SaMD or AI-enabled product, defining intended use and understanding risk categorization are foundational steps that shape your entire regulatory plan. These decisions influence your FDA pathway, required evidence, documentation expectations, and the depth of your quality processes. By applying a structured risk framework and being deliberate about how you describe your software’s role in clinical decision making, you can avoid unnecessary regulatory burdens and move toward market faster.

If you need help shaping your intended use statement, categorizing risk, or planning your SaMD documentation, Unigen can guide you through each step so you avoid delays and build a product that is safe, compliant, and ready for submission. Contact us for a consultation.

Medical Device Regulation 101: How to Prepare for (and Survive) FDA Approval

For many innovators building their first medical device or software product, the regulatory system can feel confusing, slow, and intimidating. Most founders begin with the same basic questions: What pathway should my product follow? How long will it take? What documents do we actually need? And how early should we start preparing?

This guide gives you a clear overview of how FDA evaluates medical devices, how risk classification works, which pathways exist, and what practical steps you should take during early development. Whether you are building a hardware device, a cloud-connected tool, or Software as a Medical Device (SaMD), the principles below form the foundation of a successful regulatory strategy.

1. Understanding Intended Use and Risk Classification

Your device’s regulatory journey starts with a single sentence: your intended use statement. This brief description of what your product does and who it is for influences everything that follows, from risk classification to required evidence.

FDA evaluates risk by considering the severity of harm that could result if the device fails or is used incorrectly. ISO 14971, the global standard for medical device risk management, provides the framework most teams follow to classify hazards, estimate their severity, and determine controls. The output of this analysis feeds directly into device classification:

• Class I: Low risk products such as simple manual tools

• Class II: Moderate risk products including most diagnostic and monitoring technologies

• Class III: High risk devices that directly support or sustain life, or make critical clinical decisions

For SaMD, risk is tied to the role the software plays in clinical care. Software that simply informs a clinician tends to fall lower on the spectrum. Software that drives or automates a diagnosis tends to fall higher.

This early classification step shapes the rest of your journey, so it is important to get it right.

2. The Three Main FDA Pathways and Their Timelines

Once risk is understood, your product fits into one of three major FDA pathways. Each pathway has different expectations, timelines, and documentation requirements.

510(k) Premarket Notification (Most Common, Fastest)

A 510(k) is used for moderate risk devices that can demonstrate substantial equivalence to a device already on the market. FDA’s review goal is 90 days, although real timelines extend to 6 to 9 months once questions and updates are included.

De Novo Classification (For Novel, Low to Moderate Risk Products)

If no predicate exists, but the device is still low to moderate risk, the De Novo pathway allows companies to create a new classification. FDA’s review goal is 150 days, with most real-world reviews taking 8 to 12 months.

Premarket Approval (PMA) for High Risk Devices

PMA is the most demanding pathway. It requires robust scientific and clinical evidence, a full quality system review, and often an advisory panel meeting. FDA’s statutory timeline is 180 days, but full PMA cycles often extend beyond a year.

The important takeaway is that the more innovative the product, the longer and more complex the pathway tends to be.

3. Why Innovation Is Often “Punished” in Regulatory Pathways

FDA’s reliance on substantial equivalence means that companies with novel technology frequently face longer timelines.

If your device is truly unique and no predicate device exists, it cannot go through the 510(k) pathway, even if it is low risk. That means:

• You lose access to the fastest clearance route

• You face more rigorous evidence requirements

• Your review includes more back-and-forth with FDA

• Timelines stretch significantly

This is why it is often said that the regulatory system rewards incremental improvements and slows down transformative innovation.

This is not a reason to avoid building novel technology. It simply means you should understand the regulatory consequences and plan accordingly.

4. Why a 510(k) Strategy Is Often Recommended for Innovators

For early-stage MedTech and SaMD companies, the 510(k) pathway has several advantages:

• It is the fastest route to market

• It typically requires less evidence than De Novo or PMA

• It offers more predictable timelines

• It creates fewer barriers for fundraising and commercialization

Because of its efficiency, many startups adjust their product strategy to fit a predicate device. This can involve:

• Narrowing the initial intended use

• Aligning product claims with an existing device

• Launching a “Version 1” that mirrors a cleared predicate, then expanding later

• Prioritizing features that support regulatory similarity

A 510(k) strategy does not reduce innovation. It simply ensures that innovation is sequenced in a way that aligns with regulatory realities.

5. Build Your Quality Management Processes Early

Quality is not something you add at the end of development. FDA expects manufacturers to follow quality system principles throughout the product lifecycle.

ISO 13485 is the global standard most teams use to structure their quality management system (QMS). It defines how you handle:

• Design controls

• Risk management

• Document management

• Verification and validation

• Supplier management

• Complaint handling and postmarket surveillance

For startups, the QMS does not need to be heavy or expensive. It needs to be functional, traceable, and appropriate for your stage of development.

Investors and regulators both expect you to have this foundation in place long before your submission.

6. Additional Standards to Consider for SaMD

Software products must follow additional standards that are specific to digital health and artificial intelligence. The most common include:

• IEC 62304: The software lifecycle standard, covering design, coding, testing, maintenance, and change control

• ISO 14971: Risk management, including software-specific failure analysis

• ISO 27001 and FDA cybersecurity expectations: Security controls, threat modeling, and secure development

• ISO 42001: The new management system standard for AI governance, especially relevant for machine learning products

• IEC 62366: Usability and human factors engineering

These standards help demonstrate that your software is safe, reliable, and well controlled, which is extremely important for regulators reviewing SaMD or AI products.

7. The First Hurdle Before Submission: Your QMS Audit

Before many companies can submit to FDA or enter markets like Canada or Europe, they must undergo a QMS audit to demonstrate compliance with ISO 13485. This audit is performed by a recognized auditing organization such as UL, BSI, TUV SUD, or Intertek.

During this process, auditors verify that:

• Your documentation meets ISO 13485

• Your design controls are traceable

• Your risk files are complete

• Your software development process matches IEC 62304

• Your quality system is being followed, not just written down

While this can sound intimidating, startups who prepare early usually pass without major issues.

8. You Do Not Need Expensive QMS Software to Get Started

Many early-stage companies believe they need enterprise QMS software before they can begin their regulatory journey. This is not true.

For your first submission, you primarily need:

• A clear regulatory strategy

• Well organized documentation

• Basic quality processes

• A partner who can teach you what matters and what does not

Software can help later, especially once you scale or approach multiple markets, but it is not required at the beginning. What you need first is clarity and structure, not complexity.

Final Thoughts

Regulatory approval can feel overwhelming at first, but once you understand how intended use, risk, pathways, and quality systems fit together, the process becomes far more manageable. Early planning gives innovators more control, reduces rework, and shortens time to market.

If your team is building its first medical device or SaMD product, Unigen can help you map your pathway, establish lightweight quality processes, prepare your documentation, and move forward with confidence. Contact us for an introductory chat.