Treat or Prevent
Software that drives or recommends a therapeutic action — closed-loop insulin dosing, automated ventilator adjustment, treatment protocol engines that output specific clinical decisions.
Your Software Makes a Clinical Decision. The FDA Has a Say.
If it analyzes patient data to detect a condition or guide a clinical decision, it's likely a medical device under FDA law. We build standalone clinical software with the regulatory strategy and validation FDA clearance requires.
Talk to Us About Your SaMD BuildTrusted by startups and global leaders
What Qualifies as SaMD — Because the Line Matters
Four intended-use categories push software into SaMD territory. The line is your intended use statement — not how it's labeled. We work through this during discovery.
Diagnose
Software that identifies a disease, condition, or injury — AI image analysis for cancer or retinal disease, arrhythmia detection, seizure detection, sepsis models where the output is a diagnosis.
Monitor
Software that monitors a patient's clinical state for immediate clinical action — continuous vital-sign analysis, real-time deterioration detection, post-surgical complication monitoring.
Predict
Risk stratification software where the output drives specific clinical decisions — treatment selection, intervention timing, or care escalation for individual patients.
SaMD Categories We Build
Six categories — each with its own regulatory pathway and clinical-validation requirements.
The Regulatory Pathway — Choosing the Right One Before Development
Most diagnostic AI and CDS falls Class II — a 510(k) or De Novo pathway. The right choice depends on risk classification and whether a predicate exists.
Risk Classification First
510(k) — Substantial Equivalence
De Novo — Novel Low-to-Moderate Risk
Pre-Submission Meetings
Clinical Validation — The Evidence That Makes or Breaks a SaMD Submission
Clinical validation for SaMD is not software testing. It is a clinical study — designed with the rigor of a medical study, conducted with representative patient populations, and analyzed with statistical methods that provide meaningful evidence of clinical performance. Several principles apply broadly.
Study Design Matches the Intended Use
An algorithm validated only on academic-center data with high-quality imaging may not generalize to the community setting where it will be used. A sepsis model validated on one health system may not perform on a demographically different population. Study design accounts for the real-world deployment context.
Performance on the Metrics That Matter Clinically
Sensitivity and specificity for diagnostic software. Positive and negative predictive value at realistic disease prevalence. Area under the ROC curve where appropriate. Clinical outcomes where feasible — not just overall accuracy, which can be misleadingly high for rare conditions.
Subgroup Performance, Not Just Population-Level
FDA increasingly expects — and clinical users reasonably demand — evidence of equitable performance across demographic and clinical subgroups. An algorithm at 95% sensitivity overall and 78% in elderly patients with comorbidities has a different clinical profile than the headline number suggests.
Real-World Evidence Supplements Controlled Data
Post-market clinical data from real-world deployment is increasingly important to FDA's assessment — particularly for AI/ML products where real-world performance may differ from controlled-study performance. We build the real-world evidence infrastructure alongside the product.
SaMD Products We've Built and Cleared. What the Submissions Showed.
Each card is a standalone clinical software product we designed, validated, and carried through FDA review — with the category and regulatory outcome that followed. Click through to see the product behind each result.
Talk to Us About Your SaMD BuildDe Novo
AI Diabetic Retinopathy Detection — Ophthalmology diagnostic SaMD. FDA De Novo granted. Sensitivity 91%, specificity 96% in validation study.
510(k)
Cardiac Arrhythmia Detection Algorithm — ECG analysis SaMD. 510(k) cleared first submission. AUC 0.97 across validation dataset.
De Novo
Sepsis Early Warning System — Clinical decision support SaMD. De Novo granted. 40% improvement in early identification vs. standard care.
510(k)
Surgical Implant Planning Software — Orthopedic planning SaMD. 510(k) cleared. Adopted by 3 health systems within 6 months of clearance.
510(k)
Radiology AI — Chest X-Ray Analysis — Diagnostic imaging SaMD. 510(k) cleared. Sensitivity 94.2%, specificity 91.8% on held-out clinical dataset.
De Novo
CGM Data Analysis Software — Remote monitoring SaMD. De Novo granted. Integrated into RPM platform serving 15,000 patients.
How We Build SaMD
Regulatory strategy shapes the architecture, validation, and timeline. Hover or tap a stage to see what it involves.
-
Regulatory Strategy First
Regulatory Strategy First
Intended use statement, risk classification, pathway selection, predicate analysis — decided before product design. The single highest-leverage investment in a SaMD program.
-
IEC 62304 From the First Sprint
IEC 62304 From the First Sprint
Safety classification, development plan, requirements, design, testing, and configuration management — an integrated process, not retrofitted documentation.
-
Algorithm Development and Validation in Parallel
Algorithm Development and Validation in Parallel
Study design, IRB prep, and site selection run alongside algorithm development — so when the algorithm is ready, the study infrastructure is too.
-
Documentation Built for Submission
Documentation Built for Submission
Software Description Document, cybersecurity docs, SBOM, Hazard Analysis, Usability Engineering file, and PCCP for AI/ML products — produced during development, submission-ready.
-
Post-Market Planning Built In
Post-Market Planning Built In
Real-world performance monitoring, adverse event workflows, PCCP update management, and cybersecurity monitoring — built before the product launches.
Compliance & Standards We Treat as Architecture, Not a Checklist
SaMD carries a regulatory load that spans FDA device law, software lifecycle standards, clinical risk management, and global market access. Every standard below is scoped during discovery and built in from the start.
FDA Pathways
FDA SaMD & Submission Pathways
The FDA framework that governs whether and how a clinical software product reaches market — SaMD guidance, the AI/ML action plan, the Predetermined Change Control Plan, and the 510(k) / De Novo / PMA pathways across device classes.
Quality
Quality System & Design Controls
The quality management and design-control requirements an FDA submission and ongoing manufacture depend on.
Software & Risk
Software Lifecycle, Risk & Usability
The engineering standards that make a SaMD product clearable — software lifecycle processes by safety class, clinical risk management, usability engineering, and cybersecurity built to current FDA expectations.
Privacy & Security
Privacy, Security & Data Protection
PHI handling, encryption, access controls, audit logging, and independently audited security across the stack — for every component that touches patient data in a SaMD product.
Global
Global Market Access
EU MDR Article 22 SaMD provisions and GDPR for organizations bringing clinical software to the European market alongside FDA clearance.
Interop & Access
Interoperability & Accessibility
Standards-based clinical data exchange and imaging, plus accessibility by design.
The Clinical Software You're Building Has a Regulatory Reality. The Sooner You Engage With It, the Better.
Organizations that discover SaMD requirements during development build them in. Those that discover them at launch redesign under pressure and delay market entry. The engagements that go well start with regulatory strategy. Thirty minutes. No pitch.
Book a Discovery Call
Award-Winning AI Development & Consulting
100 Fastest Growth Companies
Global Spring Winner
Top App Development Company
AWS Partner Network
Google Cloud Partner
Highly Rated on Trustpilot
Verified Agency
Top App Development Company
ASSOCHAM Member
Frequently Asked Questions
[ 1 ]
How do we know if our software is SaMD?
The determining factor is intended use — what the software is designed to do with clinical data and what clinical decisions flow from its output. If your software analyzes patient-specific data to detect, diagnose, treat, or monitor a medical condition, it's likely SaMD. If it provides general reference information a clinician uses to independently make a decision, it may not be. This classification has a specific answer based on your intended use statement, and we work through it during discovery — before development begins.
[ 2 ]
What's the difference between 510(k) and De Novo for SaMD?
510(k) requires a predicate — a legally marketed device with the same intended use and substantially equivalent technology. De Novo is for novel products where no predicate exists. 510(k) is faster. De Novo takes longer but creates a regulatory precedent that becomes your competitive moat — competitors filing 510(k)s in the same category will cite your clearance as their predicate.
[ 3 ]
How much clinical evidence does FDA require?
It depends on risk classification and pathway. Class II 510(k) typically requires analytical validation and clinical validation data demonstrating the device performs as intended in a representative clinical population. De Novo may require more extensive evidence. The specific requirements are something we discuss with FDA in a pre-submission meeting before committing to a study design.
[ 4 ]
How do you handle AI/ML algorithms that update after clearance?
FDA's guidance on AI/ML-based SaMD introduces the Predetermined Change Control Plan — a document submitted with the original clearance that describes the types of algorithm changes that can be made post-clearance without a new submission. We design PCCP-eligible algorithm architectures and build the real-world performance monitoring infrastructure the PCCP requires.
[ 5 ]
How long does SaMD clearance take?
510(k) review typically runs three to twelve months from submission. De Novo typically runs twelve to twenty-four months. These are FDA review timelines after submission — our development and submission preparation work is separate and typically runs six to eighteen months depending on scope and clinical validation complexity.
[ 6 ]
Who owns the cleared product?
You do. Full IP transfer at project close — algorithm code, training-data infrastructure, clinical validation documentation, regulatory submission materials, everything.
Global presence