FDA SaMD and clinical decision support software
If your software diagnoses, treats or drives clinical decisions, FDA may regulate it as a medical device, and an AI feature can change that answer. Agnotic Technologies builds SaMD inside an IEC 62304 lifecycle, with the risk files, traceability and documentation your regulatory team submits.
Trusted by global innovators
What is FDA SaMD software development?
FDA SaMD software development is building software intended for a medical purpose that performs that purpose without being part of a hardware device, under the controls FDA expects: a documented intended use, risk management, an IEC 62304 lifecycle, verification and validation, and cybersecurity. MedTech product leads need it once a software function meets the device definition.
Is your software a device?
Which software functions does FDA treat as a device?
Device status depends on what each function is intended to do, not on the product as a whole. This is the first pass we make with a MedTech team, function by function.
| What the function does | How the FD&C Act and FDA guidance treat it | What we document |
|---|---|---|
| Administrative support: scheduling, billing, claims or inventory | Excluded from the device definition by section 520(o)(1)(A) | An intended use statement that keeps clinical claims out |
| Encourages a healthy lifestyle, unrelated to a disease or condition | Excluded by section 520(o)(1)(B) | Intended use and marketing claims, reviewed together |
| Shows a clinician a recommendation whose basis they can independently review | May meet the non-device CDS criteria in section 520(o)(1)(E), if every criterion is met | How the basis for each recommendation is shown to the clinician |
| Analyzes a medical image or a physiological signal | Outside the CDS exclusion, so a device function when it serves a medical purpose | An IEC 62304 lifecycle, a risk file and verification evidence |
| Gives a patient or caregiver a treatment recommendation | The CDS criteria cover health care professionals; FDA device policies still apply | Intended user, risk analysis and the regulatory assessment |
| An AI model you plan to update after authorization | A device change; a PCCP in the marketing submission can describe planned modifications | Planned modifications, the validation method and an impact assessment |
This table is engineering guidance, not a regulatory determination. Your regulatory lead or FDA decides how each function is treated.
How does Agnotic build software as a medical device?
A lifecycle-first approach to SaMD: classify risk, stand up the quality system and build with the traceability a submission requires.
Classification & Intended Use
We define intended use, classify the SaMD risk category against the IMDRF framework, and determine the likely FDA pathway.
Quality & Risk Planning
We tailor an IEC 62304 lifecycle and ISO 14971 risk-management plan to your device's software safety class.
Design Controls & Traceability
We implement design controls with requirements-to-test traceability, verification, and validation evidence throughout development.
Submission Support
We assemble the design history and technical documentation and support your regulatory pathway (510(k), De Novo, or exemption).
App gallery
View AllLera Health
Lifecycle-first delivery
A repeatable, evidence-driven lifecycle that captures classification, risk, verification, and validation continuously, so the design history file is ready when the submission is.
Intended Use & Risk Classification
We define intended use and classify SaMD risk (IMDRF categories I-IV), setting the software safety class and pathway.
Quality System & Lifecycle Setup
We stand up IEC 62304 lifecycle processes and ISO 14971 risk management with design-control gates.
Design, V&V & Traceability
We build with requirements traceability, verification, and validation evidence captured continuously in the design history file.
Documentation & Submission
We compile technical documentation and support the appropriate FDA pathway and a post-market surveillance plan.
How are safety and security
built into the lifecycle?
Safety and security are engineered across the device lifecycle: IEC 62304 processes, ISO 14971 risk controls, cybersecurity per FDA premarket guidance and requirements-to-test traceability.
Which FDA rules and standards apply to SaMD?
Short facts from FDA, the FD&C Act and IEC, each linked to its primary source.
FDA uses the IMDRF definition of Software as a Medical Device: software intended to be used for one or more medical purposes that performs these purposes without being part of a hardware medical device.
Source: FDA, Software as a Medical Device (SaMD)Section 520(o)(1)(E) of the FD&C Act excludes from the device definition software that supports recommendations to a health care professional and lets that professional independently review their basis, unless it acquires, processes or analyzes a medical image or a signal.
Source: 21 U.S.C. 360j(o) (govinfo)FDA's final Clinical Decision Support Software guidance (January 2026) explains which CDS functions the criteria in section 520(o)(1)(E) of the FD&C Act exclude from the device definition, and says device policies still apply to functions for patients or caregivers.
Source: FDA guidance, Clinical Decision Support Software (January 2026)IEC 62304 defines the life cycle requirements for medical device software, both when the software is itself a medical device and when it is part of one.
Source: IEC 62304:2006, Medical device software: software life cycle processes (IEC Webstore)
Which other standards apply to SaMD products?
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Featured case study
Read Case StudyLera Health: compliant health platform
Related proof of regulated-grade delivery: for Lera Health we built a testing-to-insights workflow with traceable data handling and clinical rigor, the same discipline a SaMD lifecycle and design history file demand.
FDA SaMD software development FAQs
Build compliantly