Part 2: Navigating Class I SaMD as an AI Researcher

AI tools that are classified as SaMD are also referred to as machine learning-enabled medical devices (MLMD) by Health Canada². They may be standalone AI software as a medical device or AI that is part of a physical medical device.

Once software is considered as SaMD, Health Canada applies a risk-based framework to determine its regulatory class. The classification determines how it is regulated with Class I imposing the least requirements and Class IV the most rigorous and extensive ones.

Many AI models do not independently diagnose, treat, or drive clinical management but instead enhance clinical practice by providing informative outputs. These are strong candidates for Class I SaMD.

However, while many researchers frequently encounter Class I SaMD, it is important to recognize that a large portion of AI research centers around prediction tasks that might meaningfully guide clinical decision-making or patient management and would thereby fall into Class II rather than Class I.

What Qualifies as Class I SaMD?

Class I sits at the lowest end of Health Canada’s SaMD risk spectrum and is subject to fewer regulatory requirements, many of which can be satisfied using processes that already exist within hospitals, universities and research institutions.

To understand whether your AI is a strong candidate for Class I SaMD, you need to think through the two axes on which Health Canada bases its classification approach:

• state of healthcare situation or condition and
• significance of information provided by SaMD to inform healthcare decisions

Each of these axes has three levels, so that you get the matrix shown in Figure 1.

*Class III if an erroneous result could lead to immediate danger (Rule 10(2))

**Class II if the software is intended to image or monitor a physiological process or condition (Rule 10(1))

Class I under Rule 12     

This matrix provides a mapping to Class I to III whereby Class I is then classified under Rule 12 of the Medical Device Regulations³ which acts as the default rule for “any other active device” when no higher-risk rule applies. In principle, SaMD can also fall into Class IV (the highest-risk devices), but typically not as a standalone SaMD but rather as part of an integrated device system.

From this matrix, there are two routes through which your AI may qualify as Class I:

If your AI is intended for use in a non-serious condition, it will generally fall into Class I even if the model diagnoses, treats, or drives clinical management, as long as the context remains non-serious. The main exception is software intended to image or monitor a physiological process or condition. These functions involve real-time insights into the body’s state which makes them arguably higher risk. Health Canada notes that non-serious conditions or scenarios are characterized by factors such as predictable progression and minor therapeutic interventions. The user population is also relevant in these considerations: if the intended users are considered vulnerable, such as pediatric patients, the tool may fall into the critical scenario, regardless of the disease or condition itself.

Your AI may also be classified as Class I if it informs clinical and patient management without triggering any near-term action. It would remain Class I even in critical condition as long as it remains informative, again with the exception of physiological monitoring and imaging functions. It’s important here to distinguish informing management from driving management. For example, an AI summarization model can be considered informing while a prediction model that identifies early signs of disease prompting diagnostic escalation is rather driving a clinical decision.

A lot of AI that is being developed can be considered as predictive models deployed with a human in the loop. It is important to highlight that human oversight by itself does not determine whether software is “informing” versus “driving”. A model may still be considered as driving clinical or patient management even if a clinician reviews the output, where the intended use is to prompt diagnostic escalation, treatment changes, or other near-term actions. Conversely, software can be considered informative where outputs are presented as contextual information that clinicians may interpret alongside other data without being positioned as a trigger for action.

A critical point that may be underestimated in research settings is that SaMD classification is driven by the intended use as communicated or documented, not solely by what the AI is technically capable of. The same algorithm may fall into Class I or Class II depending on the intended use within the clinical workflow.

A Practical Example: Making the Classification Framework Concrete

Regulatory concepts can feel abstract at first, so let’s make this more tangible by walking through a simple, realistic example. This will help you see how Health Canada’s classification matrix applies in practice and why many AI tools fall into Class I.

Consider the following scenario: You have developed Jointly, an AI tool that analyzes short video clips of a patient performing knee flexion and extension exercises. The software automatically extracts key points, measures joint angles, and generates a summary of the patient’s range of motion over time. The output is presented to the clinician as a set of measurements and visualizations. Jointly is intended to be used in outpatient rehabilitation whereby a physiotherapist records the patient performing the movement and the AI generated summary of the patient’s range is presented to the clinician.

Under Health Canada’s framework, Jointly is a strong candidate for Class I SaMD and it even fits into both routes: the scenario (outpatient rehabilitation) would typically be considered as non-serious, and the outputs can be seen as purely informative without recommendations for treatment or diagnosis. It is also not real-time monitoring of a physiological process.

Understanding the Requirements for Class I

Once you’ve determined that your AI tool qualifies as Class I SaMD, the natural question is: what happens next? Even though Class I sits at the lowest end of the SaMD risk spectrum, it is still regulated under Canada’s Medical Device Regulations³. However, the good news is that these requirements are, as previously mentioned, fewer and can typically be satisfied using processes that already exist within hospitals, universities and research institutions.

Under Health Canada’s regulatory framework, Class I SaMD does not require a pre-market device license or submission. There is no formal mechanism by which Health Canada confirms or approves a Class I classification in advance. Classification is self-determined and, in practice, adequacy is ensured through clear documentation of alignment with the SaMD classification framework and corresponding obligations and record maintenance to support clarification in the event of audit or inspection.

One of the key regulatory obligations is proper labeling⁴. In the context of software, “labeling” goes far beyond a physical label on a device: it includes the intended use statement, instructions for use, on-screen information, accompanying documentation, and any materials provided to the user. With that in mind, the following table summarizes the labeling elements as provided in the Section 21(1)(a)–(j) of the Guidance for the Labelling of Medical Devices⁴ and puts them in the SaMD context. It is important to note that recognize that these provisions were drafted with physical medical devices in mind.

The intended use statement is a highly relevant part of SaMD labeling because this is effectively where you describe how the software should be used and, consequently, the class it falls into. Alongside a description of the SaMD’s core functionality, it should specify the intended users, medical purpose, target population, clinical context, functionalities, contraindications, any known limitations and any further factors that determine classification (see details in [1,2]).

While the concept content description does not map to SaMD, the pre-market guidance for MLMD highlights the relevance of a detailed description of the AI tool including underlying training algorithms and architectures as well as data selection and management (with more information in [2]). This guidance also introduces the idea of a predetermined change control plan (PCCP). A PCCP defines changes or updates to the software a priori and would, for example, include any modifications required due to data drift over time. The idea is to manage known risks in AI tools in a timely and ongoing manner.

Risks in AI may be different than in traditional physical medical devices and can include hallucinated outputs, biases, over-/underfitting, data shift/drift, automation bias or alarm fatigue.² The manufacturer of a Class I SaMD must have basic processes in place to ensure safety throughout the device’s lifecycle.

What’s Next

While Class I devices do not require a pre-market device license or submission, they may require a Medical Device Establishment License (MDEL).

Whether or not this applies to you depends on how and where your AI will be deployed. In the next blogpost, we will walk through the considerations around MDEL, explain why starting with the MDEL is often the most strategic move for research teams and share some practical experiences from a team who has gone through the process.

Read Part 1 in the series: Translational Medical AI: From AI Research to Real-World Deployment as SaMD

Acknowledgements

• Shafiq Qaadri, JD Candidate, Lincoln Alexander School of Law
• Vanessa Gruben, Director, University of Ottawa Centre for Health Law, Policy and Ethics

References

1. Health Canada. Guidance Document: Software as a Medical Device (SaMD): Definition and Classification. 2019.
2. Health Canada. Pre-market guidance for machine learning-enabled medical devices. 2025.
3. Medical Devices Regulations (SOR/98-282). 1998.
4. Health Canada. Guidance for the Labelling of Medical Devices, not including  in vitro diagnostic devices. 2015.