Guidance Document: Software as a Medical Device (SaMD): Classification Examples

Date adopted: 2019/10/03
Effective date: 2019/12/18

Foreword

Guidance documents are meant to provide assistance to industry and health care professionals on how to comply with governing statutes and regulations. Guidance documents also provide assistance to staff on how Health Canada mandates and objectives should be implemented in a manner that is fair, consistent and effective.

Guidance documents are administrative instruments not having force of law and, as such, allow for flexibility in approach. Alternate approaches to the principles and practices described in this document may be acceptable provided they are supported by adequate justification. Alternate approaches should be discussed in advance with the relevant program area to avoid the possible finding that applicable statutory or regulatory requirements have not been met.

As a corollary to the above, it is equally important to note that Health Canada reserves the right to request information or material, or define conditions not specifically described in this document, in order to allow the Department to adequately assess the safety, efficacy or quality of a therapeutic product. Health Canada is committed to ensuring that such requests are justifiable and that decisions are clearly documented.

This document should be read in conjunction with the accompanying notice and the relevant sections of other applicable Guidance documents.

Table of Contents

1. Introduction

This document is intended to be read in conjunction with the Guidance Document - Software as a Medical Device (SaMD): Definition and Classification.

Due to the fast-changing technological environment, Health Canada will continue to adapt its policy approach to SaMD as the field evolves. This guidance document will be updated periodically to reflect the current SaMD landscape.

2. Classification Process for SaMD

Health Canada recognizes that classification can be challenging. When classifying your device, consider the following steps:

2.1 Perform the classification assessment

  1. Verify that the software meets the definition of “device” per section 2 of the Food and Drugs Act and “medical device” per section 1 of the Medical Devices Regulations
  2. Ensure your intended use statement reflects the principles outlined in section 2.3.1 of the Guidance Document – Software as a Medical Device (SaMD): Definition and Classification as well as section 2.2, item 7 of the Guidance Document – How to Complete the Application for a New Medical Device Licence
  3. Use the intended use statement and product labelling (e.g. instructions for use/user manual, marketing materials, website) to verify that the software meets the SaMD inclusion criteria found in section 2.1 of the Guidance Document – Software as a Medical Device (SaMD): Definition and Classification. Then, determine if the software fulfills all four SaMD exclusion criteria listed in section 2.2 of the aforementioned document. If the software meets all four exclusion criteria, the software is not subject to the Medical Devices Regulations.
  4. Classify the software
  5. Compare your classification to:
    • Classification examples listed in section 4 of this document;
    • Classification of  similar products (the Medical Devices Active Licence Listing (MDALL) database is a comprehensive listing of all licensed Class II, III, and IV medical devices); and
    •  Any prior Canadian classifications for the product, including any relevant previous correspondence with Health Canada.
  6. Save your classification assessment and rationale in your company records. To help facilitate the licensing process, your own classification assessment should also be included in the cover letter of your licence application.

2.2 Review the classification assessment

3. Classification Example Walkthroughs

The following examples illustrate how the classification process described in section 2 applies to SaMD.

Example 1: Software that provides patients with simple tools to organize and track their health information. The information is intended to be shared with a healthcare provider as part of a pre-diabetes management plan.

Exclusion criteria Is the exclusion criteria met? Rationale
Software that is not intended to acquire, process, or analyze a medical image or a signal from an IVDD or a pattern/signal from a signal acquisition system. Yes The software does not acquire nor process a signal from an IVDD or a monitoring device. The user manually inputs their health data into the software.
Software that is intended to display, analyze, or print medical information about a patient or other medical information (such as demographic information, drug labelling, clinical guidelines, studies, or recommendations). Yes The software displays the patient’s information.
Software that is only intended to support a health care professional, patient or non healthcare professional caregiver in making decisions about prevention, diagnosis, or treatment of a disease or condition. Yes The software does not provide any information regarding the prevention, diagnosis, or treatment of a disease or condition.
Software that is not intended to replace the clinical judgement of a health care professional to make a clinical diagnosis or treatment decision regarding an individual patient. Yes The software does not provide any information regarding the prevention, diagnosis, or treatment of a disease or condition.

Conclusion: Therefore, the software is not a medical device.

Example 2: Software that provides patients with simple tools to organize and track their health information. The health information is then analyzed by the software using a novel algorithm to predict risk of diabetes.  The information is intended to be shared with a healthcare provider (HCP) to provide a diagnostic output the HCP would otherwise not have access to. The information is also intended to support development of a management plan.

Exclusion criteria Is the exclusion criteria met? Rationale
Software that is not intended to acquire, process, or analyze a medical image or a signal from an IVDD or a pattern/signal from a signal acquisition system. Yes The software does not acquire nor process a signal from an IVDD or a monitoring device. The user manually inputs their health data into the software.
Software that is intended to display, analyze, or print medical information about a patient or other medical information (such as demographic information, drug labelling, clinical guidelines, studies, or recommendations). Yes The software displays the patient’s information.
Software that is only intended to support a health care professional, patient or non healthcare professional caregiver in making decisions about prevention, diagnosis, or treatment of a disease or condition. No The software provides a diagnostic output that the health care professional would otherwise not have access to.
Software that is not intended to replace the clinical judgement of a health care professional to make a clinical diagnosis or treatment decision regarding an individual patient. Yes The software only predicts risk and does not make a clinical diagnosis or treatment decision.
State of healthcare situation or condition Significance of information provided by SaMD to healthcare decision
Treat or diagnose Drive Inform
Critical III III I or II
Serious II or III II or III I or II
Non-serious I or II I or II I or II

Conclusion: An erroneous result would not lead to immediate danger. Therefore, Class II is appropriate. Refer to section 2.3.2 of the Guidance Document – Software as a Medical Device (SaMD): Definition and Classification for additional information regarding the interpretation of “immediate danger.”

Example 3: Software that provides a diabetic patient with simple tools to organize and track their health information. The healthcare professional can input medical information for diabetes-related conditions such as kidney and eye function as well as drug dosage. The software also obtains data from a closed-loop blood glucose monitor. The software analyzes the information collected to provide early diagnosis of a diabetic emergency. When a patient experiences a diabetic emergency, the software will alert the healthcare professional and use the analyzed information to make treatment decisions based on the patient’s unique health profile.

Exclusion criteria Is the exclusion criteria met? Rationale
Software that is not intended to acquire, process, or analyze a medical image or a signal from an IVDD or a pattern/signal from a signal acquisition system. No The software receives information from a closed-loop blood glucose monitor.
Software that is intended to display, analyze, or print medical information about a patient or other medical information (such as demographic information, drug labelling, clinical guidelines, studies, or recommendations). Yes The software displays the patient’s information.
Software that is only intended to support a health care professional, patient or non healthcare professional caregiver in making decisions about prevention, diagnosis, or treatment of a disease or condition. No The software is intended to be used to diagnose a diabetic emergency.
Software that is not intended to replace the clinical judgement of a health care professional to make a clinical diagnosis or treatment decision regarding an individual patient. No The software provides patient-specific treatment recommendations that would otherwise not be available to the health care professional, and changes the way the health care professional would render a diagnosis of diabetic emergency or make a treatment decision.
State of healthcare situation or condition Significance of information provided by SaMD to healthcare decision
Treat or diagnose Drive Inform
Critical III III I or II
Serious II or III II or III I or II
Non-serious I or II I or II I or II

Conclusion: An erroneous result would lead to immediate danger. Therefore, Class III is appropriate. Refer to section 2.3.2 of the Guidance Document – Software as a Medical Device (SaMD): Definition and Classification for additional information regarding the interpretation of “immediate danger.”

4. Additional Examples

4.1 Non-IVDD SaMD

4.1.1 Examples of Class I non-IVDD SaMD

4.1.2 Examples of Class II non-IVDD SaMD

4.1.3 Examples of Class III non-IVDD SaMD

4.2 IVDD SaMD

Note: Refer to section 2.3.3 of the Guidance Document – Software as a Medical Device (SaMD): Definition and Classification as well as the Guidance Document: Guidance for the Risk-based Classification System for In Vitro Diagnostic Devices (IVDDs) for additional guidance.

4.2.1 Examples of Class III IVDD SaMD

4.3 Software that is not subject to the Regulations

It is Health Canada's current position that the software examples below do not meet the definition of a device as outlined in the Food and Drugs Act and therefore, are not subject to the Medical Devices Regulations:

Report a problem or mistake on this page
Please select all that apply:

Thank you for your help!

You will not receive a reply. For enquiries, contact us.

Date modified: