What is Software as a Medical Device?

In an age where software is in every aspect of our lives, it’s no surprise that the healthcare industry has also embraced the digital revolution. One remarkable development is the emergence of Software as a Medical Device (SaMD). This transformative concept has the potential to reshape the way healthcare is delivered, monitored, and managed. Understanding how SaMD is defined, classified, and regulated across global markets is crucial for developers, manufacturers, and innovators aiming to bring compliant, safe, and effective MedTech products to market. 

How to determine if your software is SaMD?

Determining whether your software qualifies as SaMD involves understanding its intended use and function. According to the FDA, IMDRF, and the EU MDR, software must be intended for medical purposes and function independently of any hardware device. This means the software should directly contribute to patient treatment, diagnosis, or monitoring without being embedded in a medical hardware device.

What is the difference between SaMD and software in a medical device (SiMD)?

While SaMD functions independently, SiMD refers to software integral to the functioning of a hardware medical device. SiMD typically controls or powers a device, such as software that operates on a blood pressure monitor. Understanding these distinctions is crucial for regulatory compliance and product development strategies.

How is SaMD regulated globally?

Software as a Medical Device does not have a single global regulation, but is regulated by different jurisdictions (US, EU, others), often with reference to global harmonization documents from IMDRF.

SaMD regulations in the United States

In the United States, the FDA oversees SaMD through classification systems similar to those for traditional medical devices. The FDA categorizes SaMD based on risk classes and requires premarket submissions to ensure safety and efficacy.

Medical device software regulations in the European Union

The EU's approach involves the Medical Device Regulation (MDR), specifically MDCG 2019-11, which classifies medical device software. CE Marking is essential for EU market entry, reflecting compliance with these regulations.

How are global regulators addressing SaMD challenges?

The IMDRF provides a framework to harmonize SaMD regulations worldwide. This includes addressing unique challenges such as cybersecurity risks and the rapid evolution of technology.

How is SaMD classified across global regulatory markets?

Classification (risk level) drives the regulatory pathway, documentation burden, time to market, and ongoing obligations.

SaMD risk classification and “Levels of Concern” in the US

In the US, the FDA does not have a SaMD-specific classification matrix akin to IMDRF’s “levels of concern” published in the IMDRF documents; instead, it uses device Classes I-III. However, the IMDRF’s framework is referenced and helpful for pre-market thinking. For example: 

• Class I: low risk, only general controls
• Class II: moderate risk, special controls and often 510(k) with clinical data
• Class: high risk, needs PMA (premarket approval) with clinical data

Medical device software risk classification in the EU (Rule 11)

In the EU under MDR (Annex VIII, Rule 11): software classification is defined as:

• Software intended to provide information used to take decisions for diagnosis or therapy is Class IIa, unless such decision may cause:
  • Death or irreversible deterioration → Class III
  • Serious deterioration or surgical intervention → Class IIb
• Software intended to monitor physiological processes is Class IIa, except if monitoring of vital physiological parameters where variations could cause immediate danger → Class IIb
• All other software is Class I

According to a study published in the Therapeutic Innovation & Regulatory Science journal under MDR, many software entries are now Class II rather than Class I, reflecting more stringent classification. 

IMDRF’s SaMD categorization framework

The IMDRF’s “Possible Framework for Risk Categorization” (SaMD WG N12) sets out a matrix based on two axes: (1) significance of the information provided by the SaMD to the healthcare decision, and (2) state of the healthcare situation or condition (critical, serious, non-serious) that the software addresses. 

Examples:

• High significance + critical condition → highest risk category
• Lower significance + non-serious condition → lower risk category

This framework helps manufacturers and regulators align globally on how to assess SaMD risk and apply controls, and many jurisdictions reference it when designing classification schemes.

IEC 62304 and software safety classification

Although not a regulatory classification scheme per se, the international standard IEC 62304 (“Medical device software – Software life-cycle processes”) classifies software safety risks into Class A, B, and C, where:

• Class A: no injury or damage to health is possible
• Class B: possible non-serious injury
• Class C: possible death or serious injury

IEC 62304 provides the engineering orientation, while regulatory classifications mentioned above provide the compliance orientation.

Software development and compliance for SaMD

IEC 62304 – software lifecycle requirements

IEC 62304 is the de facto standard for medical device software lifecycles, including SaMD. Key points include:

• Defines software lifecycle processes: software development planning, requirements, architecture/design, implementation, verification, maintenance
• Applies to software as part of a medical device and standalone software (i.e., SaMD)

Although it is not strictly mandatory in some jurisdictions, failure to meet IEC 62304 will make it very difficult to demonstrate compliance or obtain regulatory approval.

Risk Management for SaMD (ISO 14971 & FDA guidance)

Risk management is a cornerstone for SaMD compliance.  ISO 14971 is the international standard for risk management of medical devices and applies to software as well, including SaMD. For SaMD, this includes functional risks (software errors, algorithm failures), cybersecurity risks, and data integrity. The FDA and other regulatory bodies expect manufacturers to integrate risk management throughout the product lifecycle, not just in hardware, but software changes, updates, and cyber-risks as well. 

Software validation and verification for SaMD

Validation and verification processes are critical for demonstrating that the SaMD meets its intended use and functions safely and effectively. Software verification involves rigorous activities to ensure that the SaMD correctly implements its specified requirements, encompassing procedures such as static code analysis, unit testing, integration testing, and system testing. Concurrently, software validation determines that the developed SaMD fulfills the user needs and its intended purpose within its operational environment, typically involving user acceptance testing, performance testing, and, where applicable, clinical evaluations. These comprehensive processes are indispensable for establishing the software's reliability, mitigating potential risks associated with malfunctions, and ensuring adherence to stringent regulatory standards, thereby safeguarding patient safety and guaranteeing clinical efficacy. 

Key supporting standards

In addition to IEC 62304, related standards such as the IEC 82304-1 and IEC 62366-1 play important complementary roles.

IEC 82304-1, Health Software – General Requirements for Product Safety, extends beyond IEC 62304 by addressing the overall safety and performance of health software products, including standalone software not necessarily classified as a medical device. It focuses on product-level aspects such as safety labeling, instructions for use, product validation, and lifecycle maintenance. For MedTech developers, adherence to IEC 82304-1 ensures that the software not only meets the technical lifecycle and risk management requirements outlined in IEC 62304 but also achieves a high standard of product safety, reliability, and usability from a system perspective.

Similarly, IEC 62366-1, Application of Usability Engineering to Medical Devices, emphasizes the integration of usability engineering into the development process to minimize use errors and enhance the safety and effectiveness of user interactions. This standard ensures that human factors and interface design considerations are embedded throughout the software development lifecycle, from requirements definition through design verification and validation. By aligning with IEC 62366-1, developers can systematically reduce user-related risks and promote intuitive and safe operation of SaMD in clinical and real-world environments.

Together, IEC 62304, IEC 82304-1, and IEC 62366-1 provide a comprehensive and harmonized framework for the development, validation, and maintenance of safe, effective, and user-centered medical device software. Adherence to these standards not only supports regulatory compliance under frameworks such as the EU MDR and FDA guidelines but also reinforces overall quality, risk management, and patient safety objectives throughout the software lifecycle.

Cybersecurity in SaMD: regulations, guidance, and best practices

Because SaMD is increasingly network-connected, cloud-based, or reliant on third-party libraries, cybersecurity is a core regulatory expectation. The FDA’s  page on cybersecurity states that “medical devices are increasingly connected to the internet, hospital networks, and other medical devices...these same features also increase potential cybersecurity risks." 

Key guidance

• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (FDA)
• Postmarket Management of Cybersecurity in Medical Devices (FDA)
• For networked devices with off-the-shelf software, FDA guidance “Information for Healthcare Organizations about FDA's Guidance for Industry: Cybersecurity for Networked Medical Devices Containing Off-the-Shelf Software” remains relevant.

Best practices for SaMD cybersecurity

• Perform a software bill of materials (SBOM) for external libraries/components and manage vulnerabilities.
• Embed cybersecurity risk assessment into your risk management (ISO 14971) process.
• Provide evidence of secure software development lifecycle (e.g., threat modeling, penetration testing).
• Ensure you have a documented procedure for post-market monitoring and patch management.
• Link cybersecurity controls to your QMS (e.g., ISO 13485) and software processes (IEC 62304).
• For cloud/connected SaMD, ensure secure communication, authentication, encryption, and integrity of data.

Overall, cybersecurity moves from being a nice-to-have to a must-have in SaMD regulatory submissions and post-market surveillance.

The importance of cybersecurity in the MedTech industry

Learn more about how the Omnibus Bill affects MedTech OEMs

Read Now

Postmarket surveillance and compliance for SaMD?

The regulatory journey does not end at market launch. Post-market oversight, change management, and updates are key, especially for SaMD. 

When does a SaMD require a new submission?

Changes in SaMD that impact safety or intended use may necessitate new regulatory submissions. It is crucial to understand the criteria for when these submissions are required to maintain compliance.

The FDA indicates that software modifications may need a premarket review, “depending on the significance of the change relative to the level of risk posed to patients”.

Artificial intelligence and machine learning in SaMD

AI and machine learning introduce new dimensions to SaMD, requiring careful consideration of regulatory implications and potential impacts on device performance.

The future of SaMD regulations and compliance

The regulatory landscape for Software as a Medical Device is rapidly advancing to keep pace with MedTech innovation. Regulators across the globe are moving toward greater international harmonization, guided by the work of the IMDRF. 

At the same time, regulators are shifting focus from static, one-time approvals to the continuous lifecycle management of software. There is growing emphasis on handling frequent updates, monitoring real-world performance, and managing algorithmic evolution — particularly for AI- and ML-enabled SaMD. The FDA’s Section 524B, “Ensuring Cybersecurity of Devices,” effective since March 2023, reinforces the need for stronger cybersecurity and supply chain transparency. Similarly, in Europe, the upcoming EU Artificial Intelligence Act will likely impose dual compliance obligations on AI-driven medical software, layering additional requirements onto existing MDR expectations.

Looking ahead, SaMD manufacturers can expect more detailed global guidance on change protocols, cybersecurity incident reporting (including Software Bills of Materials – SBOMs), and potentially streamlined approval pathways for lower-risk software with robust postmarket monitoring. The future of SaMD regulation will demand not only solid premarket processes but also ongoing lifecycle governance, cybersecurity resilience, and strategic alignment with global regulatory frameworks to maintain compliance in an ever-evolving digital health ecosystem. 

How PTC can help your team achieve traceability and validation

PTC’s Codebeamer Technology provides an integrated platform for managing the full lifecycle of SaMD, ensuring compliance with standards, such as IEC 62304, ISO 1348, and FDA 21 CFR Part 820. It enables end-to-end traceability by linking user needs, requirements, design elements, risks, code artifacts, and test cases in a single environment. This traceability is dynamically maintained, allowing teams to easily perform impact analysis and automatically generate audit-ready reports and traceability matrices that demonstrate compliance throughout development and validation.

Codebeamer also streamlines verification and validation by offering configurable workflows for test planning, execution, and reporting, with full integration into popular CI/CD and testing pools. Test results automatically update relationships, ensuring every requirement and risk control is verified and validated. Codebeamer includes electronic signature and audit trail functionality compliant with 21 CFR Part 11, providing a secure, transport record of all development and approval activities. 

Additionally, Codebeamer integrates risk and quality management directly into the development process, supporting ISO 14971-compliant risk assessment, FMEAs, and mitigation tracking. When connected with PTC’s Windchill and DevOps tools like Git or Jenkins, it creates a unified intelligent product lifecycle that spans hardware, software, and system-level artifacts. This connected environment not only simplifies regulatory compliance and audit preparation but also enhances collaboration, visibility, and confidence in the safety and effectiveness of SaMD.

Streamline your SaMD development

PTC’s ALM solutions offer systematic support for traceability and validation.

Learn More