Scientific Advisory Panel on Software as a Medical Device (SAP-SaMD) - Record of Proceedings – January 26, 2018

Panel members: Robert DiRaddo (Chair), Laith Bustani, Joseph Cafazzo, Eric Cohen, Kimberley Hanson, Christopher Kamel, Ron Parker, Bakul Patel, Catherine Proulx

Presenters: Colin Foster, Daniel Yoon (Health Canada), Bakul Patel (US FDA), Dana O'Born (CCI), Melissa Perri & Anthony Kaul (CloudDX), Graeme Moffat (InteraXon), David Bissessar (Identos) - (on behalf of CCI), Monica Magidin (Siemens Healthcare, on behalf of MEDEC)

Health Canada staff: Celia Lourenco, David Boudreau, Sarah Chandler, Colin Foster, Patrice Sarrazin, Andrew Hawel, Ian Glasgow, Kevin Day, Graham Ladner, Hripsime Shahbazian, Daniel Yoon, Yvonne Fallenbuchl, Tyler Dumouchel, Patrick Assouad, Marc Lamoureux, Patrick Fandja, Christine Lefebvre, Anoop Poovadan, Asaad Ahmed

Welcome and opening remarks (Celia Lourenco)

Celia Lourenco, the Senior Executive Director, Therapeutic Products Directorate (TPD) welcomed the scientific advisory panel members and presenters. She provided context for the meeting, noting that software as a medical device (SaMD) is an emerging area that Health Canada is finding challenging to regulate. As Canadians increasingly incorporate medical technology into their everyday lives, Health Canada must provide appropriate risk management and regulatory oversight without stifling technological innovation and access to the market. The Panel's expert advice on how Health Canada can improve the draft guidance will be crucial in ensuring that Health Canada appropriately scope and regulate this area. She explained the process to be used for the meeting, and once again thanked the panel for their time and willingness to provide advice to Health Canada. She then handed the meeting over to the Chair of the panel.

Chair's address (Robert DiRaddo)

The Chair reiterated the mandate of the panel and the questions posed to the panel by Health Canada. He then confirmed acceptance of the terms of reference of the panel and the draft agenda for the meeting. He explained that the presenters would address the panel only and there would be no discussion between presenters. Following the presentations, the presenters would leave and the panel would deliberate on what they had heard, and formulate responses to Health Canada's questions. He asked each member to briefly introduce themselves, and to stipulate if any changes had occurred since each had completed their written declaration as part of the membership requirements for this committee. No additional conflicts of interest were declared. Short introductions followed. The Chair then asked attendees to introduce themselves before the presentations commenced.

Presentations

Health Canada

Colin Foster provided an overview of the regulatory framework for medical devices. He provided the definition of a device and the how software would qualify as a device based on this definition. He noted that there are many software products that fit this definition; however there are others that do not fit this definition. Health Canada would like the Panel's input to address, whether or not these software products are devices and how to classify these products based on current regulatory framework. He explained the risk based approach to regulation of devices. Health Canada relies on classification rules that are published in the Medical Devices Regulations (the Regulations) to categorize medical devices into one of four risk classifications: Class I, II, III or IV, Class I representing the lowest risk devices and Class IV representing the highest risk devices. There are two sets of rules in the Regulations, one for non-In Vitro Diagnostic Devices (IVDDs) and the other for IVDDs. Medical device manufacturers, importers and distributors are subject to different regulatory requirements depending on the risk classification of devices they intend to introduce into Canada. For the medical device licence application process, Health Canada requires submission of different information depending on the medical device risk classification. He provided examples of types of software currently licensed by Health Canada. This guidance document was drafted to facilitate classification of SaMD.

He noted that the current classification rules were defined when the Regulations came to force, 20 years ago, and do not reflect the current technology. Health Canada needs a guidance document addressing how to classify this new technology.

Issues raised by the panel, in questioning the presenter, included, but were not limited to:

• Definition of a device and labelling of software products. When software is considered a device and when it falls outside this definition.
• The same product may be considered a device if the labelling claims are falling under the definition and not be considered a device if labelling does not indicate any of the claims covered by the definition. There is a lot of room for interpretation.
• Concept of medical grade was suggested to differentiate type of software.
• Classification rules were discussed for clarification.
• Differentiation of medical software (such as radiation treatment planning software) vs software as a service was questioned.
• The distinction between software and hardware, which component is considered a device - continuing blurring of this distinction.
• The International Medical Device Regulators Forum (IMDRF) definition is reflecting the concept of software that does not reside within the hardware. One can have a third party providing the planning software through an interface that can be humans or machines.
• Issue of labelling, where the limitation of labelling lies? Labelling indicates who is going to use it and for what purpose?
• We need a balance between regulation, patient safety, and to allow new technology development and availability.

United States Food and Drug Administration (US FDA)

Bakul Patel provided an overview of how the US FDA and the IMDRF are handling this issue. He described three types of medical device software: Software in a device; Software as a device; and Software that is used in the manufacturing process of a device. What is a device and what is not a device? How do regulators address this category of devices? Some of the software is considered a medical device; others fall outside medical devices definition.

Next he described the activities of IMDRF and provided the SaMD definition developed by the IMDRF working group and explained the SaMD Risk Framework.

He also described a number of US FDA activities in this area, including the FDA Pre-Certification Program for a company-based streamlined regulatory approach for SaMD that relies on a demonstrated culture of quality and organizational excellence.

He noted that we need to look at how quickly these products change and evolve so that we can develop a regulatory process that is not stopping this progress. We need to make sure that makers of these products are reliable. The assessment criteria are based on 5 excellence principles: patient safety, product quality, clinical responsibility, cybersecurity and proactive culture.

Currently the FDA is looking at 9 companies who participate in this voluntary program.

Issues raised by the Panel, in questioning the presenter, included, but were not limited to:

• From software perspective regulatory framework may need to look at interfaces to understand where the boundaries are.
• Wouldn't it be a better a fit to include the Pre-Cert in ISO type of organization so that all companies can apply it and it would be recognized by everyone?
• Does Health Canada consider participating in a similar process to include Canadian companies?

Council of Canadian Innovators (CCI)

Represented by Dana O'Born, Melissa Perri, Anthony Kaul, Graeme Moffat, David Bissessar

The CCI presentation included an overview of SaMD and market challenges. They looked at the IMDRF approach to SaMD and noted that there are many definitions in IMDRF documents that have not yet been tested in the real world. IMDRF categories are product-centric rather than company-centric. Software change management is not addressed appropriately by IMDRF. Data residence is a concern: who owns the data? They listed number of opportunities for Canada.

They also discussed activities in the US. What makes excellent software companies excellent? Can we assume that "Good SaMD practices" are equal to "Good software practices"?

They noted that software and medical devices evolve at different time scales. There are a number of concerns:

• Change management
• Version control

Agile software development is a standard practice:

• Rapid iteration, no fixed version at launch
• Preferred approach in cloud connected software (regular improvements)
• Addressed by AAMI TIR45 (2012)

The regulation of machine learning in SaMD is still very uncertain globally.

It was noted that user behavior change is another concern.

For patient-oriented software:

• How can we gauge 'technophilia' within patient groups?
• Are there health/mental health consequences of overuse?
• Some users will explore the entire space allowed by the software - what consequences?

For behaviour change software:

• Users will follow the software where it takes them - how does the software measure outcomes & behaviours to adapt?

Decision support software for healthcare professionals:

• Users will follow the software where it takes them - what is the consequence of dependence on cognitive software on decisions?
• What is the consequence of non-adoption on health outcomes

The FDA Pre-Cert Program was described. It was noted that Canada has a much smaller market and should work to harmonize US FDA and Canadian regulations for improved patient access & better market access. Standardize working definitions for reduction of market uncertainty.

Issues raised by the panel, in questioning the presenters, included, but were not limited to:

• Agile technologies are not new. The difference is in transparency rather than how software technology is being developed.
• Disagree with Good SaMD practices = Good software practices assumption. There is a lot of poor software out there. Software companies need to adopt good software development practices. The level of rigor to validate software is not the same as the one applied to medical devices
• There is little guidance on how a physician processes patient generated data during diagnosis. Suggested algorithms may not be correct and this could create problems.
• We have a large number of software developments by Highly Qualified Personnel (HQP) to satisfy a degree program. We need to facilitate some of these HQPs to develop their product. We cannot always rely on large companies.
• Similar to the US FDA we need to encourage Health Canada employees to come to software development lab and gain some experience on how software is developed - an invitation was extended by the chair to the Health Canada employees to visit National Research Council labs to gain experience and to observe the process.

Medical Devices Canada (MEDEC)

Represented by Monica Magidin
MEDEC presentation focused on differences between the SaMD and non-SaMD.

She presented the IMDRF definition for software as a medical device. She noted that a software would be considered a medical device if it meets the definition of a device. However, software cannot "act" on its own; it needs an interface to access data, to process data or to output data. Some software is not considered a device. SaMDs undergo frequent changes after being placed onto the market. Regulations shall clearly lay out, when a change to a SaMD needs a premarket approval / postmarket notifications. Changes related to SaMD may also be related to cybersecurity.

Manufacturers are challenged to provide relevant and reliable data in order to:

• Expand indications for use
• Perform Post-market Clinical Follow-up (PMCF) studies
• Claim objective performance criteria and goals

Even in consideration of innovative techniques, SaMD shall bear a clear intended purpose as required by current regulations. Collecting data generated by SaMD could be used to support new indications or claims, if the data is collected appropriately. SaMD which are altering the medical purpose by themselves without controls of the manufacturers are not in control of their safety and effectiveness. Their verification and validation would be subject to doubts.

Which classification should be applied for software? Software requires, as all other medical devices, a risk-based approach to classify and apply regulatory stringency. Software can be classified according to existing regulatory frameworks. The IMDRF provides a stratification scheme to determine the associated risk of the output data of a SaMD. Evaluation of a SaMD is expected to be iterative and continuous.

Health Canada regulates the importation and sale of the medical device. Are application service providers (ASP) subject to the Regulations?

In conclusion she noted that:

• SaMD is a "special" medical device.
• Full adoption of IMDRF principles for SaMD, where possible, should be taken into account in order to drive an approach of harmonization.
• Risk Classification for SaMD should provide guidance to appropriate activities for design and manufacture.
• Consideration should be given to the US FDA's approach to Clinical Decision Support of SaMD
• Regulations should not hinder software changes such that the benefit to the user is unduly delayed

Issues raised by the panel, in questioning the presenter, included, but were not limited to:

• Interpretation of "sale" creates a loophole that allows for some software to be regulated as a device and others to be exempt from it.
• If someone leases a device, there is no sale, therefore it is not regulated.
• It was noted that no software is 'sold' by normal definitions, rather licenses to use are paid for (i.e. the purchaser doesn't "own" the software). This was viewed as an important loophole.
• Regulatory requirements for medical devices are so high that as a startup manufacturer you may choose not to take the regulatory path.
• This is an advisory panel and panel members feel that the current definition does not seem to allow for some of these products to be considered devices. The panel encouraged Health Canada to look into the interpretation of "sale" to allow consistent application across the product line.
• Introducing regulatory changes takes a long time. In the current regulatory framework Health Canada needs to provide some guidance regarding these products. Legal interpretation of this term in the Act is narrow and makes it difficult to include some products.

After the presentations, external presenters left the meeting.

Draft guidance document

To frame the questions for Panel discussion Daniel Yoon (Health Canada) provided an overview of the draft SaMD guidance. This draft Guidance is intended to clarify what SaMD is subject to the Regulations and to provide guidance on how SaMD may be classified. It was explained that recommendations and advice from today's meeting will be analyzed and considered for revising the draft guidance document. Health Canada intends to release guidance for public consultation in summer 2018. In conclusion he summarized the questions posed to the panel.

Issues raised by the panel, in questioning the presenter, included, but were not limited to:

• Can manufacturers follow guidelines to develop their product? Most guidelines are developed to clarify regulations. They do not address design and development aspects of a product.
• Is the public consultation done only by posting it on Health Canada WEB? Since many stakeholders are very busy, web posting should be supplemented by direct solicitation of stakeholders. It has to be an active process.
• We could follow the way IMDRF documents were posted for comments and feedback was solicited, we need to get in touch with organizations that have networks and can distribute through them.
• This Panel has limited representation (mainly from Ontario), we need to enroll from across the provinces and reach remote consumers as well.
• What is the nature of advice that Health Canada seeks? Is it only on guidance document or includes definitions?
• Intended audience in the guidance seems to be limited. What if you have a software developer that is not aware of these regulations? Perhaps it needs to include software developers as well. Health Canada is trying to include innovation hubs to seek their input.
• Does the regulator do active surveillance on what is out there on a market? Some of the apps that are available seem to be devices; do we try to monitor these? How do the users know what they are getting? Should the user get a message about the app if it has been approved by a regulator? This is one of the Post Market Surveillance (PMS) program's biggest challenges. PMS does not actively monitor the apps. Health Canada is relying on the manufacturers and the users to report incidents. We would like to have input on how we could actively monitor these apps.
• Most of the apps (about 99%) out there are distributed by 2 major providers: APPLE's App store and GOOGLE Play. APPLE is very rigorous about what apps they allow. Perhaps there could be discussion with them if they look at the regulatory requirements for such apps. Android market is not as rigorous. There are about 1000 apps/months created since 2013. It requires a different approach.
• Perhaps similar to natural health product guidelines Health Canada needs to introduce a different, less onerous process of registration. High level description of natural product regulatory requirements was provided.
• How can we borrow from existing frameworks to devise different set of requirements for these products?
• It is important to acknowledge that approval by Health Canada does not always trigger consumer interest. Consumer may get an app regardless of its regulatory status.
• What about prescribing apps that go beyond manufacturing and sale and play a role of a medical advice. Clinicians are relying on that information. Most of these devices have a personal context. SaMD is taking us to a different paradigm where devices have not been before. These types of applications may increase at a rate that we cannot respond to it.

Deliberation on the questions (All panel members)

The chair introduced the questions posed by Health Canada and led the discussion.

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

Question 1.1

Health Canada has used the definition for SaMD provided by the International Medical Device Regulator's Forum (IMDRF).

1. 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?
2. Are you aware of examples of medical software that do not fit this definition?
   • Most members agreed with the IMDRF definition, one thing missing is incremental changes (changing functionality), how is that going to be addressed.
   • What if the software is on a cloud? Does this definition address the cloud?
   • In some cases if the software is in a device (ECG machine), it could be turned off, and a third party software could be used. Are we going to look at this software differently? It would seem that two pieces of software that are providing the same function are treated differently.
   • What is the difference between medical device software vs SaMD.
   • How about wearable software (like Fitbit), is it considered a device? When does it become a medical device?
   • Apple is developing an app on apple watch that measures blood glucose. Is it going to be considered a device? What the software does and where it is used is driving the definition.
   • We have many apps available that allow the user to run an algorithm and come up with indications. When will these be considered to be a device? The intended use of a sensor will define its status as a device.
   • Where does it matter if it is just software vs SaMD? Medical device software will be registered with the hardware device. SaMD will be registered by itself as a device with its own classification. Both of this software will undergo a similar review.
   • There needs to be some wording regarding machine learning.
   • The purpose in the definition is medical. What is "medical"? Perhaps we need to use "health related" rather than medical.
   • There is definitional issue and a regulatory path issue in front of us.
   • In the IMDRF Software as a Medical Device: Clinical Evaluation document, page 11, there is a pictorial that could be included in this document to clarify this issue. This pictorial addresses what is considered a processing of a data.

Question 1.2

Section 2.1.2 of the guidance document provides examples of SaMD.

1. Are these examples sufficient enough to help you differentiate the difference between Non-SaMD, Medical Device Software, and SaMD?
2. What other examples could be included to provide further clarity?
   • There is nothing wrong with these definitions, rather where the placement of these definitions in a document. Without talking about classification, the provided examples do not make much sense. Put the examples after the classification piece.
   • Sensory devices that provide patient assistance, where would these fall in classification? It is difficult to classify a product without having specific information on their intended use.
   • Simplify the document; consider removing all the other definitions from the document. It seems to be creating confusion.
   • There is confusion on energy requirement. Is software really an active device? When these rules were created they did not consider software as a medical device. It is true that software does not apply energy to achieve its purpose; we are using an existing rule to address classification.
   • The classification rule 10 does not seem to be a good one for software as a medical device. When is a SaMD not an active device?
   • There are other classification rules that will be considered as well outside the active device rule.
   • Some of the examples (page 15, otoscope, and page 7, blood pressure monitor) do not seem to be clear. Otoscope uses general purpose sensor that is indicated for general use. These examples have been developed by the international committee, perhaps these could be turned into frequently asked questions.
   • Providing decisions that have been made regarding software in the past could be a good reference. US FDA is already doing this.
   • Dose calculator example on page 17, what about the dose calculators for insulin? You are making a distinction as to who the user is, the patient vs the clinician.
   • Identification of examples is an on-going process; it should be a living document.
   • Definition and regulatory pathway are two different things. We need a simple definition.

Question 1.3

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.

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?
   • Health Canada is considering adopting the approach taken by the Therapeutic Goods Administration (TGA) described in the Appendix to regulate software intended to be used as IVDDs. Do you agree with this approach?
   • Software cannot do any harm by itself; it is the person's actions to the readings that may cause harm.
   • Classification rules may force the developer to follow a different path when developing their product to choose a lower classification.
   • It was noted that while the IVDD classification is based on public and individual health risk, there may be other risks related to software or data collection/storage that are additional risk considerations (e.g. data privacy, cybersecurity issues mentioned in FDA and MEDEC presentations)
   • Can we separate the risk of underlying disease from the software that is providing a reading?
   • Implications of who the user is for particular software seem to impact its classification. The manufacturer is responsible to provide appropriate user instructions for safe use. Risk mitigation features are important.
   • If we do not explain why we are using a certain rule there will always be questions asked. We need to provide more contexts how we are classifying a device.
   • Risk matrix provides risk categories however; it does not include number of people that would be using an application. There is a lot of information imbedded in the text (see pages 12 and 13).
   • Are we considering type of data, security of data when categorizing the risk?
   • The classification grid it is not very clear. How will a software developer creating the algorithm for providing parameters for a health condition classify it?
   • Manufacturer has to be very specific regarding why and where you are going to use it. It is not self-evident from software as to what it is intended for. Who the user of the software is, makes a big difference. Depending on interface you may have different consequences.
   • The document as it stands is a little too narrow. We are talking "medical" and not explaining what it means.
   • Are the manufacturers providing instructions for use? Some of these may be available on-line.
   • The intended purpose has to be very clear.
   • Risk management has to be provided by the manufacturer.
   • Consider to solicit input from allied health professionals and health economists.
   • Regarding the TGA document, if it has been vetted by another country we may consider using it for Canadian perspective.
   • Is there any reason why this is considered? The example that is provided explains that IVDD classification is decided separately from software. The classification should be based on risk of a device based on its intended use.
   • The Panel noted potential issues with 'intended use' as criteria for classification. Issue of potential for unintended use was raised.
   • Class IV risk for IVDDs is based on level of population risk. Class III represents the high risk for an individual. That is why we would like to classify software similar to TGA approach.
   • Health Canada already assesses software if it is part of an IVDD device.
   • There is a concern on putting treatment with diagnosis principle. The software does not add more risk to form of a treatment. For example, rehabilitation software, is coaching the user for physical therapy.
   • There is a spectrum to consider, it is difficult to come up with one rule for all cases.

Part 2: Future of medical devices software including SaMD and Health Canada's regulatory approach

Question 2.1

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:
2. Are the classification rules that exist in the Regulations sufficient to classify the risk of current SaMD?
3. 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?
   • Clinicians find it difficult to address regulatory issues; however, fewer regulatory regulations are always preferable.
   • Why is US FDA considering a pre-cert program? The concept of substantial equivalence does not apply to software. There is a technological difference. Software evolves very rapidly. There is at least 1000 apps/month and regulator will not be able to handle such a volume. It is not sustainable. This is why US FDA is looking at a different approach.
   • Regulations are there to protect the public. Traditionally medical devices have a long development process. Software is moving at a much faster pace. Regulating the developer of software vs the software seems like a logical approach.
   • In the world of software updates are beneficial to the public; we cannot prevent those updates coming out by introducing regulatory burden.
   • If you are a class II device manufacturer you need to certify your tools as safe. However, the burden of certifying software tools is so heavy that software process tools (e.g. code review, continuous integration) will not be made part of the official quality system, or will not be used at all. This makes it hard to reconcile good software development practices and quality systems.
   • Startups are usually bought out by bigger companies because they could not handle the regulatory burden.
   • Software engineers would build in algorithms that check the software. Once you have the built in checks it is easy to move to the next generation of the software.
   • To make the guideline robust it has to evolve over time. This guideline may be obsolete in one year.
   • How can you prioritize assessment tools? Need to engage with stakeholders, ask the public to provide input on what types of apps is they using.
   • Does Health Canada currently look at software code when assessing these type of products? We don't look at the code; we look at supporting reports for software validation.
   • There are best practices; if someone is developing a SaMD we should provide good practices to use.
   • US FDA looked at this from spectrum of things changing, each company using different processes, using different terminology, this is why they are looking at the organizations, how they are developing software, at a higher level and what are the results on the market.
   • There is a concern that if a guideline is complex companies are going to ignore it. We need to put out something simple and robust and revisit it in a year.
   • The TGA document is very simple. Proper communication and proper language would go a long way.
   • May be if you look at the clinical impact of a software you could approach it accordingly, you could evaluate it differently.
   • In Canada there are ethical committees that require products to be approved by Health Canada before considering their use. In clinical practice the clinician takes on the risk. How can Health Canada reduce risk of using these products by doing due diligence on the software product.
   • Why is this question asked? It is not related to the guideline that is provided for review. If you are truly looking for input, it should be done before you develop the document. You need to ask what you are struggling with. What are your regulatory concerns?
   • The questions were in two parts, first part focused on the document, looking for comments regarding the document, the second part is to get feedback on where gaps are and how we can address these concerns. This is described in the pre-amble of the questions that puts it in context.
   • For startups to meet the regulations is very complex. It is not very easy to understand the regulations and rules. So most of them would simply ignore them.
   • May be Health Canada needs an office to provide guidance to industry?
   • Traditional medical devices already have a path of development; development of software is quite different. Medical software is only a small part of software in general. We could look at other software development and applications (such as transport safety) and learn from that experience. We could look at airline industry (Airworthiness).
   • Personal Connected Health Alliance aims to make health and wellness an effortless part of daily life. They are focused on interfaces with software. They have many examples that may be useful.
   • Need to look at the scope that is in front of the MDB. The problems that we are trying to address are different than in other industries. However we can learn from them.
   • The patient privacy piece would be relevant to second part of the question. How would patient data be used by companies, level of protection would be important.

Question 2.2

1. What do you believe the largest emerging trend is in medical device software and SaMD?
2. 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?
   • Currently 99% of health technology is in electronic health records (EHR); free apps are a very small slice of this.
   • You need to look at the SaMD definition and decide if any of EHR falls under it. The volume of the apps will increase over time. Generation of data is going to be of importance. Data generation is going to lead to more SaMD applications.
   • Ownership of a product is being questioned: there is not always a single obvious manufacturer (e.g. open source software). We need to create an environment that allows this progress to go ahead in a safe manner.
   • Patients are becoming experts of their own healthcare. The information that patients have access to is enormous. There is a struggle to get useful information out of these data registries.
   • Apps for the neglected population (elderly, mental health, chronic illnesses).
   • Apps for people who are interested in self-diagnosis.
   • Despite the fact that there are many apps out there these apps are not accessed as frequently. Machine learning will be adjunct to clinicians, however the machine learning does not replace the clinician and it is very expensive.
   • There is a need to shift resources from pre-market to post-market activities. There are a good number of apps; we need to have post-market surveillance of these products performance. Health Canada may not be aware of it; however, there is a lot of information out there that could be very useful to know to determine which ones are good performers.
   • Most of these software developers are startups. Most of them know nothing about healthcare.
   • Need a short term document that handles the short term needs and evolves over time.
   • Canadian public does not wait for anyone; they use the apps of their choice regardless of the approval status.
   • We have number of EHR systems that are stand alone; these do not talk to each other. This will make it very difficult to regulate.
   • Most teaching hospitals have an innovative hub. The new technology is being developed faster than we think.
   • As a regulator we need to think outside the current regulatory framework.
   • There is a mission statement that we need to look at.

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?

• Software as a service (SaaS) is a marketing term. No software is sold to the user; only a license to use is provided. Location of software makes no difference.
• Yes it is possible.
• All software falls in that category.
• Diabetes clinics in hospital settings have systems that allow patients to access their record; nurses can access it and provide dosing decisions to the patients remotely.
• Physicians usually decide to use what works effectively for them. Using messaging apps may allow transfer of personal information.
• Patients are 3D printing their own devices, they do not look if it is approved or not.
• IT related technology only gets noticed if it gets out of your institution.
• If you put regulations in place that you cannot monitor, it becomes useless.
• There may be no problem not regulating it, however what we are introducing is not a level playing field. If radiation planning software is not residing on the machine, it is regarded as a software as a service. The idea of a software as service should be taken out of the guideline.
• Is this a legal interpretation that no sale took place? The language does not imply money exchange; the concept of sale does not always mean selling a product. The word "Distribute" describes the nature of providing a license to use software.
• Should ask for a second legal review of this interpretation.
• Regulators should ask what we can realistically accomplish with the resources available to us. Are we the correct office to start this discussion? Perhaps we should look outside Health Canada, such as medical associations, to discuss and provide some guidance.
• SaMD developed in hospitals is also covered under IT process which is fairly transparent.
• You can take everything including robotic surgery that has software residing on a cloud. This may not be a realistic approach.
• FOG computing at a local level, not a single server.
• Radio-frequency identification (RFID) technology trying to track what medication is given to the person.
• Block chain causing major disruption.
• Any data that is used for evidence based decision making, what happened when you lose it? Distribution of records comes with its own problems.
• If we look at data that is stored about the patient, are we also going to look at other personal data that is available on face book, other social media?
• Most applications like Alexa ran remotely.
• Biometric identification, integrated on in medical application, how does this impact on medical devices.
• Machine learning is done as a service, the computational power and storage requirements are so big that it will never be on a local server. People who ask medical questions to Siri, some of the answers were provided poorly. This is all done cloud based. Most these services are not conventional. They move away from being a device.
• If there is an anti-vaccine app that has a negative impact on public health, do we regulate it as a device?
• There is a real paradigm shift here. May be we need to step back and look at it again.
• Now people are looking at social media to look at suicide intentions.
• Siri answers medical questions, is it a device? People need to understand the limitations of these technologies.
• IVDD risk factors- are there consensus for Health Canada approach? It may be inaccurate. Approach is a good approach; however we need to look at it closer, to clarify the risk categories of these software products. TGA guideline is a good start.

End of deliberations.

Summary of recommendations:

• Too many definitions. Simplify the document; consider removing all the other definitions from the document.
• Consider removing terms that may not stand the test of time e.g. "cloud".
• Classification Rule 10 does not seem to be a good fit for software as a medical device. When is SaMD not an active device? There is a spectrum to consider, it is difficult to come up with one rule for all cases.
• If we do not explain why we are using a certain classification rule there will always be questions asked. We need to provide more contexts on how we are classifying a device.
• Without explaining classification rules, provided examples do not make much sense. Place the examples after the classification piece.
• Some of the examples provided are not clear. Identification of examples is an on-going process; it should be a living document, separate from the guidelines. Perhaps these could be turned into frequently asked questions.
• Provide examples of decisions that have been made regarding software in the past as a reference.
• Regarding IVDD risk factors - the suggested approach is a good approach; however we need to look at it closer, to clarify the risk categories of these software products. TGA guideline is a good start.
• There are many applications that may fall outside the SaMD definition. You can take everything including robotic surgery that has software residing on a cloud. This may not be a realistic approach.
• There may be no problem not regulating these, however what we are introducing is not a level playing field. If radiation planning software is not residing on the machine, it is regarded as a software as a service. The idea of a software as a service should be taken out of the guideline.
• Legal interpretation of 'sale' - the language does not imply money exchange; the concept of sale does not always mean selling a product. The word "distribute" describes the nature of providing a license to use software. There is a need to ask for a legal review of this interpretation.
• There is a real paradigm shift here. May be we need to step back and look at it again.
• We need a balance between regulations, patient safety, and to allow new technology development and availability.

Health Canada will consider the Panel's feedback to revise the draft document. Revised guideline will be posted for consultation in the summer of 2018.

Since comments are regarding a draft guidance document that is not publicly available, the record of proceedings (RoP) will be circulated for the Panel members' review and chair's approval. Health Canada will advise the members prior to posting the revised guidance.

FDA indicated their interest to have access to the public feedback in order to take this into consideration when revising the IMDRF documents.

Closing remarks / Adjournment (Chair)

The Chair thanked the members for their participation. The meeting was adjourned.

[Note: This record of proceedings will be submitted and approved in English by the Chair of the SAP-SaMD.]

References:

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.

International Medical Device Regulatory Forum (IMDRF), Software as a Medical Device Clinical Evaluation, IMDRF SaMD WG, 2017.

Medical Devices Regulations