Software as a Medical Device (SaMD) has become one of the most dynamic areas of medical device regulation. For manufacturers, one of the first questions is not only whether the software is a medical device, but also how it should be classified from both a regulatory and risk management perspective.
Classification is not simply an administrative exercise. The regulatory class assigned to a software product may influence market access pathways, evidence requirements, quality management expectations, software lifecycle activities, and post-market obligations. At the same time, manufacturers must recognize that regulatory classification is only one part of a broader risk-based strategy.
This article focuses on the strategic considerations manufacturers should evaluate when developing a classification approach for software-based medical technologies.
Why Does SaMD Classification Matter?
SaMD classification is one of the first regulatory decisions that can affect the development and commercialization strategy of a software product. The classification may determine the applicable regulatory pathway, documentation requirements, quality management expectations, evidence needed to support safety and effectiveness, and the timeline to market.
For manufacturers, classification should not be treated as an isolated regulatory step. It should be connected to intended use, clinical evaluation, risk management, software lifecycle activities, cybersecurity controls, and post-market monitoring.
A common mistake is assuming that a classification in one framework automatically determines the classification in another. For example, a software safety class under IEC 62304 does not directly equal the regulatory class under FDA, COFEPRIS, INVIMA, or another jurisdictional framework. While both systems consider patient harm, they serve different purposes and should be evaluated independently.
Step 1: Define the SaMD Intended Use
Before assigning any class, manufacturers should clearly define the intended use of the software. This includes the medical purpose, the intended user, the patient population, the disease or condition involved, the software inputs, the software outputs, and how those outputs will be used.
The intended use helps determine whether the software is intended to diagnose, treat, monitor, mitigate, predict, or provide information for clinical decisions. It also helps determine whether the software output is merely informative or whether it may influence a therapeutic or diagnostic decision.
For example, software that only stores or transfers information may have a different regulatory profile than software that analyzes patient data and recommends a diagnostic or therapeutic action. Similarly, software used by a trained healthcare professional may raise different considerations than software intended for use by patients or caregivers.
The intended use also serves as the foundation for risk management activities, clinical evaluation strategies, and classification assessments.
This is also relevant in Mexico. In our Guide on the classification of Software as a Medical Device in Mexico, we explain that the intended use is fundamental to determine whether software is considered SaMD and how it may be classified by COFEPRIS.
IMDRF SaMD Categorization
The International Medical Device Regulators Forum (IMDRF) has developed a widely recognized framework that helps manufacturers understand the potential risk associated with Software as a Medical Device.
The framework evaluates two main factors:
- The significance of the information provided by the SaMD to the healthcare decision
- The state of the healthcare situation or condition
The significance of the information can generally be understood according to whether the software is intended to:
- Treat or diagnose
- Drive clinical management
- Inform clinical management
The state of the healthcare situation or condition can generally be understood as:
- Critical
- Serious
- Non-serious
| State of healthcare situation or condition | Treat or diagnose | Drive clinical management | Inform clinical management |
| Critical | Category IV | Category III | Category II |
| Serious | Category III | Category II | Category I |
| Non-serious | Category II | Category I | Category I |
Together, these two dimensions help manufacturers and regulators understand the potential impact of the software output on patient care. For example, software that provides information used to treat or diagnose a critical condition may represent a higher risk category than software that only informs clinical management for a non-serious condition. This approach helps manufacturers think beyond the software itself and assess the clinical consequences of its output.
Although IMDRF categorization does not replace local classification rules, it provides a useful framework for early risk analysis, classification rationale development, and global regulatory planning.
Regulatory Classification Is Not the Same as Software Safety Classification
Manufacturers should distinguish between at least two types of classification:
- Regulatory risk classification, which determines the applicable medical device regulatory pathway in a specific jurisdiction. (COFEPRIS, INVIMA, ANVISA etc)
- Software safety classification, which is commonly associated with software lifecycle standards such as IEC 62304.
Regulatory classification focuses on the risk posed by the medical device under the applicable laws and regulations of a jurisdiction. Software safety classification, on the other hand, is used to determine the rigor of the software development and lifecycle processes based on the possible harm that a software failure could cause.
This distinction is important because a software product may require robust software lifecycle controls even if its regulatory classification is not the highest. Conversely, regulatory classification may depend on factors such as intended medical purpose, clinical impact, and jurisdiction-specific rules, not only on software failure severity.
Risk Management and Cybersecurity Considerations for SaMD
Classification should also be connected to risk management and cybersecurity activities. Software-related risks are not limited to incorrect clinical outputs or software failures. They may also include risks associated with access control, data confidentiality, remote connectivity, network use, cloud-based systems, malware, and the release of incorrect software versions.
The following standards and guidance documents may be useful when establishing a risk-based approach for SaMD, medical device software, connected health software, and cybersecurity activities:
| Reference | Document |
| IEC 62304:2006/AMD1:2015 | Medical device software: Software life cycle processes, Amendment 1 |
| ISO 14971:2019 | Medical devices: Application of risk management to medical devices |
| ISO/TR 24971:2020 | Guidance on the application of ISO 14971 |
| IEC/TR 80002-1:2009 | Medical device software: Part 1: Guidance on the application of ISO 14971 to medical device software |
| IEC/TR 80002-2:2017 | Medical device software: Part 2: Validation of software for medical device quality systems |
| IEC 80001-1:2021 | Application of risk management for IT-networks incorporating medical devices: Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software |
| IEC/TR 80001-2-1:2012 | Application of risk management for IT-networks incorporating medical devices: Step by Step Risk Management of Medical IT-Networks; Practical Applications and Examples |
| IEC/TR 80001-2-2:2012 | Application of risk management for IT-networks incorporating medical devices: Guidance for the communication of medical device security needs, risks and controls |
| IEC 81001-5-1:2021 | Health software and health IT systems safety, effectiveness and security: Part 5-1: Security: Activities in the product life cycle |
| ISO/IEC 27005:2022 | Information security, cybersecurity and privacy protection: Guidance on managing information security risks |
| FDA guidance | Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions |
| MDCG 2019-16 | Guidance on Cybersecurity for Medical Devices |
| IMDRF | Principles and Practices of Medical Device Cybersecurity |
These references are useful because SaMD may operate in environments where safety, effectiveness, security, data protection, and network performance are connected.
In a practical risk matrix, manufacturers may need to consider scenarios such as:
- A person exploiting password weaknesses.
- Unauthorized access to patient information.
- Remote access vulnerabilities.
- Misuse of the network.
- External attacks on cloud-based systems.
- A system compromised by malware.
- The release of an incorrect software version.
These examples show why SaMD classification should be analyzed together with the software’s real operating environment, intended users, access controls, update process, cybersecurity measures, and lifecycle controls.
Practical Classification Strategy for SaMD
A practical SaMD classification strategy should include the following steps:
- Define the intended use clearly
The intended use should describe the medical purpose, target users, patient population, condition, inputs, outputs, and role in the clinical workflow. - Determine whether the software is a medical device
Not all health-related software is SaMD. Software used for administrative, educational, communication, or general wellness purposes may fall outside medical device regulation depending on its claims and functionality. - Use IMDRF concepts to support risk thinking
Assess both the significance of the software output and the severity of the condition involved. - Assess the regulatory class in each target market
Classification should be performed separately for each jurisdiction.
For detailed jurisdiction-specific considerations, see: - Integrate cybersecurity and risk management activities
Cybersecurity should be incorporated as part of the overall risk management process rather than treated as a standalone activity. - Reassess classification when the software changes
New functionalities, expanded indications, greater automation, AI features, new users, and software updates may affect the regulatory assessment.
Frequently Asked Questions (FAQ)
- What is the role of intended use in SaMD classification?
It serves as the foundation for risk management, clinical evaluation, and the classification assessment itself. Intended use defines the medical purpose, the target user, the patient population, the inputs and outputs, and whether the software is intended to diagnose, treat, monitor, mitigate, predict, or simply provide information for clinical decisions. - How does the IMDRF categorize SaMD risk?
The IMDRF framework helps assess risk by evaluating two primary factors:- The significance of the information provided by the SaMD (whether it is meant to treat/diagnose, drive clinical management, or inform clinical management).
- The state of the healthcare situation or condition (whether the condition is critical, serious, or non-serious).
Together, these dimensions help determine the potential impact of the software output on patient care.
- Is software safety classification the same as regulatory classification?
No, they serve different purposes. Regulatory classification evaluates the overall risk posed by the device under the specific laws of a jurisdiction whether software safety classification (such as IEC 62304) focuses on the potential harm a software failure could cause, which determines the rigor needed during software development and lifecycle processes. - Why is cybersecurity important for SaMD classification?
Because SaMD operates in environments where network performance, data protection, and patient safety intersect, cybersecurity vulnerabilities pose a direct risk to the software’s clinical effectiveness. Risk management must account for issues like malware, unauthorized access, and remote connectivity vulnerabilities, integrating cybersecurity protocols directly into the product’s overall lifecycle controls and regulatory planning.
Conclusion
SaMD classification is far more than assigning a regulatory class to a software product. Organizations that develop a well-documented classification strategy early in the product lifecycle are often better positioned to anticipate regulatory requirements, support global market access activities, manage software-related risks, and reduce delays during commercialization.
Most importantly, successful SaMD market entry depends not only on identifying the correct regulatory classification, but also on demonstrating a clear understanding of the clinical, technical, and cybersecurity risks associated with the software throughout its lifecycle.
If you are planning to bring SaMD or other medical technologies to the Latin American market, please contact us at [email protected].
Last updated: August 2026