Unpacking Health Canada's Roadmap for Machine Learning Medical Devices

Maya: Imagine a medical device that can learn, update, and improve on the fly without needing a new regulatory application every time. That is the future outlined in Health Canada's April 2026 publication, Pre-market guidance for machine learning-enabled medical devices. Welcome to AI in Medicine Smart Summaries. A quick note upfront: our voices are AI-generated, and this podcast is a summary of a public document.

Sam: I am Sam. Maya, this sounds like a massive shift. Usually, medical device regulation is entirely focused on locking down a final, unchanging product. Health Canada states its mission is helping the people of Canada maintain and improve their health, but practically, what does this specific guidance change on the ward or in the boardroom?

Maya: This document lays out the roadmap for getting machine learning medical devices approved. Rather than prescribing the required information for all scenarios, it outlines information for consideration using a risk-based approach on how to prove the device is safe, and critically, how to handle continuous software updates in the real world.

Sam: Let us start with the scope. What exactly falls under this guidance? Are we talking about smartphone apps or heavy-duty hospital imaging software?

Maya: It applies to manufacturers submitting a new or amendment application for Class II, III and IV machine learning-enabled medical devices under the Medical Devices Regulations. The guidance clarifies that an MLMD can be standalone software that meets the definition of a medical device, or a medical device that includes software. It can be an in vitro diagnostic device or a non-IVDD. Overall, risk classifications can range from Class I to Class IV.

Sam: So if I am a company building one of these tools, how do I actually start the process? Do I just send in my normal medical device paperwork and hope they figure it out?

Maya: No, you must be very explicit from the beginning. Manufacturers should clearly state that the device uses ML in their cover letter for all Class II, III and IV applications. If the device has a predetermined change control plan, they should clearly state that in the cover letter too. The guidance warns that excluding such statements could delay the application process.

Sam: That makes sense. A delayed application is a nightmare for any medtech company. Beyond the paperwork, what overarching philosophy does Health Canada expect these companies to follow?

Maya: They expect adherence to good machine learning practice, which helps ensure safe, effective and high-quality medical devices. But they also put a massive emphasis on a concept called SGBA Plus, which stands for Sex and gender-based analysis plus. The document states that biological, economic and social differences between diverse groups of people contribute to differences in health risks and outcomes, their use of health services and how they interact with the health system.

Sam: Wait, so is this regulatory document explicitly mandating that developers conduct an economic and social analysis for their software?

Maya: Not exactly. The economic part is mentioned as background context for health disparities. What the guidance actually expects is that manufacturers should apply SGBA Plus and consider the unique anatomical, physiological and identity characteristics of patients. It explicitly lists taking into consideration sex and gender, racial and ethnic minorities, elderly and pediatric populations, and pregnant people.

Sam: So it is not enough to just say your algorithm has a high accuracy rate overall. You have to prove it works for diverse demographics.

Maya: Correct. You need to collect and analyze disaggregated data on sub-populations in clinical studies, training data and test data. Any data used to develop the MLMD or demonstrate a device's safety and effectiveness should reflect the population for whom the device is intended. They specifically mention considering skin pigmentation and biological differences between sexes.

Sam: That is a huge detail for procurement officers. If a hospital is buying an AI triage tool, they can demand to see if the training data actually matches their local patient demographic. How detailed does the manufacturer have to be when describing the device itself?

Maya: Incredibly detailed. They need to provide a detailed description of the ML methods, training algorithms and architecture. The guidance lists ML methods like supervised learning, unsupervised learning, semi-supervised learning and reinforcement learning.

Sam: And does it cover modern generative AI, or just older predictive models?

Maya: It covers generative AI too. Under training algorithms, they list convolutional neural networks, logistic regression, support vector machines, but also generative adversarial networks, transformers, and generative pre-trained transformers.

Sam: Generative pre-trained transformers. So literally large language models running inside medical devices. If a doctor is using one of these models, how do they know why the software gave a specific output? Does the manufacturer have to explain the black box?

Maya: They are expected to try. The application must include an explanation of how the ML system works, the known factors influencing the output and the interpretation of the system behaviour, if available. They suggest providing feature attributions to ML model predictions, showing how the outputs of the ML model are impacted by changing input properties, and using saliency maps.

Sam: That will be crucial on the ward. The application also needs to explain how the software fits into the workflow, right? Are we talking about a tool that just flags a chart, or one that makes decisions completely on its own?

Maya: Exactly. Manufacturers must specify the clinical degree of autonomy, which is defined as the capacity to perform a clinical function with no or limited clinical user intervention. They also want to know all hardware requirements, such as CPU, GPU and RAM requirements, the operating system, and all compatible medical devices.

Sam: Alright, let us get to the absolute most groundbreaking part of this document. You mentioned it earlier. The predetermined change control plan, or PCCP. Medical software is historically locked down once approved. How does a PCCP change that?

Maya: A PCCP provides a mechanism for Health Canada to address cases where the regulatory pre-authorization of planned changes to ML systems is needed to address a known risk. If authorized, subsequent changes made according to the authorized PCCP do not require that you submit a medical device licence amendment application for a significant change. You just document those changes within your Quality Management System.

Sam: So a developer can update their algorithm without going back to the regulator every single time. That is a massive operational shift. What kind of changes are allowed under this plan?

Maya: The guidance states appropriate changes to list in a PCCP include those where pre-authorization addresses a known risk while upholding the benefits to the patient. A key example is the maintenance or improvement of performance to address the risk of ML performance degradation over time. This degradation can be due to changes to the environment, such as to the input data or the relationship between the input variables and the target variable.

Sam: But there have to be limits, right? They cannot pivot a dermatology tool into a cardiology tool using a PCCP.

Maya: Absolutely not. All modifications listed in a PCCP must ensure that the device continues to operate within its intended use. Changes listed in a PCCP should not include changes to the medical conditions, purposes or uses of an MLMD. Those still require a significant change application.

Sam: Okay, so how detailed does this predetermined plan have to be? What exact documentation do you have to hand over to Health Canada?

Maya: A PCCP consists of 3 components: a change description, a change protocol, and an impact assessment. The change description characterizes the baseline device design and performance envelope. For each proposed change, you need a detailed description of the motivation, rationale or trigger for the planned changes. Examples include performance thresholds, scheduled time intervals, or user feedback.

Sam: So you have to outline exactly what will prompt the software update. Do you also have to say who is pushing the update?

Maya: Yes, you have to describe who will make the changes. The document lists examples like the manufacturer, a qualified clinical user, a non-clinical user, the patient, or automatically by the software. You also have to describe where the changes apply.

Sam: Wait, what do you mean by where the changes apply?

Maya: The guidance notes changes might apply uniformly across all marketed devices, or non-uniformly across marketed devices based on unique characteristics of a clinical site or patient.

Sam: Wow. So a hospital in Toronto could end up with a slightly different AI model than a hospital in Vancouver, based on their local patient data, and that is completely fine as long as it was in the PCCP?

Maya: Quick note before we carry on. This spot is open for a sponsor. If your company builds or sells AI for healthcare and wants to reach the clinicians, health-system leaders and industry teams who listen to this show, the link to our sponsorship page is in the show notes.

Sam: And now, back to the document.

Maya: If it was pre-authorized, yes. The second component is the change protocol, which describes the set of policies and procedures that control how changes will be implemented. This requires modification procedures, like re-training, learning techniques, update triggers, and pre-update verification and validation methods.

Sam: It sounds like they want the entire software engineering playbook. What if an update goes wrong in the real world? Is there a safety net?

Maya: The change protocol must include corrective actions. This may include roll-back plans, backup and recovery procedures, retraining criteria and objectives, and customer communications. The third component is the impact assessment, which considers the collective impact of all proposed changes on the MLMD and the impacts on other elements of the clinical workflow, including on other medical devices.

Sam: Okay, let us pivot to risk management. Aside from an update failing, what specific risks is Health Canada looking out for with machine learning devices?

Maya: The risk analysis section is very comprehensive. Under erroneous outputs, they list false positive or false negative results, and incorrect information for use in a medical purpose. But they also explicitly call out generated outputs that are delusions, confabulated, inappropriate, false or misleading.

Sam: Delusions and confabulated outputs. That is directly addressing the hallucination problem in generative AI. You have to prove you have a risk control in place if your software hallucinates a diagnosis. What about technical risks within the algorithms themselves?

Maya: They mandate analysis of overfitting, which occurs when a model is fit to properties that are specific to the training examples, such as random noise, resulting in a model that does not apply to the general problem. They also list underfitting, which occurs when a model is not fit to all relevant properties of the population from the training examples.

Sam: It is striking to see data science concepts like overfitting and underfitting formally written into federal medical device guidance. Are there risks related to how human clinicians interact with the AI?

Maya: Yes, two very critical ones. First is automation bias, which occurs when a user's conclusion is overly reliant on the device output while ignoring contrary data or conflicting human decisions.

Sam: That is the classic scenario where a doctor blindly trusts the computer over their own judgment.

Maya: Right. And second is alarm fatigue, which occurs when a user is desensitized to alarms due to excessive exposure, which can result in missed alarms. If your AI throws an alert constantly, eventually the clinical team will just mute it.

Sam: I have definitely seen that happen on the ward. So how do companies prove their device is safe from all these risks? Let us talk about data selection. What does the guidance say about the data used to train the AI?

Maya: Manufacturers must provide descriptions of the training, tuning and test datasets used to develop and evaluate the ML system. This includes sample sizes with and without the condition, clinical characteristics, and demographic statistics. You must compare the prevalence within the dataset and the intended population. They also want to know if you used single versus multi-centre data, or personalized data.

Sam: What if a disease is extremely rare, and the manufacturer just cannot find enough real patient data to balance the dataset?

Maya: The guidance permits techniques to address data imbalances. You have to provide descriptions of specific sampling methods or data augmentation techniques used to address a dataset that has low disease prevalence, and provide a justification. They even mention data augmentation or imputation practices, like geometric transformations or synthetic generative outputs, intended to enhance the size and quality of datasets.

Sam: So developers can use synthetic generative outputs to train a medical device. That is a fascinating loop. Once the model is built, what are the testing requirements before it can be used on patients?

Maya: For testing and evaluation, you must provide evidence to support the performance for appropriate subgroups, including at the relevant intersections, for example according to identity factors, under-represented populations, clinical status, or clinical features like tissue density or lesion type.

Sam: Do they actually need to run clinical trials, or is bench testing on a computer enough?

Maya: It depends on the risk class. In a medical device licence application for a Class III or IV MLMD, manufacturers should provide the appropriate clinical evidence, including clinical validation studies, to support safe and effective clinical use. For a Class II MLMD, this information should be available upon request.

Sam: And I am assuming they cannot just test the model on the exact same data they used to train it?

Maya: Exactly. The clinical evidence requires confirmation that the study population is independent of the data used for ML system development, training and tuning. The rationale for the study design also requires comparison to standard of care, and stating the use of retrospective and prospective evaluations.

Sam: Okay, so let us say the device passes validation, gets approved, and is deployed in a clinic. How do the clinicians actually know what the limitations of the AI are?

Maya: That brings us to transparency. Health Canada defines transparency as the degree to which appropriate and clear information about a device is communicated to stakeholders. They state manufacturers should consider including a structured summary of the key ML system information in the labelling. The document notes this is sometimes referred to as a model card, data card or model facts.

Sam: A model card, like a nutrition label for the algorithm. What specific information needs to be on that label for the end-user?

Maya: The labelling should include instructions for the user on how to interpret the software interface. This includes the ML system output and any information provided to help users interpret each output, for example, saliency maps and confidence scores. It must also list known failure modes and data characterization limitations.

Sam: So the doctor can see the confidence score of the AI's prediction. What about the software updates we talked about with the PCCP? If the software is updating itself, how does the user know?

Maya: The device change information in the labelling must include a statement communicating that the device includes a PCCP or pre-authorized changes. It must communicate the expected update frequency, any requirements for the user to perform software updates, and notifications when a software update occurs and the impacts on device performance.

Sam: This is a huge amount of ongoing monitoring. What if something starts failing in the real world after deployment? Does the government have any emergency levers?

Maya: They do. Under subsection 36(2) of the Regulations, the Minister may, at any time, impose T&Cs on a licence, or amend those T&Cs. The goal of imposing or amending terms and conditions is to maintain safety and effectiveness under sections 10 to 20 of the Regulations, optimize benefits, and manage uncertainties.

Sam: So they can add conditions after the fact if they find an uncertainty in how the algorithm is performing?

Maya: Yes. The guidance gives an example: although overall evidence demonstrates an acceptable benefit-risk profile, the benefits weighed against the risks may be less known in certain population subgroups. The ongoing safety and effectiveness of marketed MLMDs may be strengthened by imposing T&Cs to manage uncertainties. However, before doing so, the Minister will consider if compliance with the proposed T&C is technically feasible and if there are less burdensome ways for those objectives to be met.

Sam: This whole document really shows a massive leap in regulatory thinking. They are recognizing that machine learning is a living system that needs continuous lifecycle management, not just a one-time stamp of approval.

Maya: Absolutely. The implementation of the Predetermined change control plan is the biggest takeaway here. It finally gives developers a structured, pre-authorized pathway to improve their algorithms and prevent performance degradation without getting bogged down in endless amendment applications for every single update.

Sam: It changes the economics of maintaining medical AI completely. For anyone buying, building, or regulating these tools, this guidance is required reading. We will put a link to the full document in the show notes. As always, remember this podcast is for informational purposes and is not medical advice. Thanks for listening.