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

Date adopted: 2019-10-03
Effective date: 2019-12-18
Revised date: 2022-11-15

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
• 2. Classification Process for SaMD
  • 2.1 Perform the classification assessment
  • 2.2 Review the classification assessment
• 3. Classification Example Walkthroughs
• 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
    • 4.2.1 Examples of Class III IVDD SaMD
  • 4.3 Software that is not subject to the Regulations

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
   • Non-in vitro diagnostic device (non-IVDD):
     • Use Table 2 of the Guidance Document - Software as a Medical Device (SaMD): Definition and Classification
       • Determine the significance of the information provided by the SaMD to the healthcare decision
       • Determine the state of the healthcare situation or condition that the SaMD is intended for
   • In vitro diagnostic device (IVDD):
     • Use section 2.3.3 of the Guidance Document - Software as a Medical Device (SaMD): Definition and Classification and the Guidance Document - Guidance for the Risk-based Classification System for In Vitro Diagnostic Devices (IVDDs)
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

• It is the role and onus of the manufacturer to determine the appropriate classification for their device.
• When a classification is unique and complex, Health Canada can assess the manufacturer's classification to verify its accuracy. In the event of a discrepancy between the manufacturer and Health Canada regarding the product or risk classification of a medical device, Health Canada reserves the right for the final decision. The manufacturer, however, may request a reconsideration of this classification.
• Classification verification requests must contain all of the elements listed above. Requests can be sent to meddevices-instrumentsmed@hc-sc.gc.ca
• To facilitate the licensing process, copies of communications with Health Canada regarding relevant classification advice and decisions should be included in the previous correspondence folder of your licence application.

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.

• Does the software meet the SaMD inclusion criteria?
  • No; the software is not intended for a medical purpose as outlined in the definition of device in the Food and Drugs Act:
    • The software is not intended for diagnosing, treating, mitigating or preventing a disease.
    • The software does not restore, modify, or correct body structure or functioning.
    • The software does not diagnose pregnancy, is not intended for use during pregnancy or after birth, and the software does not prevent conception.
• Does the software meet the SaMD exclusion criteria?

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.

• Does the software meet the SaMD inclusion criteria?
  • Yes; the software is intended to support diagnosis of a disease.
• Does the software meet the SaMD exclusion criteria?

• What is the significance of the information provided by the SaMD to the healthcare decision?
  • The information provided by the SaMD will be used to aid in diagnosis since the SaMD provides a diagnostic output that the healthcare professional would not otherwise have access to. Therefore, the software is driving clinical/patient management.
• What is the state of the healthcare situation or condition that the SaMD is intended for?
  • An accurate pre-diabetes diagnosis is of vital importance and a timely intervention is necessary to mitigate long-term irreversible consequences to an individual’s health. Therefore, the software is intended for a serious condition.
• What is the classification assessment per Table 2?

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.

• Does the software meet the SaMD inclusion criteria?
  • Yes; the software is intended to analyze measurements from a monitoring device and is intended to provide recommendations to healthcare professionals about treatment or mitigation of diabetes.
• Does the software meet the SaMD exclusion criteria?

• What is the significance of the information provided by the SaMD to the healthcare decision?
  • The information provided by the SaMD is intended to be used to diagnose a diabetic emergency and make treatment decisions. Therefore, the software is treating and diagnosing.
• What is the state of the healthcare situation or condition that the SaMD is intended for?
  • An accurate diagnosis of diabetic emergency is vital to avoid death, long-term disability or other serious deterioration of health of a patient. Therefore, the software is intended for a critical situation.
• What is the classification assessment per Table 2?

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

• Software that is intended for use in rehabilitation and active range of motion assessment. This software analyzes images from cameras to generate objective measurements of joint mobility and posture. The data generated by the software is intended to function as a clinical aid in the assessment and rehabilitation of joint dysfunction and posture imbalance.

4.1.2 Examples of Class II non-IVDD SaMD

• Software that acquires patient data, such as blood pressure, heart rate, and weight from connected medical devices and displays them to a healthcare professional for remote patient monitoring. The software provides real-time feedback based on measured signals and generate alerts for the clinician if the signals are outside an established range.
• Software that manipulates or analyzes images and other data obtained from a radiation emitting imaging device (e.g., computed tomography, bone densitometer) to create three-dimensional models of the region intended to be used in planning orthopedic/dental surgical treatments with a device.
• Software intended for health care professionals that uses an algorithm to analyze patient information, such as blood pressure, heart rate, weight, and age to determine which treatment plan is likely to be most effective in treating the patient's condition.  These patient-specific treatment recommendations would otherwise not be available to the health care professional. The healthcare professional cannot independently review the calculations made by the algorithm.
• Software that analyzes previously recorded physiological signals from adult patients to stage sleep, detect arousals, and measure snoring. This allows a physician to assess sleep quality to identify patients with obstructive sleep apnea.
• Software that leverages the use of a smartphone otoscope attachment and the smartphone camera to perform an ear exam by capturing a video of the inside of a child's ear to support a clinical diagnosis. The software serves as the interface that launches the camera, controls the acquisition of an image, performs storage and sharing functions, and may or may not have analytical functionality.
• Mobile app intended for people with tinnitus and a compatible hearing aid. The app is intended to be used as a sound therapy tool in a tinnitus treatment program that is prescribed by a hearing healthcare professional.
• Software that calculates percent breast density from the same digital mammograms that radiologists view in breast screening exams to aid in the assessment of breast tissue composition. The software is intended for the evaluation of individual breast cancer risk and to aid in making decisions about any additional screening modalities that might be beneficial for further assessments.
• Breast imaging software intended for use with a digital mammography system. The software displays images from multiple modalities, including X-ray, ultrasound and magnetic resonance imaging. The software allows selection, display, manipulation, quantification (i.e. measurements such as area and distance within a region of interest), annotation, printing, and Digital Imaging and Communications in Medicine (DICOM) image transfer. Following review of the images by a primary radiologist, the software analyzes digital mammography images and identify regions of interest, such as microcalcification clusters and density masses, which may warrant further review.
• Mobile app that acts as a digital scoliometer to diagnose scoliosis and monitor disease progression. The software leverages information from a cell phone accelerometer and scales up the measurements.  
• Software that uses artificial intelligence to tailor mental health treatment plans, including medication dosing, based on patient-derived signals. The software also calculates the probability of remission for a given treatment plan. The software is intended for use in the clinician's office during a routine appointment.
  • Note: if the software was intended for use in-hospital for patients experiencing an acute psychiatric event, the healthcare condition would be considered to be critical and the software would be Class III SaMD.

4.1.3 Examples of Class III non-IVDD SaMD

• Software that performs diagnostic image analysis for making treatment decisions in patients with acute stroke. This analysis is performed by the software and returns a stroke score metric to the healthcare provider.
• Software that receives information from an implantable device and allows the user to monitor their condition. The software sends alerts to a healthcare professional if the readings indicate that immediate intervention is needed. Erroneous readings or a missed alert could lead to death, long-term disability, or other serious deterioration of health of an individual patient.
• Radiation treatment planning software that accepts patient images, allows for a healthcare professional to identify and delineate tumours, healthy tissues, and critical organs, calculates a complex plan for how the therapy system will deliver radiation, and then serves as input for medical linear accelerators in the treatment of cancer.   

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

• A software app that reads near-patient, in vitro diagnostic device Class III urinalysis test strips intended for screening urinary tract infections. The user takes a picture of the dipstick from a smartphone camera which is then processed by an image processing algorithm. The app analyzes the color of strips and reports the results of the different analytes tested. Since the software is intended to be used with a Class III near-patient in vitro diagnostic device, the software is a Class III device per Rule 7, Schedule 1, Part 2 of the Medical Devices Regulations.
  • Note: if the software was intended to be used in a laboratory setting to analyze Class II patient urinalysis test strips, the software would be Class II per Rule 7.
• A prenatal screening software application intended for use in clinical laboratories to analyze diagnostic assays and aid in estimating the risk of congenital abnormalities such as Down's Syndrome, Edward's Syndrome, Patau's syndrome and open Spina Bifida. Users include qualified laboratory technicians and senior laboratory personnel.
• Qualitative software intended for high resolution identification of Human Leukocyte Antigen (HLA) alleles by means of sequencing-based typing using data generated by Next Generation Sequencing to inform clinical management. This software is intended to be used for transplantation purposes and in silico diagnostic use by professional health care personnel, such as laboratory technicians and physicians, trained in HLA-typing and Deoxyribonucleic Acid (DNA) sequencing in diagnostic laboratories.

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:

• Software that provides patients with simple tools to organize and track their health information. These apps do not provide alerts or recommendations to alter or change a previously prescribed treatment or therapy.
  Examples include: apps that provide simple tools for patients with specific conditions or chronic diseases (e.g., obesity, anorexia, arthritis, diabetes, heart disease) to log, track, or trend their events or measurements (e.g., blood pressure measurements, drug intake times, diet, daily routine or emotional state) and share this information with their health care provider as part of a management plan.
• Electronic Health Record (EHR) - An application software program, and/or algorithms used as or in an information system to electronically receive, collect, store, manage, display, output, and distribute data, within or between healthcare facilities, to support the electronic registration and documentation of patient clinical data. It typically enables healthcare providers to review and update patient medical records, place orders (e.g., for medications, procedures, tests), and sometimes view multimedia data from many specialties.
  • Note: software modules within EHRs that meet the definition of a medical device are subject to regulatory oversight.
• Software that meet the definition of Medical Device Data Systems (MDDS). These are software that are intended to transfer, store, convert format, and display medical device data, without controlling or altering the functions or parameters of any connected medical device. These software include those that are used as a secondary display to a regulated medical device when these applications are not intended to provide primary diagnosis, treatment decisions, or to be used in connection with active patient monitoring.
• Chat-based triage software intended to guide users to the most appropriate form of help based on their medical symptoms. The chat-based triage software outcomes are intended to indicate to a user the next best step to take when seeking further health care, and to provide safe and appropriate clinician-vetted advice where appropriate. Triage advice outcomes include self-care, pharmacy, primary care, dental, ophthalmic, sexual health and emergent care advice outcomes.
• Software intended to be used as an annotation tool for the production of diagnostic and prognostic reports of clinical electroencephalogram (EEG) studies, based on a user's traditional visual interpretation of EEG. It is intended to standardize and structure reporting of clinical EEG according to an international academic standard. The software is also intended to reduce the workload of the reporting doctor by automatically importing minimal pieces of information from an external EEG system.
• Software that incorporates a risk calculator based on well-established, publicly available models to generate a score for obese individuals at risk of developing heart disease. This includes software applications intended to provide a convenient way for clinicians to perform various simple medical calculations routinely used in clinical practice. This software is tailored for clinical use, but retains functionality that is similar to simple general purpose tools such as paper charts, spread sheets, timers or generic mathematical calculators.
• Software that provides supplemental care by coaching or educating patients to help them manage their health. This includes software that complements professional clinical care by facilitating behavioral change or coaching patients with specific diseases or conditions in their daily environment.
  Examples include software that coaches patients with conditions such as cardiovascular disease, hypertension, diabetes or obesity, and promotes strategies for maintaining a healthy weight, getting optimal nutrition, exercising and staying fit, managing salt intake, or adhering to pre-determined medication dosing schedules by simple prompting.
• Software that serves as a medical image storage device by providing electronic storage and retrieval functions for medical devices or software that serves as a medical image communication device by providing electronic transfer of medical image data between medical devices.
• Software that calculates drug dosing based on the information provided on a drug product label.  The user manually inputs the necessary parameters (e.g., age, gender, weight) to determine the appropriate dose. The user is able to independently review the calculation.
• Software that converts paper-based mental health assessments to an electronic format. These paper-based assessments are readily available to the medical community and are routinely used in clinical practice. The type of information must be from authoritative medical sources, as recognized by the field or discipline that is the subject of the assessment, and must be cited in the software. The results can be independently reviewed by a healthcare professional.
• Clinical-Coding Information System Application Software that receives, collects, stores, manages, assists in analysis of, displays, outputs and distributes data. Healthcare facilities use the software to support the administrative and clinical activities associated with the electronic registration of patient diagnoses and procedures (used within or between facilities). This software is not considered a medical device when used to triage patients who arrive at an emergency department.