Health Canada recently released a draft guidance document on software as a medical device (SaMD). This guidance is intended to help industry better understand the regulatory compliance requirements for software technology that has a medical purpose. In particular, it aims to clarify when software may be considered a medical device, as well as the related regulatory classification (i.e. device class) and corresponding licensing requirements.
What is Software as a Medical Device
The draft guidance defines SaMD as software intended to be used for one or more medical purposes and performs these purposes without being part of a hardware medical device.
More specifically, Health Canada generally interprets "medical purposes" in the context of software as follows:
- Intended to acquire, process, or analyze a medical image, or information from an in vitro diagnostic device or a measurement/signal from a monitoring device or imaging device.
- 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.
SaMD can include mobile apps, software capable of running on general purpose computing platforms, and software used in combination (e.g. as a module) with other products including medical devices.
The draft guidance excludes from regulation software that is necessary for a hardware medical device to achieve its intended medical purpose, as well as 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. Examples of the latter include:
- 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.
Once it has been established that a software technology is indeed a medical device, classification must then be determined.
This determination follows a risk-based approach by applying the Classification Rules for Medical Devices detailed in Schedule 1 of the Medical Device Regulations.
In contrast to the previous guidance, Software Regulated as a Class I or Class II Medical Device, it is now proposed that software may be considered a class I, II or III device. According to Health Canada, such classification will depend on three main factors: (i) the significance of the information provided by the SaMD to the healthcare decision; (ii) the state of the healthcare situation or condition that the SaMD is intended for; and (iii) the description of the SaMD's core functionality.
The draft guidance provides that most SaMD applications will be classified as Class II under Rule 10 of the Classification Rules:
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.
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.
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.
Pursuant to rule 12, any other active device is classified as Class I.
Other classification rules may also be used as SaMD technology progresses.
Examples of SaMD classification are provided on a separate, companion document, Draft Examples Document - Software as a Medical Device (SaMD), which was created in conjunction with the draft guidance.
Health Canada is seeking feedback on the draft guidance and its companion document until March 29. The Fasken Life Sciences team has extensive experience in this area and is available to consult with stakeholders interested in responding to the draft guidance.