An Introduction to Software as a Medical Device (SaMD) (original) (raw)

[Revised February 16, 2026]

Software as a Medical Device (SaMD): Comprehensive Overview

Definition and Scope of 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.

SaMD vs. SiMD (Software in a Medical Device)

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]. The FDA illustrates this difference with examples: software that analyzes medical images to assist diagnosis is SaMD, whereas software that operates or calibrates the imaging machine itself is SiMD [12]. 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 [13].

Global Regulatory Frameworks for SaMD

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 [14]. 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) [15]. The FDA expects SaMD developers to follow quality system regulations and, for software handling medical data, electronic records rules ([16]) [14]. Notably, as of February 2, 2026, the FDA's new Quality Management System Regulation (QMSR) has replaced the legacy Quality System Regulation (21 CFR 820), formally incorporating ISO 13485:2016 by reference[17]. This harmonization means SaMD manufacturers worldwide can now leverage the same ISO 13485 standard for both FDA and international compliance, though FDA retains its inspectional authority independently of ISO certification. Compliance with FDA’s guidance documents is critical – for example, FDA has issued guidance on “Content of Premarket Submissions for Software” and adopted IMDRF’s guidance on SaMD Clinical Evaluation [18]. In practice, FDA aligns with IMDRF’s risk categorization and principles. SaMD manufacturers are encouraged to use FDA-recognized consensus standards (such as IEC 62304 for software lifecycle processes) to streamline approvals [18]. Overall, the U.S. framework emphasizes demonstrating safety and effe
  ctiveness 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. In general, software that provides information for diagnostic or therapeutic decisions is Class IIa by default, but if such decisions could result in serious deterioration or surgical intervention, it is Class IIb, and if they could result in death or irreversible deterioration, it is Class III[19]. Software intended to monitor physiological processes is Class IIa, unless it monitors vital parameters where variations could pose immediate danger (then Class IIb) [20]. All other medical software not meeting these criteria falls in Class I [21]. 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 EU mandates a robust Quality Management System (QMS) – effectively ISO 13485 compliance – for manufacturers, and adherence to software lifecycle standards like IEC 62304 is expected 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 [22]. EU AI Act Intersection: Starting in 2026–2027, AI-enabled SaMD in the EU must also comply with the EU AI Act (Regulation 2024/1689). Most AI-based medical devices will be classified as "high-risk AI systems" under the AI Act, requiring conformity assessments under both the MDR and the AI Act. The MDCG published guidance (MDCG 2025-6) in June 2025 defining "Medical Device Artificial Intelligence (MDAI)" products subject to dual regulation health.ec.europa.eu. The European Commission's November 2025 Digital Omnibus package proposes to streamline some overlapping requirements, but manufacturers should prepare for dual compliance. 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 [23] [24]. 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 [25]. Regulators (including FDA, EU, etc.) recognize IEC 62304 as a benchmark for SaMD development, and following it provides a “presumption of conformity” to software engineering expectations [22] [26]. In addition, standards like ISO 14971 (Risk Management) must be applied to identify and control software risks throughout the product lifecycle [22]. 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 [27] [28]. 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.

Real-World Examples of SaMD

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 [29]. 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 [30].
• 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 [31]. 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 [32] [33]. It delivers cognitive behavioral therapy through interactive modules and has been shown to improve abstinence rates [34]. 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 [35]. The reSET and reSET-O products were acquired by PursueCare, which relaunched them in 2024 as direct-to-consumer offerings [36].
• 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 [37] [38]. 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 34million–farbelowits34 million – far below its 34million–farbelowits1 billion SPAC valuation – underscoring the commercial difficulties of prescription digital therapeutics [39].
• AI-Powered Imaging SaMD: Many SaMD products leverage AI/ML for image analysis. For example, Hologic’s Genius™ Digital Diagnostics is a pathology SaMD that uses AI to assist in cervical cancer screening (PAP smear analysis), cleared by FDA in 2021. Another example is Arterys CardioAI, which assists cardiac MRI interpretation (cleared via 510(k)). Qure.ai’s qXR is a CE-marked SaMD using AI to detect tuberculosis and lung nodules on chest X-rays, used in public health programs. These products, deployed in real clinical workflows, show SaMD’s value in augmenting clinicians with advanced analytics.

(These examples demonstrate the diversity of SaMD: from diagnostic algorithms and imaging aids to therapeutic and monitoring software. Many are powered by machine learning – as of 2025, the FDA has authorized over 1,000 AI/ML-enabled medical devices, with 295 new clearances in 2025 alone, the majority in radiology – and all underwent rigorous regulatory scrutiny to validate their clinical performance.) [40] [41]

SaMD Lifecycle Management: From Development to Post-Market

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 [27] [42]. 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 [42]. Regulators map such categorizations to their class systems (e.g. IMDRF Category IV likely corresponds to FDA Class III / EU Class III). 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 [25]. 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 [43] [44]. Manufacturers need to establish requirements traceability, risk management integration, configuration management, and problem resolution processes as part of development [45] [22]. 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) [46] [47] – 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, SaMD requires clinical validation. Regulators want to see that the software has clinically meaningful impact and accuracy. The clinical evaluation of SaMD, as described in IMDRF guidance adopted by FDA, involves three pillars: establishing a valid clinical association (scientific rationale linking the software output to clinical condition/outcome), analytical validation (demonstrating the software correctly processes inputs to produce accurate and reliable outputs), and clinical validation (evidence that using the software in the intended population yields clinically significant outcomes or benefits) [48] [49]. 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 [14]. 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 [50]. 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 [51] [52]. 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) [53]). 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 [54] [55]. 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.

Challenges and Considerations for SaMD Deployment

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 [56]. Standards Adoption: To overcome this, SaMD developers use standards like HL7 FHIR and DICOM, and APIs to enable compatibility [56]. 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” [57]. 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 [58]. 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 [59]. 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 US, the Consolidated Appropriations Act of 2023 (Section 524B of the FD&C Act) mandates that new device submissions include a cybersecurity plan detailing how the manufacturer will "monitor, identify, and address" cybersecurity vulnerabilities, assure their device is protected against threats, and provide regular security updates and patches [60]. FDA requires a Software Bill of Materials (SBOM) listing third-party components to help track known vulnerabilities [61]. In its 2025 premarket cybersecurity guidance, the FDA further emphasized that devices must be "secure by design," embedding threat modeling, risk assessments, and update mechanisms into development from the outset. Manufacturers should implement measures like data encryption, user authentication, secure coding practices, and penetration testing. The stakes are high – reports have shown that over half of connected medical devices in hospitals have critical vulnerabilities exploitable by hackers [62]. Such attacks could lead to corrupted readings or device behaviors (imagine an algorithm being manipulated to give false diagnoses). 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 [63] [64].
• 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, GDPR imposes strict requirements on any software processing health data – consent or other legal basis for data processing, data minimization, and robust protection measures are mandatory [65] [66]. This means SaMD developers should only collect the data absolutely needed for the intended purpose and possibly anonymize or pseudonymize data where feasible. Principles like “privacy by design and default” apply, requiring that privacy considerations are embedded from the earliest design stage [67]. For instance, default settings should not share data unless the user opts in, and features like role-based access control, encryption of data at rest and in transit, and secure user authentication are critical [68]. In the US, while there isn’t an exact GDPR equivalent, SaMD may fall under HIPAA if handling data from healthcare providers or insurers, meaning it must ensure confidentiality of identifiable health information. That may entail signing Business Associate Agreements and meeting the HIPAA Security Rule standards (access controls, audit logs, etc.). 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 [69] [70]. 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 [71]. 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.

Trends and Innovations in SaMD

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

• Rise of Digital Therapeutics: SaMD is at the core of the digital therapeutics (DTx) movement – software solutions that deliver clinical interventions directly to patients (often as treatments for chronic conditions or mental health). We’ve seen apps treating substance use disorder, ADHD, insomnia, anxiety, and more obtaining regulatory approval. These innovations turn evidence-based behavioral therapies or rehabilitation exercises into interactive software programs. Regulators have embraced this trend by creating new classifications and guidance for such products (often prescription-only apps). The appeal is significant: DTx SaMD can provide therapy access at scale, personalized to user inputs, and with real-time progress tracking. The trend is also expanding into adjunct therapies (e.g. software to improve medication adherence or provide lifestyle coaching for diabetes). Regulatory and commercial evolution: The FDA's Pre-Cert pilot program concluded in 2022, and its learnings have been folded into broader regulatory frameworks for SaMD. However, the sector has faced significant commercial headwinds: the bankruptcies of Pear Therapeutics (2023) and the fire-sale acquisition of Akili Interactive (2024) highlighted that regulatory approval alone does not guarantee commercial success – reimbursement pathways remain a critical challenge. Encouragingly, the CMS proposed new reimbursement codes for "digital mental health treatment" devices in its 2025 Medicare Physician Fee Schedule, and major insurers like Cigna and CVS Health have begun covering FDA-authorized digital treatments. In April 2025, Click Therapeutics received FDA authorization for CT-132, the first prescription digital therapeutic for episodic migraine prevention [72]. The global DTx market is valued at approximately 9.7billionin2025andprojectedtoexceed9.7 billion in 2025 and projected to exceed 9.7billionin2025andprojectedtoexceed56 billion by 2034. Digital therapeutics also spur conversation about how software updates (analogous to dose changes) are managed and how healthcare providers prescribe and monitor software 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: The FDA has cleared over 1,000 AI-based SaMD to date and maintains a publicly updated list of AI-enabled devices; 2025 saw a record 295 new AI/ML device authorizations, with radiology comprising roughly 76% of the total [73] [74]. A current frontier is adaptive AI – algorithms that continue to learn post-deployment. In December 2024, the FDA finalized its guidance on Predetermined Change Control Plans (PCCPs) for AI-enabled device software functions, allowing manufacturers to pre-specify anticipated algorithm updates in their original marketing submission and implement those changes without filing a new application, provided they follow the approved protocol [75]. Additionally, the FDA issued draft guidance in January 2025 on AI-enabled device software functions applying a Total Product Life Cycle (TPLC) approach. 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 [76]. 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 [77]. 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 [78]). 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 [79]. 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, the intersection of MDR and the AI Act is creating a new compliance landscape that will require SaMD manufacturers to navigate dual regulatory frameworks from 2027 onward. 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. [27] [80]

Sources:

1. IMDRF SaMD Working Group – Key Definitions (2013) [1] [81]
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] [82]
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) [27] [42]
7. EU MDR Annex VIII – Rule 11 for Software [19] [20]
8. HTD Health – IEC 62304 & ISO 13485 for SaMD (2023) [24] [22]
9. Orthogonal Inc. – FDA-Cleared SaMD List (2024) [29] [31]
10. FDA Press Release – reSET SUD Therapeutic (2017) [32] [33]
11. FDA De Novo Summary – EndeavorRx (DEN200026) (2020) [37]
12. FDA SaMD Examples – FDA SaMD Examples Page [83] (for context)
13. FDA Guidance – SaMD Clinical Evaluation (2017) [48]
14. Cognidox – SaMD Post-market and 510(k) Changes (2021) [50] [54]
15. Orthogonal Inc. – SaMD Interoperability Guide (2025) [57] [56]
16. HTD Health – FDA Cybersecurity Requirements (2023) [60] [62]
17. Sequenex – GDPR and SaMD Data Protection (2023) [67] [68]
18. FDA – Artificial Intelligence in SaMD (2021) [75] [84]

DISCLAIMER

The information contained in this document is provided for educational and informational purposes only. We make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability, or availability of the information contained herein. Any reliance you place on such information is strictly at your own risk. In no event will IntuitionLabs.ai or its representatives be liable for any loss or damage including without limitation, indirect or consequential loss or damage, or any loss or damage whatsoever arising from the use of information presented in this document. This document may contain content generated with the assistance of artificial intelligence technologies. AI-generated content may contain errors, omissions, or inaccuracies. Readers are advised to independently verify any critical information before acting upon it. All product names, logos, brands, trademarks, and registered trademarks mentioned in this document are the property of their respective owners. All company, product, and service names used in this document are for identification purposes only. Use of these names, logos, trademarks, and brands does not imply endorsement by the respective trademark holders. IntuitionLabs.ai is an AI software development company specializing in helping life-science companies implement and leverage artificial intelligence solutions. Founded in 2023 by Adrien Laurent and based in San Jose, California. This document does not constitute professional or legal advice. For specific guidance related to your business needs, please consult with appropriate qualified professionals.