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

thumbnail

Download the alternative format
(PDF format, 269 KB, 16 pages)

Organization: Health Canada

Published: 2019-12-18

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.

Table of Contents

1. Introduction

The Medical Devices Regulations (the Regulations) have been established under the authority of the Food and Drugs Act (the Act) and apply to all medical devices imported or sold in Canada. The Regulations set out the requirements governing the sale, importation, and advertisement of medical devices in Canada.

The Regulations utilize a risk-based approach to regulating products within its scope. The information and documentation required to support a medical device licence application is proportional to the risk of the device, which is determined by applying the Classification Rules for Medical Devices detailed in Schedule 1 of the Regulations. As per section 6 of the Regulations, medical devices are classified into one of four classes where Class I represents the lowest risk and Class IV the highest.

Due to the fast-changing technological environment, Health Canada will continue to adapt its policy approach to Software as a Medical Device (SaMD) as this field evolves. This guidance document therefore represents the first phase of SaMD policy in Canada.

This document should be read in conjunction with the document titled, Software as a Medical Device (SaMD): Classification Examples.

1.1 Policy objectives

This document is intended to clarify how SaMD fits into Health Canada's regulatory framework for medical devices, based on current interpretation of the definitions of “device” and “medical device” in the Act and Regulations.

1.2 Policy statements

Software plays an important role in the healthcare sector. The functionality of any software product, and the manner in which it is represented or labeled for use, dictates whether it qualifies as a medical device under Health Canada's Regulations.

When the intended or represented use of software is for one or more of the medical purposes set out in the definition of a device as stated in the Act, that software qualifies as a medical device. The regulatory classification of SaMD is dependent on the manufacturer's labeled intended use for the product and the applicable Classification Rules in Schedule 1 of the Regulations.

The classification of each software function must be considered when determining the risk classification of the complete software product. SaMD that is intended to be used across multiple healthcare situations or conditions will be classified at the highest classification as per section 7 of the Regulations.

In the event of a discrepancy between the manufacturer and Health Canada regarding the product classification or risk classification of a medical device, the final decision rests with Health Canada. The manufacturer, however, may request a reconsideration of this classification.

SaMD that is capable of running on commercial off-the-shelf computing platforms (e.g., applications on mobile phones, tablets, personal computers, etc.) may be used in combination with other products including medical devices as a module or subcomponent. It may also be interfaced with other medical devices, including hardware medical devices and other SaMD software, as well as general purpose software.

Currently, Health Canada will only be regulating software that is sold within the meaning of the Act, which generally requires the transfer of ownership of a device from one party to another. For example, this would include the downloading of software from an online store to a mobile device and similar transactions.

1.3 Scope and application

This document is intended for medical device manufacturers, importers, distributors, health care professionals, and all other stakeholders who need assistance in understanding which products qualify as SaMD, as well as how SaMD is classified as per Schedule 1 of the Regulations. Software does not meet the definition of SaMD if its intended purpose is to drive a hardware medical device.

Software developers producing a SaMD under their own name or trademark are considered to be a manufacturer under the Regulations.

The term “patients” in the context of this guidance document, includes users not under the care of a healthcare professional.

1.4 Definitions

Medical Device (Medical Devices Regulations):

means a device within the meaning of the Food and Drugs Act, but does not include any device that is intended for use in relation to animals.

Device (Food and Drugs Act)

means an instrument, apparatus, contrivance or other similar article, or an in vitro reagent, including a component, part or accessory of any of them, that is manufactured, sold or represented for use in

  1. diagnosing, treating, mitigating or preventing a disease, disorder or abnormal physical state, or any of their symptoms, in human beings or animals,
  2. restoring, modifying or correcting the body structure of human beings or animals or the functioning of any part of the bodies of human beings or animals,
  3. diagnosing pregnancy in human beings or animals,
  4. caring for human beings or animals during pregnancy or at or after the birth of the offspring, including caring for the offspring, or
  5. preventing conception in human beings or animals;

however, it does not include an instrument, apparatus, contrivance or article, or a component, part or accessory of any of them, that does any of the actions referred to in paragraphs a) to e) solely by pharmacological, immunological or metabolic means or solely by chemical means in or on the body of a human being or animal.

Software as a Medical Device (SaMD)Footnote 1

The term “Software as a Medical Device” (SaMD) is defined as software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.

Notes:

  • SaMD is a medical device and includes in-vitro diagnostic (IVD) medical devices,
  • SaMD is capable of running on general purpose (non-medical purpose) computing platforms,
  • “without being part of” means software not necessary for a hardware medical device to achieve its intended medical purpose,
  • Software does not meet the definition of SaMD if its intended purpose is to drive a hardware medical device,
  • SaMD may be used in combination (e.g., as a module) with other products including medical devices,
  • SaMD may be interfaced with other medical devices, including hardware medical devices and other SaMD software, as well as general purpose software,
  • Mobile apps that meet the definition above are considered SaMD.
Medical Device Data System

Medical Device Data Systems (MDDS) are hardware or software products that transfer, store, convert formats, and display medical device data. An MDDS does not modify the data or modify the display of the data, and it does not by itself control the functions or parameters of any other medical device.

2. Guidance for implementation

2.1 What is Software as a Medical Device (SaMD) - inclusion criteria

Health Canada uses the definition developed by the International Medical Device Regulators Forum (IMDRF) as provided in section 1.4 above to help determine whether software is a medical device.

Health Canada considers that software is a medical device when:

  1. It is intended to be used for one or more medical purposes as outlined in the definition of device in the Act, and
  2. It performs these purposes without being part of a hardware medical device (i.e., it is not necessary for a hardware medical device to achieve its intended medical purpose).

The interpretation of the intended use is a key consideration in the determination of SaMD. The medical purposes described in the device definition of the Act are generic and can be interpreted in several ways. In the context of determining whether or not software is a medical device, Health Canada generally interprets medical purposes as follows:

  • Intended to acquire, process, or analyze a medical image, or a signal from an in vitro diagnostic device or a pattern/signal from a signal acquisition systemFootnote 2 or imaging device,
    OR
  • Intended for the purpose of supporting or providing recommendations to health care professionals, patients or non-healthcare professional caregivers about prevention, diagnosis, treatment, or mitigation of a disease or condition.

Software that fits the above criteria can be broadly categorized under the terms Clinical Decision Support Software (CDS) and Patient Decision Support Software (PDS). CDS software (intended for Health Care Providers (HCP)), and PDS software (intended for patients and caregivers who are not HCPs) can encompass a wide spectrum of software functionalities. Some CDS/PDS products are regulated as medical devices under the Regulations if they are intended to be used for medical purposes as defined above. This includes technologies that provide prognostic and predictive information. Others may not be subject to the Regulations if they meet the exclusion criteria outlined in Section 2.2.

SaMD that is capable of running on commercial off-the-shelf computing platforms (e.g., applications on mobile phones, tablets, personal computers, etc.) may be used in combination with other products including medical devices as a module or subcomponent. It may also be interfaced with other medical devices, including hardware medical devices and other SaMD software, as well as general purpose software.

Examples of CDS and PDS that are SaMDs are provided on the Health Canada Website.

2.2 Exclusion criteria

The medical purposes described in the device definition of the Act can apply to a wide range of products. However, software that does not have a direct impact on the diagnosis, treatment, or management of an individual's disease, disorder, abnormal physical state or symptoms would not be subject to the Regulations (e.g. a mobile app intended to monitor daily calorie intake and energy expenditure to allow an individual to self-manage their weight).

It has been Health Canada's longstanding position that the following types of software do not meet the definition of a medical device and are therefore not subject to the Regulations:

  • Software intended for administrative support of a healthcare facility,
  • Software that enables clinical communication and workflow including patient registration, scheduling visits, voice calling, video calling,
  • Software intended for maintaining or encouraging a healthy lifestyle, such as general wellness apps, and
  • Software intended to serve as electronic patient records or tools to allow a patient to access their personal health information.

In efforts to align regulatory processes for SaMD with other international jurisdictions, Health Canada has determined that various types of clinical decision support/patient decision support software may not meet the device definition - and therefore would not be subject to the Regulations - when it meets all of the four criteriaFootnote 3 outlined below:

Table 1: Software exclusion
Please note: software must meet all the following four criteria in order to be excluded.
Exclusion Criteria Clarification

1

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 systemFootnote 2.

  • Software that acquires images and data from medical devices solely for the purpose of display, storage, transfer or format conversion is commonly referred to as Medical Device Data Systems (MDDS) software, which does not qualify as a medical device.
  • Information from in vitro diagnostic devices (IVDDs) includes qualitative and quantitative outputs and signals from instruments, tests and assays.

2

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).

  • Software that matches medical information to reference information routinely used in clinical practice or self-care would meet this criterion. This could include software that matches patient symptoms and test results with best practice treatment guidelines for common illnesses.
  • Software that provides a reference for health care professionals to identify possible drug interactions in order to prevent adverse drug events could be interpreted to prevent an abnormal physical state as per the medical device definition. However, Health Canada does not intend to regulate this type of software since the alert provided by the software functions as a convenient mechanism for health care professionals to match patient-specific information with reference information that is readily available to the medical community and routinely used in clinical practice.

3

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.

  • Generally, software intended to inform clinical/patient management can be interpreted to fit this criterion. Informing clinical/patient management infers that the information provided by the software will not trigger an immediate or near term action.
  • Software that is used to treat, diagnose or drive clinical management does not generally fit under this criterion. Treatment or diagnosis infers that the information provided by the SaMD will be used to take an immediate or near term action.

4

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.

  • The intended user should have access to the basis for the software's recommendation, so the user can independently review and rely on their own judgement and reach a recommendation without primarily relying on the software function. For example, software intended to provide a convenient way to perform various simple medical calculations, which are routinely used in clinical practice, would meet the fourth criterion as the software retains functionality that is similar to simple general purpose tools such as paper charts, spread sheets, timers or generic mathematical calculators, and is able to be independently validated.
  • The software should enable health care professionals, patients or non-healthcare professional caregivers to independently review the basis for the recommendations presented by the software.

The exclusion criteria listed above are only intended to serve as a foundation for an analysis to be carried out, and should not be interpreted as a rigid set of exclusion factors. In addition to the exclusion criteria, other factors may need to be considered when determining whether software would qualify as a medical device.

Examples that are not subject to the Regulations are provided in the SaMD Examples document.

2.3 Classification of SaMD

Once it has been determined that a software is a medical device, classification must also be determined. While several factors are taken into account in the classification decision, SaMD's intended use will be fundamental in the determination of its classification.

SaMD can be considered to be an active device because it relies on a source of energy other than energy generated by the human body or gravity. As such, Health Canada utilized classification Rules 10(1), 10(2) and 12 in Part 1 of Schedule 1 of the Regulations to classify SaMD. This document explains that additional rules outlined in Part 2 of Schedule 1 of the Regulations will also be used to classify SaMD. Other classification rules may be used as SaMD technology progresses.

Every SaMD will have its own independent classification, even when a SaMD is interfaced with other SaMD, other hardware medical devices, or used as a module in a larger system that may or may not consist of other SaMD and non-regulated modules. Although SaMD is not incorporated into a hardware medical device, it does not have to be used alone in order to maintain its SaMD status. SaMD may be designed to include several functions that are intended to be used in different circumstances.

Manufacturers must determine the risk class of the SaMD based on the intended use of the software and the applicable rules in Schedule 1 of the Regulations. The risk class will be confirmed by the Medical Devices Bureau upon review of the medical device licence application. For further clarity regarding the interpretation of a specific rule, please contact the Medical Devices Bureau (hc.devicelicensing-homologationinstruments.sc@canada.ca). For an overview of the required submission documents and regulatory requirements for all risk classes of medical devices, please refer to the “Licensing a Medical Device in Canada” summary table.

2.3.1 SaMD intended use statement

The intended use of SaMD is normally reflected in various sources such as the manufacturer's labelling, including instructions for use manuals, websites, promotional material, and other information provided by the manufacturer.

The expectation is that all the relevant information is contained in the intended use statement. The manufacturer should describe the intended use of the software, as well as any conditions, diseases that it's intended to treat and/or diagnose, including a description of the following factorsFootnote 4:

2.3.1.1 Significance of the information provided by the SaMD to the healthcare decision

The significance of the information provided by the SaMD to the health care decision identifies the intended medical purpose of the SaMD. The statement should explain how the SaMD meets one or more of the purposes described in the definition of a medical device, i.e., supplying information for diagnosis, treatment, prevention, monitoring, etc.

2.3.1.1.1 Treat or diagnose

Treating or diagnosing infers that the information provided by the SaMD will be used to take an immediate or near-term action:

  • To treat/prevent or mitigate by connecting to other medical devices, medicinal products, general purpose actuators or other means of providing therapy to a human body.
  • To diagnose/screen/detect a disease or condition (i.e., using sensors, data, or other information from other hardware or software devices, pertaining to a disease or condition).

2.3.1.1.2 Drive clinical/patient management

Driving clinical/patient management infers that the information provided by the SaMD will be used to: triage or identify early signs of a disease or condition that will be used to guide next diagnostics or treatment interventions; aid in diagnosis; aid in treatment:

  • To triage or identify early signs of a disease or conditions.
  • To aid in diagnosis by analyzing relevant information to help predict risk of a disease or condition or as an aid to making a definitive diagnosis.
  • To aid in treatment by providing enhanced support to safe and effective use of medicinal products or a medical device.

2.3.1.1.3 Inform clinical/patient management

Informing clinical/patient management infers that the information provided by the SaMD will not trigger an immediate or near-term action:

  • To inform of options for treating, diagnosing, preventing, or mitigating a disease or condition.
  • To provide clinical information by aggregating relevant information (e.g., disease, condition, drugs, medical devices, population, etc.).
2.3.1.2 State of the healthcare situation or condition that the SaMD is intended for

2.3.1.2.1 Critical situation or condition

There are situations or conditions where accurate and/or timely diagnosis or treatment action is vital to avoid death, long-term disability or other serious deterioration of health of an individual patient or to mitigating impact to public health. SaMD is considered to be used in a critical situation or condition where the type of disease or condition is:

  • Life threatening state of health, including incurable states.
  • Requires major therapeutic interventions.
  • Sometimes time critical, depending on the progression of the disease or condition that could affect the user's ability to act upon the output information.
  • Intended target population is fragile with respect to the disease or condition (e.g., pediatrics, high risk population, etc.).
  • Intended for specialized trained users.

2.3.1.2.2 Serious situation or condition

There are situations or conditions where accurate diagnosis or treatment is of vital importance to avoid unnecessary interventions (e.g. biopsy) or timely interventions are important to mitigate long-term irreversible consequences to an individual's patient's health condition or public health. SaMD is considered to be used in a serious situation or condition when:

  • The type of disease or condition is:
    • Moderate in progression, often curable,
    • Does not require major therapeutic interventions,
    • Intervention is normally not expected to be time critical in order to avoid death, long-term disability or other serious deterioration of health, whereby providing the user an ability to detect erroneous recommendations,
  • Intended target population is NOT vulnerable with respect to the disease or condition
  • Intended for either specialized trained users or lay users.

2.3.1.2.3 Non-serious situation or condition

There are situations or conditions where an accurate diagnosis and treatment is important but not critical for interventions to mitigate long-term irreversible consequences on an individual patient's health condition or public health. SaMD is considered to be used in a non-serious situation or condition when:

  • The type of disease or condition is:
    • Slow with predictable progression of disease state (may include minor chronic illnesses or states),
    • May not be curable; can be managed effectively,
    • Requires only minor therapeutic interventions, and
    • Interventions are normally noninvasive in nature, providing the user the ability to detect erroneous recommendations.
  • Intended target population is individuals who may not always be patients.
  • Intended for use by either specialized trained users or lay users.
2.3.1.3 Description of the SaMD's core functionality

The description of the SaMD's core functionality identifies the critical features/functions of the SaMD that are essential to the intended significance of the information provided by the SaMD to the healthcare decision in the intended healthcare situation or condition. This description should include only the critical features.

2.3.2 Non-IVD SaMD Classification

The following chart provides an illustration of how non-IVD SaMD may be classified as per the factors described above and identified in the SaMD intended use statement. The chart suggests which classification rule might be applied. This chart has been provided for information purposes only; it should only be used as a guide to provide general direction on device classification. Health Canada reserves the right for the final decision on device classification.

Table 2: Non-IVD SaMD classification
The following information was modified from the IMDRF document, “Software as a Device”: Possible Framework for Risk Categorization and Corresponding Considerations, to accommodate Health Canada's classification rules.
State of Healthcare situation or condition Significance of information provided by SaMD to healthcare decision
Treat or diagnose Drive clinical/patient management Inform clinical/patient management
Critical III III I or IITable 2 Footnote b
Serious II or IIITable 2 Footnote a II or IIITable 2 Footnote a I or IITable 2 Footnote b
Non-serious I or IITable 2 Footnote b I or IITable 2 Footnote b I or IITable 2 Footnote b
Table 2 Footnote a

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

Table 2 Return to footnote a referrer

Table 2 Footnote b

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

Table 2 Return to footnote b referrer

Class I under Rule 12

SaMD may be classified according to Rules 10(1), 10(2), or 12, as per Schedule 1 of the Regulations.

Rule 10:

  1. Subject to subrule (2), an active diagnostic device, including any dedicated software, that supplies energy for the purpose of imaging or monitoring physiological processes is classified as Class II.
  2. A device described in subrule (1) that is intended to be used to monitor, assess or diagnose a disease, a disorder, an abnormal physical state or a pregnancy, if erroneous readings could result in immediate danger, is classified as Class III.

The majority of SaMD apps will be classified under Rule 10. Medical device software is considered to be an active device because it relies on a source of energy other than energy generated by the human body or gravity. Rule 10(1) classifies all active diagnostic devices, including any dedicated software, that supply energy for the purpose of imaging or monitoring physiological processes, as Class II. In the context of Rule 10(1) as it pertains to software, the phrase “monitoring a physiological process” means software that assists patients and healthcare professionals (HCPs) in observing, tracking and recording medical parameters, such as physiological and anatomical measurements, over time or at one point in time. For example, if a SaMD's intended use statement stated that it would be used in a serious healthcare situation, and will be used to treat, diagnose or drive clinical management, the SaMD would be a Class II medical device as per Rule 10(1).

Rule 10(2) classifies devices that are intended to be used to monitor assess or diagnose a disease, a disorder, an abnormal physical state, or a pregnancy, where erroneous readings could result in immediate danger as Class III devices. For example, if a SaMD's intended use statement stated that it would be used in a critical state of healthcare or for a critical health condition, and will be used to diagnose or drive clinical management, that SaMD would be Class III as per Rule 10(2) since an erroneous result could lead to immediate danger.

Rule 12:

Any other active device is classified as Class I.

Rule 12 acts as a fall-back rule for active devices. For example, if a SaMD's intended use statement stated that it would be used to inform clinical management, and will be used in a non-serious healthcare situation or condition, that SaMD would be classified as Class I.

Examples of SaMD that are classified according to Rules 10(1), 10(2), or 12 of the Regulations are provided on the Health Canada website.

2.3.3 IVD SaMD Classification

According to IMDRF, “Software as a Medical Device” (SaMD) is a medical device and includes in-vitro diagnostic (IVD) medical device. The same risk factors used to develop the IVDD classification rules apply to both conventional IVDDs and IVD SaMD. Therefore, to classify an IVD SaMD, the classification rules set out in Schedule 1, Part 2 of the Medical Devices Regulations that are applicable to In Vitro Diagnostic Devices should be used.

Note: All IVDD classification rules can apply to IVD SaMD other than IVDD Rule 6. IVDD Rule 6 stipulates that near patient IVDDs are Class III. A near patient IVDD is defined as an IVDD for use outside a laboratory environment for home testing or for point-of-care testing. Most SaMD products are intended to be used outside a laboratory environment. Although risk factors associated with the place of use do exist for conventional IVDD products, not all of the same risk factors necessarily apply to software. For example, the effectiveness of conventional IVDDs may be compromised by environmental conditions and/or lack of user expertise but these same risk factors may not affect SaMD products. Since Health Canada's near patient definition and classification rule were intended for conventional IVDD products, and do not incorporate considerations to software risk factors. IVDD Rule 6 will not be applicable when classifying IVD SaMD.

Appendix 1: Additional International Resources

For additional clarification on this issue, the following documents may be useful:

  • International Medical Device Regulatory Forum (IMDRF), Software as a Medical Device (SaMD): Key Definitions, IMDRF SaMD Working Group N10, 2013
  • International Medical Device Regulatory Forum (IMDRF), Software as a Medical Device (SaMD): Application of Quality Management, IMDRF SaMD WG, 2015.
  • International Medical Device Regulatory Forum (IMDRF), “Software as a Device”: Possible Framework for Risk Categorization and Corresponding Considerations, IMDRF SaMD WG, 2014.
  • Food and Drug Administration. “Mobile Medical Applications” Guidance for Industry and Food and Drug Administration Staff. Centre for Devices and Radiological Health. 2015.
  • International Medical Device Regulatory Forum (IMDRF), Software as a Medical Device Clinical Evaluation, IMDRF SaMD WG, 2017.
  • Food and Drug Administration. Clinical and Patient Decision Support Software, Centre for Devices and Radiological Health, 2017.
  • Food and Drug Administration. Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act, Centre for Devices and Radiological Health, 2017.
Footnote 1

IMDRF, “Software as a Medical Device (SaMD): Key Definitions”

Return to footnote 1 referrer

Footnote 2

Software that is intended to acquire process or analyze a medical image or a signal from an IVDD or a pattern/signal from a signal acquisition system. The fidelity and integrity of the signal in this context is often critical to the overall performance of a software-based medical device. A signal acquisition system may be considered a system that acquires real-world, patient-derived, data that can serve as input to the SaMD.

Return to footnote 2 referrer

Footnote 3

Where feasible, the exclusion criteria were aligned with those from the United States FDA.

Return to footnote 3 referrer

Footnote 4

The factors presented in this section were published in the International Medical Device Regulatory Forum's N12 document titled “Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations”.

Return to footnote 4 referrer

Page details

Date modified: