An Introduction to Software as a Medical Device (SaMD)

International Definition (IMDRF): Software as a Medical Device (SaMD) is defined by the International Medical Device Regulators Forum (IMDRF) as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device” ^[1]. In other words, SaMD is standalone software with a medical intent, running on general-purpose computing platforms (e.g. PCs, smartphones, cloud servers) rather than dedicated medical hardware ^[2]. Notably, SaMD is considered a medical device in its own right (including software intended for in-vitro diagnostic purposes) ^[3]. IMDRF’s 2013 foundational guidance established this common definition to harmonize global understanding of standalone medical software ^{[4] [5]}.

FDA and Other Regulators: The U.S. FDA has adopted the IMDRF definition of SaMD verbatim ^[4]. FDA identifies SaMD as one of three categories of medical device software (the others being software in a device, and software used in device production/maintenance) ^[6]. Health Canada and several other regulators likewise use the IMDRF definition in their policies. For example, Health Canada’s guidance explicitly mirrors IMDRF’s wording and notes (e.g. clarifying that software to drive a hardware device is not SaMD) canada.ca canada.ca. This global convergence, driven by IMDRF’s SaMD working group, means that many jurisdictions share a common vocabulary for SaMD ^[5].

EU Perspective: The EU Medical Device Regulation (MDR) does not use the term “SaMD” explicitly, but covers such software under Medical Device Software (MDSW). EU guidance (MDCG 2019-11) defines MDSW as software intended to be used for a medical purpose (as per the MDR’s general medical device definition) whether standalone or as part of a device ^[7]. Standalone software with a medical purpose is considered an “active” medical device in the EU, and is regulated as a device on its own. Thus, while the term SaMD is not in the EU MDR text, the concept is fully recognized – any software with a medical intended purpose is regulated under MDR/IVDR requirements just like other devices ^[8]. In practice, the scope of SaMD (standalone medical software) in the EU is aligned with IMDRF’s scope, even if termed differently.

It is important to distinguish SaMD from other software categories such as Software in a Medical Device (SiMD). SaMD refers to software that itself is a medical device, operating on general-purpose hardware and not required to be embedded in dedicated medical hardware ^[9]. By contrast, SiMD is software that is integral to a specific medical device’s hardware – for example, firmware that controls an MRI machine or an infusion pump is SiMD, since the hardware device relies on that software to achieve its medical purpose ^[10]. A rule of thumb is that if the software’s intended function is necessary for a hardware device to work (or it “drives or controls” a medical hardware), it is not SaMD canada.ca. SaMD can interface with physical devices and even utilize data from them, but the key is that the software can perform its medical function independently (e.g. a diagnostic smartphone app) ^{[11] [10]}. FDA examples distinguish software that post-processes medical images to help detect breast cancer, which can be SaMD, from software that drives or controls an infusion pump, which is not SaMD because it is part of the hardware medical device. FDA SaMD examples In summary, SaMD is “stand-alone” medical software, whereas SiMD is “embedded” software part of a device’s hardware. This distinction is crucial because it affects regulatory pathways and design considerations – SaMD, being independent, is regulated on its own merits, with distinct development and validation approaches compared to software tied to a physical device ^[12].

Regulators worldwide apply a risk-based framework to SaMD, building on common principles but with jurisdiction-specific classifications and approval pathways:

• United States (FDA): In the U.S., SaMD is regulated as a medical device under the FDA’s device classification system (Class I, II, or III) according to risk ^[13]. Many SaMD products fall into Class II (moderate risk) which typically require FDA 510(k) premarket notification (showing substantial equivalence to an existing device) for clearance. Novel SaMD with moderate risk may use the De Novo pathway to establish a new classification if no predicate exists, while higher-risk SaMD (e.g. those that could directly cause harm if they malfunction) are Class III and require full Premarket Approval (PMA) ^[14]. The FDA expects SaMD developers to follow applicable quality-system requirements. 21 CFR Part 11 applies to electronic records and signatures required by FDA predicate rules or submitted to FDA, not merely because software handles medical data. Effective February 2, 2026, FDA’s Quality Management System Regulation (QMSR) amended 21 CFR Part 820 and incorporates ISO 13485:2016 by reference. The QMSR harmonizes FDA’s CGMP framework with international quality-management requirements, but FDA requirements control where they conflict with the incorporated standard. FDA QMSR overview FDA has issued guidance on the content of premarket submissions for software. FDA’s 2017 Software as a Medical Device (SaMD): Clinical Evaluation guidance was withdrawn on January 6, 2026, and no longer represents FDA’s current thinking ^[15]. FDA describes the IMDRF framework as a possible risk-categorization framework; the framework is not a regulation, and FDA applies its own statutory device-classification and premarket requirements. FDA: Global Approach to SaMD SaMD manufacturers are encouraged to use FDA-recognized consensus standards (such as IEC 62304 for software lifecycle processes) to streamline approvals ^[16]. Overall, the U.S. framework emphasizes demonstrating safety and effectiveness via appropriate clinical evidence and software validation, commensurate with the device’s risk class.

• European Union (EU MDR): Under the EU MDR 2017/745, standalone software with a medical purpose is classified as a medical device and is subject to the same risk-classification rules as other devices. Classification Rules: Rule 11 of the MDR (Annex VIII) specifically addresses software. Under Rule 11 of Annex VIII, software providing information used to make diagnostic or therapeutic decisions is generally Class IIa; it is Class IIb where decisions may cause serious deterioration of health or surgical intervention, and Class III where decisions may cause death or irreversible deterioration of health. Software intended to monitor physiological processes is Class IIa, except where it monitors vital physiological parameters and variations could result in immediate danger, when it is Class IIb. Other software is Class I. Regulation (EU) 2017/745, Annex VIII These rules mean many clinical SaMD products in the EU are classed as IIa/IIb, with a few high-impact ones as Class III. Conformity Assessment: Depending on the class, SaMD manufacturers must undergo conformity assessment (involving a Notified Body for classes IIa, IIb, III) to obtain CE marking under MDR. They must meet the General Safety and Performance Requirements, including demonstrating clinical performance and data security. The MDR requires manufacturers to establish a quality management system. ISO 13485 is widely used to help demonstrate conformity, but the MDR does not universally require ISO 13485 certification; software lifecycle standards such as IEC 62304 are commonly used as part of the state of the art. Indeed, IEC 62304 (for software development processes) and ISO 14971 (risk management) are widely used to satisfy MDR requirements for software design control and risk mitigation ^[17]. EU AI Act Intersection: AI-enabled SaMD may be subject to both the EU MDR and the EU AI Act (Regulation 2024/1689), depending on the product and its intended purpose. Under the European Commission’s current timeline, rules for AI embedded in regulated products, including medical devices, apply from August 2, 2028digital-strategy.ec.europa.eu. Manufacturers should assess the applicable MDR and AI Act requirements for their specific product. In summary, the EU framework classifies SaMD stringently by patient risk and requires comprehensive evidence and quality controls proportional to that risk.

• International Standards and Controls: Across jurisdictions, ISO 13485 (Medical Devices QMS) is the cornerstone for quality management – SaMD producers are generally expected to have an ISO 13485-compliant QMS covering software design, validation, risk management, and post-market activities ^{[18] [19]}. The FDA's 2026 adoption of QMSR (incorporating ISO 13485:2016 by reference) has further harmonized the U.S. framework with international standards, reducing the compliance burden for global SaMD manufacturers. IEC 62304 is the internationally recognized standard for medical device software lifecycle processes. It defines best practices for software development, maintenance, configuration management, problem resolution, and risk management. Notably, IEC 62304 also requires classifying software items by safety criticality (Class A: no injury possible; Class B: minor injury possible; Class C: serious injury or death possible) and imposes correspondingly rigorous processes for higher classes ^[20]. FDA recognizes IEC 62304:2006+A1:2015 as a voluntary consensus standard for medical-device software lifecycle processes; use of an FDA-recognized standard can support a declaration of conformity in an FDA submission. In the EU, a presumption of conformity applies only to the MDR requirements covered by a relevant harmonised standard whose reference has been published in the Official Journal of the European Union. FDA-recognized IEC 62304 record MDR Article 8 In addition, standards like ISO 14971 (Risk Management) must be applied to identify and control software risks throughout the product lifecycle ^[17]. Compliance with these standards is often verified during regulatory submissions or audits. Finally, specialized guidances (IMDRF and national) exist for specific aspects: IMDRF’s own quality framework for SaMD QMS, clinical evaluation guidance, and risk categorization framework have been influential in shaping national regulations ^{[21] [22]}. Many countries (Canada, Japan, Australia, etc.) have aligned their SaMD regulatory approach with the IMDRF principles, requiring risk-based classification, evidence of clinical effectiveness, and lifecycle management controls similar to FDA/EU models.

Modern healthcare already employs numerous SaMD products, including innovative AI-driven tools and digital therapeutics. Below are a few notable examples (with their regulatory status and use cases):

• LumineticsCore (formerly IDx-DR, by Digital Diagnostics): An AI-based diagnostic software for diabetic retinopathy that analyzes retinal images. In 2018, IDx-DR became the first FDA-authorized autonomous AI diagnostic SaMD, cleared via De Novo classification ^[23]. It can detect diabetic retinopathy in primary care settings without a specialist, demonstrating how SaMD can provide clinical decision support. The product was rebranded to LumineticsCore in 2023 and remains in active clinical use, with growing health-system adoption demonstrating the long-term viability of autonomous AI SaMD ^[24].

• Viz.ai “ContaCT” Stroke Detection: Viz.ai’s software that analyzes CT brain scans to identify large vessel occlusion strokes and alert specialists. It was authorized as a SaMD in the U.S. (De Novo grant in 2018) to facilitate faster stroke interventions ^[25]. This AI tool exemplifies SaMD in radiology: it interfaces with hospital imaging systems but performs its analysis independently, triaging patients by analyzing images for clots. Viz.ai’s platform has since expanded (via additional 510(k) clearances) to detect other conditions, illustrating iterative SaMD innovation.

• Pear Therapeutics reSET® and reSET-O®: These were Prescription Digital Therapeutics delivered via mobile app for substance use disorders. reSET (for drug/alcohol addiction) was the first FDA-authorized therapy app (cleared in 2017) for treating SUD, intended to be used alongside outpatient therapy ^{[26] [27]}. It delivers cognitive behavioral therapy through interactive modules and has been shown to improve abstinence rates ^[28]. Note: Pear Therapeutics filed for Chapter 11 bankruptcy in April 2023, and its assets were sold at auction for just $6 million – a cautionary tale about the commercial challenges facing digital therapeutics, particularly around reimbursement and payer adoption ^[29]. The reSET and reSET-O products were acquired by PursueCare, which relaunched them in 2024 as direct-to-consumer offerings ^[30].

• Akili Interactive's EndeavorRx: A pediatric ADHD treatment in the form of a video game. EndeavorRx is an FDA-authorized digital therapeutic (De Novo granted in 2020) indicated to improve attention function in children with ADHD. The software runs on a tablet and uses adaptive algorithms within a gaming environment to deliver therapeutic exercise for the brain. It was proven to improve objective attention measures in clinical studies. As a SaMD, EndeavorRx is noteworthy as the first game-based therapy cleared by FDA, highlighting the broad scope of what SaMD can encompass ^{[31] [32]}. Update: Akili pivoted away from the prescription model and received FDA clearance for EndeavorOTC, an over-the-counter version for adults. In mid-2024, Akili was acquired by Virtual Therapeutics for $34 million – far below its $1 billion SPAC valuation – underscoring the commercial difficulties of prescription digital therapeutics ^[33].

• AI-Powered Imaging System (not a standalone SaMD): Hologic’s Genius™ Digital Diagnostics System with the Genius™ Cervical AI algorithm is an FDA-authorized integrated digital cervical-cytology system. Its De Novo authorization, DEN210035, covers the imager, image-management server, review station, and AI algorithm together; therefore, the authorized product should not be characterized as a standalone SaMD example. FDA decision summary

(These examples demonstrate the diversity of SaMD, from diagnostic algorithms to therapeutic and monitoring software. FDA maintains a periodically updated, noncomprehensive list of AI-enabled medical devices authorized for marketing in the United States. Devices on the list have met applicable premarket requirements, but the evidence required—including whether clinical data are needed—depends on the device and its regulatory pathway.) FDA AI-enabled medical-device list

Managing a SaMD through its lifecycle requires a holistic approach covering risk assessment, rigorous development practices, validation, clinical evaluation, and ongoing surveillance:

• Risk Classification: An early step is determining the SaMD’s risk category, which influences the level of regulatory control and documentation needed. IMDRF’s framework categorizes SaMD from Category I (lowest risk) to IV (highest risk) based on the significance of the software’s information to healthcare decisions and the criticality of the clinical condition ^{[21] [34]}. For instance, software that provides information treating or diagnosing a critical condition would be Category IV (highest risk), whereas software that informs clinical management of a non-serious condition might be Category I ^[34]. The IMDRF categories are not a direct legal crosswalk to FDA or EU classes; classification must be determined under the rules and intended use applicable in each jurisdiction. FDA: Global Approach to SaMD MDR Annex VIII Additionally, during development, standards like IEC 62304 require classifying software items by safety risk (Class A/B/C) which then dictates the rigor of development and testing processes ^[20]. Proper risk classification ensures that appropriate controls (design, verification, regulatory pathway) are applied proportionate to the potential harm from software failure.

• Software Development Lifecycle (SDLC): SaMD development must follow a structured lifecycle with strong quality controls. IEC 62304 provides the blueprint: it prescribes phases such as software planning, requirements analysis, design, implementation, integration, verification, and maintenance ^{[35] [36]}. Manufacturers need to establish requirements traceability, risk management integration, configuration management, and problem resolution processes as part of development ^{[37] [17]}. In practice, this means producing software requirements specifications, design documents, code reviews, unit and integration testing, system verification and validating that the final software meets user needs and safety requirements. Agile development can be used, but it must be underpinned by design controls and documentation to satisfy regulatory auditors. Verification and Validation (V&V) are critical: every requirement must be verified (through tests, inspections, etc.), and the overall software must be validated in an environment representative of actual use. FDA often expects a “level of concern” analysis to determine how much V&V evidence to submit (Major, Moderate, Minor level of concern based on potential for harm) ^{[38] [39]} – higher concern software demands more extensive testing evidence. Ultimately, a SaMD developer should demonstrate through objective evidence that the software is reliable and performs as intended under all specified conditions.

• Clinical Evaluation: Beyond technical validation, the clinical evidence needed for SaMD depends on its intended use and the applicable regulatory pathway. For example, FDA notes that clinical data are not needed for most devices cleared through the 510(k) process. The IMDRF SaMD clinical-evaluation framework describes three pillars: a valid clinical association (a scientific rationale linking the software output to a clinical condition or outcome), analytical validation (evidence that the software accurately and reliably processes inputs), and clinical validation (evidence supporting the software’s clinical performance for its intended use) ^[40]. FDA withdrew its guidance adopting this framework on January 6, 2026, so it should not be presented as current FDA guidance ^[15]. For example, for an AI diagnostic SaMD, developers must show that the algorithm’s output correlates with the disease (association), that it achieves sufficient sensitivity/specificity on test data (analytical performance), and that its use improves clinical decision-making or patient outcomes in practice (clinical performance). Clinical evaluation is an ongoing process – manufacturers often need to continually assess performance as real-world data accumulates. Documentation of clinical evidence (e.g. study reports, literature, validation studies) is required in regulatory submissions and for CE marking to prove the SaMD’s safety and effectiveness.

• Regulatory Submission & Approval: Once design and validation are complete, manufacturers compile the evidence into a regulatory submission (510(k), De Novo, PMA, CE Technical File, etc.). This includes software documentation (requirements, design specs, test reports), risk analysis, usability engineering, manufacturing and cybersecurity information, and clinical evidence. A robust Quality Management System (typically ISO 13485 certified) is generally expected to be in place by this stage to ensure all processes were controlled ^[13]. After obtaining approval or clearance, the SaMD can be marketed, but the lifecycle does not end there.

• Post-Market Surveillance & Maintenance: After release, SaMD requires vigilant post-market surveillance, just like any medical device. Manufacturers must monitor field performance and safety signals and comply with reporting requirements (e.g. FDA’s Medical Device Reporting for adverse events, EU’s vigilance reporting and periodic safety update reports). Key post-market activities include collecting customer feedback and complaints, tracking any device malfunctions or usage errors, and reviewing clinical outcomes or literature for any indication of reduced performance ^[41]. Real-world performance monitoring is especially crucial for SaMD because software may behave differently in diverse real-world settings or patient populations than in clinical trials. By monitoring metrics and user reports, manufacturers can detect issues like algorithm drift, unforeseen use cases, or rare failure modes and then correct them. Indeed, regulators encourage ongoing real-world performance data collection to support continuous improvement of SaMD ^{[42] [43]}. Change management is another important aspect: software updates (for bug fixes, cybersecurity patches, or feature enhancements) must be handled under design control. Manufacturers should have procedures to evaluate whether a software change requires a new regulatory submission (FDA has guidance on when a software change triggers a new 510(k) ^[44]). They should also re-validate significant changes. Maintenance and Support: IEC 62304 outlines a software maintenance process – manufacturers should actively maintain an inventory of known issues (“unresolved anomalies”), provide timely updates, and ensure backward compatibility or data migration as needed ^{[45] [46]}. Ultimately, lifecycle management of SaMD is a continuous, iterative process: from initial risk analysis and design, through validation and regulatory approval, to deployment with monitoring and feedback loops leading to improvements. This Total Product Life Cycle (TPLC) approach is championed by regulators to ensure SaMD remains safe and effective through its lifespan.

While SaMD offers exciting benefits, it also presents unique challenges that developers and regulators must address:

• Interoperability: SaMD must integrate into complex health IT ecosystems. Achieving seamless data exchange between the software and hospital electronic health records (EHRs), medical devices, or cloud databases can be difficult when systems use disparate standards. Lack of interoperability can lead to “data silos” where the SaMD cannot access or share crucial data ^[47]. Standards Adoption: To overcome this, SaMD developers use standards like HL7 FHIR and DICOM, and APIs to enable compatibility ^[47]. Interoperability is not just a technical nice-to-have – it is critical for clinical adoption. Healthcare providers are far more likely to embrace a SaMD that “works seamlessly with their existing EHRs and workflows” ^[48]. Thus, building to common data standards and collaborating with provider IT systems early is important. Integration testing across multiple platforms is a best practice to ensure the SaMD functions in different environments ^[49]. Interoperability also has a regulatory dimension: data exchange must comply with privacy laws (e.g. HIPAA in the US, GDPR in the EU), adding complexity ^[50]. Overall, ensuring interoperability requires extra development effort but pays off in safer, more effective deployment and user acceptance.

• Cybersecurity: Because SaMD often runs on general hardware and connects via networks, it is highly exposed to cyber threats. Hacks or malware intrusions could not only breach sensitive health data but potentially disrupt the software’s function, risking patient harm. Regulators have escalated requirements in recent years to ensure manufacturers build in robust cybersecurity. In the United States, section 524B of the FD&C Act requires specified cybersecurity information in premarket submissions for devices that meet the statutory definition of a “cyber device,” including plans to manage vulnerabilities and exploits. For those cyber devices, the submission must include a software bill of materials covering commercial, open-source, and off-the-shelf software components. FDA cybersecurity FAQs FDA’s February 2026 final premarket cybersecurity guidance supersedes its June 2025 final guidance and provides nonbinding recommendations on cybersecurity device design, labeling, and premarket-submission content, including secure-by-design considerations. FDA cybersecurity premarket guidance Manufacturers should implement measures like data encryption, user authentication, secure coding practices, and penetration testing. Cybersecurity vulnerabilities can affect device safety and effectiveness. FDA requires specified cybersecurity information in premarket submissions for devices that meet the statutory definition of a cyber device and recommends lifecycle cybersecurity management. FDA cybersecurity FAQs Therefore, cybersecurity for SaMD is directly tied to patient safety. It requires ongoing vigilance: monitoring for new threats, issuing security patches, and possibly providing a way to update software in the field quickly. Regulatory guidance (e.g. FDA’s guidances on premarket and postmarket cybersecurity) emphasize that cybersecurity is a part of the device’s safety and must be managed throughout the lifecycle. Manufacturers should also plan for incident response in case of breaches. In sum, cybersecurity is a paramount concern for SaMD, demanding proactive risk assessments and defenses to maintain trust and safety in an increasingly connected healthcare environment ^{[51] [52]}.

• Data Integrity and Reliability: SaMD often processes large volumes of medical data (images, sensor readings, patient inputs). The integrity of this data – ensuring it’s accurate, complete, and not corrupted – underpins the software’s correctness. Challenges to data integrity come from multiple angles: software bugs that might alter data, integration issues (e.g. formatting errors in data exchange), or malicious tampering. Manufacturers need to implement safeguards such as input validation (so the software correctly handles unexpected or extreme data values), error-checking and redundancy (to prevent data loss or corruption), and secure data transmission protocols. Real-time monitoring can be important for critical SaMD to detect anomalies in output that might indicate an integrity issue. For example, cloud-based SaMD might use checksums or cryptographic hashes to ensure data isn’t altered in transit. In regulated environments, maintaining data integrity is also about audit trails – the software should log data processing steps so that any issues can be traced and corrected. From a compliance standpoint, regulators expect that any databases or outputs associated with SaMD are protected from unauthorized alteration (tying into both cybersecurity and good software engineering practices). Thus, ensuring data integrity overlaps with both robust design (testing for edge cases, fail-safes if data is missing or implausible) and security (preventing unauthorized access or injection of false data). Ultimately, a SaMD’s clinical decisions are only as good as the data going in and out, so maintaining fidelity of that data is a critical consideration at every stage of design and deployment.

• Privacy and Data Protection: SaMD frequently handles personal health information (PHI), putting it under stringent data protection regimes. Patient privacy must be safeguarded by design. In the EU, health data are a special category of personal data under the GDPR. Processing requires a lawful basis and a condition under Article 9; controllers must also apply data minimization and data protection by design and by default. SaMD developers should collect only data necessary for the intended purpose and consider safeguards such as pseudonymization where appropriate. GDPR Data protection by default does not make consent or opt-in universally required: controllers must identify an appropriate GDPR legal basis and, for health data, a relevant condition for processing special-category data. Appropriate technical and organisational safeguards may include access controls, encryption, and authentication. European Data Protection Board: legal basis GDPR In the U.S., HIPAA applies to covered entities and their business associates, not simply because software handles data from providers or insurers. Where a SaMD developer is a business associate, its contract and applicable HIPAA requirements may include safeguards for protected health information. HHS: Covered Entities and Business Associates Cross-border issues: if SaMD uses cloud servers, data residency and international transfer rules must be considered (e.g. using EU-based servers for EU patient data). Non-compliance with privacy laws can lead to severe penalties and undermine user trust. Therefore, SaMD companies often employ dedicated data protection officers and undergo privacy impact assessments. Transparent user communication (privacy notices, consent dialogues) is another aspect – users should know what data is collected and how it’s used. In summary, protecting patient data privacy is both an ethical obligation and a legal requirement; it demands technical measures and governance policies to ensure that sensitive data managed by SaMD is not exposed or misused.

• Real-World Performance and Reliability: After deployment, SaMD faces the reality of diverse users, varied clinical settings, and potentially evolving conditions – all of which can affect performance. Algorithms might encounter data that differ from the training set (for AI/ML SaMD) or users might use the software in unanticipated ways. Real-world performance monitoring is essential to verify that the software continues to achieve its intended clinical outcomes once widely deployed ^{[53] [54]}. For example, an AI diagnostic tool may perform slightly differently across different hospital patient populations; continuous performance data can reveal if sensitivity or specificity drifts over time. Manufacturers are encouraged to collect real-world data (RWD) and real-world evidence through post-market studies or device registries. This is part of the “learning” post-market feedback loop: if real-world performance is below expectations, the manufacturer should investigate root causes – perhaps the need for a software update or model re-training. Software updates are a double-edged sword: they can improve performance or add features, but each change must be carefully managed and not degrade existing functionality. Regulators like FDA have discussed frameworks for “continuous learning” AI SaMD where algorithms retrain on new data, but these require a robust change control plan to ensure safety is maintained ^[55]. Another real-world factor is scalability and load: a cloud-based SaMD might perform well with 100 users but experience issues with 10,000 users – so developers must ensure the software scales and remains responsive/reliable under real usage volumes. User feedback is also invaluable; user complaints might highlight usability issues that affect real-world efficacy (e.g. if a therapy app is too hard to navigate, patients won’t benefit as intended). Finally, environmental considerations such as compatibility with different operating systems, updates of underlying platforms, and even language/cultural adaptation can influence real-world success. In short, ensuring that SaMD continues to perform in the messy, uncontrolled real world is a key challenge – one addressed by strong post-market surveillance, agile maintenance practices, and a mindset of continuous improvement over the product’s life.

The SaMD field is rapidly evolving, intersecting with cutting-edge digital health trends:

• Rise of Digital Therapeutics: SaMD is central to digital therapeutics (DTx): software intended to deliver clinical interventions, often for chronic conditions or behavioral health. These products can turn evidence-based behavioral therapies or rehabilitation exercises into interactive software programs, but their regulatory status, evidence base, and route to market depend on their specific intended use. Commercial adoption also depends on coverage and payment policies. In the CY 2025 Medicare Physician Fee Schedule final rule, CMS finalized three HCPCS codes and Medicare payment for qualifying digital mental health treatment devices furnished incident to professional behavioral health services as part of an ongoing treatment plan. CMS CY 2025 final-rule summary Digital therapeutics also raise important questions about how software updates are evaluated and how clinicians prescribe and monitor their use.

• Remote Monitoring and Telehealth Integration: SaMD plays a pivotal role in remote patient monitoring, especially as telehealth has grown. Software that can utilize data from wearables or home medical devices to monitor patients and flag issues is increasingly common. For example, SaMD can continuously analyze heart rate or glucose data and alert clinicians to trends, or a mobile app can check a patient’s symptoms and vital signs post-surgery to detect complications early. These remote monitoring SaMD often incorporate AI algorithms to filter noise and detect patterns. Trend: integration with the Internet of Things (IoT) – body-worn sensors, smartwatches, connected blood pressure cuffs all feeding into SaMD analytics. Regulators have been supportive, especially during the COVID-19 pandemic, of remote monitoring tools and have sometimes fast-tracked such software. The challenge remains ensuring data accuracy and managing the volume of data (for example, avoiding alarm fatigue by tuning algorithms to minimize false alerts). Nonetheless, remote monitoring SaMD are poised to transform chronic disease management and post-acute care, enabling more proactive and personalized interventions outside traditional clinical settings.

• AI/ML-Driven Diagnostics and Decision Support: Arguably the most impactful trend in SaMD is the incorporation of artificial intelligence and machine learning. AI/ML can enable software to interpret complex data (imaging, genomic, sensor data) with high speed and sometimes expert-level accuracy. We already have SaMD AI reading radiology images for fractures, detecting cancers in pathology slides, assessing dermatology photos for melanoma risk, and even listening to voice patterns for signs of pulmonary disease. Regulators' stance: FDA maintains a periodically updated, noncomprehensive list of AI-enabled medical devices authorized for marketing in the United States. The list is not limited to SaMD and identifies devices primarily through AI-related terms in public authorization materials or device classifications. FDA AI-enabled medical-device list A current frontier is adaptive AI – algorithms that continue to learn post-deployment. FDA’s guidance, Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions, was issued in August 2025. It provides recommendations for describing planned modifications in a marketing submission; whether a change may be implemented without a new submission depends on the authorized PCCP and applicable requirements. FDA PCCP guidance These developments reflect a broader innovation need: balancing the benefits of continuous improvement in AI against regulatory assurance of safety. Additionally, transparent and ethical AI is a hot topic: ensuring AI SaMD decisions can be explained to users and that biases in algorithms are identified and mitigated. Industry and regulators (through initiatives like IMDRF’s AI working group) are working on Good Machine Learning Practice (GMLP) guidelines to standardize development and validation of AI in SaMD ^[56]. We also see trends toward using large language models (LLMs) in healthcare (for example, AI chatbots for patient triage or decision support) – FDA has signaled interest in how to identify and evaluate such uses ^[57]. As these sophisticated AI SaMD emerge, ongoing innovation will involve incorporating real-world feedback to refine algorithms, and using techniques like federated learning to update models without centralizing sensitive data, all under the watch of regulators adapting new guidance.

• Advanced Sensors and Digital Biomarkers: Innovations in SaMD are also being driven by new data sources. Smartphone sensors, wearables, and even digital cameras are enabling novel “digital biomarkers” – for instance, gait patterns from phone accelerometers to predict fall risk, voice analysis via apps to detect depression, or camera-based blood flow analysis for vital signs. These software solutions blur the line between wellness and medical, but many are moving into regulated SaMD space as their clinical utility is proven. Regulators have had to clarify what software functions are low-risk enough to be considered general wellness (and not regulated) versus those that make medical claims and thus require oversight. The trend is that more high-quality evidence is turning what started as wellness apps into bona fide SaMD (for example, apps that initially just tracked diet, now claiming to treat obesity or diabetes with behavioral therapy content). Digital twins and personalized medicine are on the horizon too – software that models a patient’s condition to predict treatment responses or surgery outcomes could become SaMD, offering truly individualized decision support.

• Regulatory Science and Support for SaMD: As a final trend, regulatory bodies themselves are innovating in how they evaluate and approve SaMD. The FDA’s Digital Health Center of Excellence (launched in 2020) is dedicated to advancing oversight for software-based products ^[6]. Collaborative communities between regulators, industry, and academia are developing new standards for things like software clinical evaluation methods, real-world evidence use, and cybersecurity certification. In the EU, expert panels may be consulted for novel high-risk SaMD (e.g. AI that diagnoses), adding expert scrutiny. There's also movement toward harmonizing regulations – IMDRF continues to work on SaMD guidance updates (a new working group was established in 2022 to delve further into SaMD regulatory challenges ^[58]). In January 2026, the FDA updated its guidance on Clinical Decision Support (CDS) software and general wellness products, taking a more deregulatory posture toward certain lower-risk software functions – for example, broadening the scope of non-invasive wearables that qualify as general wellness products exempt from regulation ^[59]. The FDA also withdrew its guidance on adopting IMDRF's SaMD Clinical Evaluation principles, signaling a shift toward more FDA-specific evaluation approaches. Meanwhile, in the EU, some AI-enabled SaMD may need to satisfy both MDR and AI Act requirements. Under the European Commission’s current timeline, the AI Act rules for AI embedded in regulated products, including medical devices, apply from August 2, 2028 digital-strategy.ec.europa.eu. All of this suggests the SaMD regulatory environment will continue to evolve in tandem with technology, aiming to ensure that innovation can reach patients quickly without compromising on safety or effectiveness.

Conclusion: Software as a Medical Device has become a dynamic sector at the intersection of healthcare and technology. Its regulatory landscape, once nascent, is now well-defined by international standards and evolving to accommodate AI and digital therapeutics. Successful SaMD products require not only creative technical development but also diligent compliance with quality practices, clinical validation, and post-market responsibilities. As interoperability improves, cybersecurity is fortified, and real-world evidence is harnessed, SaMD will increasingly enable cutting-edge care – from early disease detection to personalized therapy – delivered through the power of software. The continued collaboration of industry innovators with regulators and clinicians will be key to fully realizing SaMD’s potential to improve global health outcomes. ^{[21] [60]}

Sources:

1. IMDRF SaMD Working Group – Key Definitions (2013) ^{[1] [61]}

2. FDA Digital Health Center – “What is SaMD” (2018) ^[4]; FDA SaMD Working Group Report ^[5]

3. BSI Guidance on Software as a Medical Device (2024) ^{[7] [62]}

4. Cognidox Blog – FDA Regulation of SaMD (2021) ^{[11] [10]}

5. Health Canada – SaMD: Definition and Classification (2022) canada.ca canada.ca

6. FDA Digital Health Guidance – IMDRF Risk Framework (2017) ^{[21] [34]}

7. EU MDR Annex VIII – Rule 11 for Software ^{[63] [64]}

8. HTD Health – IEC 62304 & ISO 13485 for SaMD (2023) ^{[19] [17]}

9. Orthogonal Inc. – FDA-Cleared SaMD List (2024) ^{[23] [25]}

10. BioSpace – Pear Therapeutics wins FDA nod for reSET (2017) ^{[26] [27]}

11. FDA De Novo Summary – EndeavorRx (DEN200026) (2020) ^[31]

12. FDA SaMD Examples – FDA SaMD Examples Page ^[65] (for context)

13. IMDRF SaMD Working Group – Clinical Evaluation (2017) ^[40]

14. Cognidox – SaMD Post-market and 510(k) Changes (2021) ^{[41] [45]}

15. Orthogonal Inc. – SaMD Interoperability Guide (2025) ^{[48] [47]}

16. HTD Health – FDA Cybersecurity Requirements (2023) ^{[66] [67]}

17. Sequenex – GDPR and SaMD Data Protection (2023) ^{[68] [69]}

18. FDA – Artificial Intelligence in SaMD (2021) ^{[70] [71]}