Scientific Advisory Panel on Software as a Medical Device (SAP-SaMD) - Questions

Part 1: Draft Guidance Document: Software as a Medical Device (SaMD)

Pre-amble

Software plays an important role in the healthcare industry. The functionality of any software product, and the manner in which it is represented or labelled for use, dictates whether it qualifies as a medical device under the Canadian Medical Devices Regulations (the Regulations).

A draft guidance document has been developed and is intended to provide a definition of Software as a Medical Device (SaMD), and to provide guidance as to how SaMD may be classified as per Schedule 1 of the Regulations. This draft guidance document is intended for medical device manufacturers, importers, distributors, healthcare 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.

Prior to external consultation Health Canada wishes to engage the SAP-SaMD panel to solicit initial feedback on the content of the draft guidance.

Question 1.1

Health Canada has used the definition for SaMD provided by the International Medical Device Regulator’s Forum (IMDRF). Is the definition provided in Section 1.4 of Health Canada’s Software as a Medical Device guidance document clear enough for the spectrum of manufacturers (from single person start-ups to large, established medical device manufacturers) this document is intended for? Are you aware of examples of medical software that do not fit this definition?

Question 1.2

Section 2.1.2 of the guidance document provides examples of SaMD. Are these examples sufficient enough to help you differentiate the difference between Non-SaMD, Medical Device Software, and SaMD? What other examples could be included to provide further clarity?

Question 1.3

The Regulations utilize a risk-based approach to regulating products within its scope. The safety and effectiveness evidence 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. The Regulations outline two sets of risk-based classification rules; one set for traditional, non-in vitro diagnostic devices (IVDDs) and another set for IVDDs.

The risk classification of non-IVDDs is primarily based on the following criteria: the level of invasiveness, tissue/organ exposure, potential for infection, and energy exposure.

The risk classification of IVDDs is primarily based on the following criteria: clinical application (screening, diagnosis, monitoring, prognosis, predisposition etc.), expertise of intended user (testing laboratory vs. home test), the importance of the information to the diagnosis, the nature of the disease, and the impact of the diagnostic test result to the individual.

The following example illustrates how the risk classification of the same medical device would be different depending on what set of rules was used for the classification: Prenatal screening software for first and second trimester risk calculation for trisomies and first trimester calculation for preeclampsia are software applications able to combine a number of IVD results to calculate and report an additional result to be used for clinical purposes.  Based on the non-IVDD classification rules, this type of software is categorized as an “active diagnostic device” that is classified as Class II. However, using the IVDD classification rules, this type of software would have been categorized as a fetal congenital disorder screening test that is classified as Class III. Health Canada would like the panel to address the following:

1. Health Canada is considering classifying software intended to be used as an in vitro diagnostic device using the IVDD classification rules described in Schedule 1 part 2 of the Regulations. Do you agree with this approach?
2. Health Canada is considering adopting the approach taken by the Therapeutic Goods Administration described in the Appendix to regulate software intended to be used as IVDDs. Do you agree with this approach?

Part 2: Future of medical device software including SaMD and Health Canada’s Regulatory Approach

Pre-amble

The increased reliance on software in healthcare in recent years is evident and this sector is expected to continue to expand in the coming years. As the federal regulator of medical devices, Health Canada reviews medical devices to assess their safety, effectiveness and quality before being authorized for sale in Canada. Prior to selling a device in Canada, manufacturers of Class II, III and IV devices must obtain a Medical Device Licence. Health Canada is exploring options to adapt its regulatory approach in this sector and while fulfilling its mandate to improve outcomes for patients.

Health Canada wishes to engage the SAP-SaMD panel to solicit discussion around the future of Medical Device Software and SaMD in Canada to inform future considerations in adapting our regulatory approach.

Question 2.1

Do you believe Health Canada should regulate SaMD within the current regulatory framework or should Health Canada modify the existing regulatory framework or create a new framework to address SaMD in its current form? Specifically:

1. Are the classification rules that exist in the Regulations sufficient to classify the risk of current SaMD?
2. Software and apps can have very short development cycles. What methods, initiatives, processes etc. would you recommend to Health Canada to ensure it fulfills its mandate to provide Canadians with timely access to safe and effective SaMD?

Question 2.2

What do you believe the largest emerging trend is in medical device software and SaMD? What do you believe will be the largest challenge facing Health Canada in regulating medical device software and SaMD as it carries out its mandate in helping the people of Canada maintain and improve their health?

Question 2.3

Currently, software such as cloud-based analysis of data from Next-Generation Sequencing (NGS) platforms, web-based radiation treatment planning software, and web-based intraocular lens calculators, are not regulated under the Regulations as they are considered software as a service (SaaS). It is possible that Medical Device Software and SaMD may evolve into technologies not covered by the Regulations or by our draft SaMD guidance. Could you provide some insight into other examples of software that may fall outside of the Regulations and advise whether Health Canada should play a role in regulating market access of such software to help ensure that it is safe and effective for the people of Canada?

Appendix

Table: How IVD software is regulated in Australia

Type of software / intended purpose	How is it regulated?	Examples
1. Software that is built into an IVD medical device (e.g. instrument or analyser)	The instrument with the installed/ embedded software is a single IVD, i.e. not licenced separately	Any software that is supplied pre-installed on an IVD instrument, e.g. operating software in a clinical analyser, point of care analyser or personal use IVD such as a glucose meter. The software is a part of the device and is not considered to be a separate or distinct device.
2. Software that is supplied separately to an IVD medical device (e.g. instrument or analyser) but which is intended to operate or influence the IVD	As a distinct IVD that is separate to the IVD instrument/ analyser	Software for operating an IVD instrument that is installed on a computer interface used for the control of the IVD instrument. Software for upgrading functionality that is to be installed on an IVD instrument or connected computer interface
3. Software that is intended to be used to provide diagnostic or therapeutic information and is not intended to drive or influence an IVD medical device (e.g. instrument or analyser)	As an IVD	Standalone software able to combine a number of IVD results to calculate and report an additional result to be used for clinical purposes. For example, software intended for the interpretation of a series of results obtained as part of a first trimester screening assessment in order to determine foetal risk of trisomy 21. Standalone software intended for use in staging or predicting severity of disease by means of an algorithm based on a combination of anthropometric measures and non-invasive biomarkers.
4. Software that is intended for handling (e.g. receiving, storing, transferring) patient-related information, including results from IVD devices, which may be used in combination with an IVD instrument or other electronic devices	Does not meet the definition of a Medical Device	Not applicable
5. Corrections to software errors	As a correction to the IVD (not a distinct or separate IVD)	If functionality that changes the original intended purpose of the software is added, then the software may be considered a distinct and separate IVD to that of the original.
Reference: Australian Government Department of Health Therapeutic Goods Administration document entitled “Software as in vitro diagnostic medical devices (IVDs)”