Software Devices and MLMD Submissions in Canada

1. Key takeaways

Medical devices incorporating software are submitted in Canada through the same Class I to IV pathway as any other device, and the dossier must include software life-cycle documentation and risk management evidence. For machine learning-enabled medical devices (MLMD), Health Canada has issued dedicated pre-market guidance; however, the publication date and exact scope of that guidance are pending verification, and this article does not state any date that has not been verified. The practical consequences are two: software submissions follow the ordinary classification rules and ordinary dossier logic, with the software-specific content layered on top; and for MLMD products, planning should proceed from the verified regulatory baseline while treating the MLMD guidance requirements as pending verification until the official text is obtained.

• Software-containing devices follow the standard Class I to IV pathway under Schedule 1.
• Software life-cycle documentation and risk management evidence are dossier requirements.
• IEC 62304 is the customary method standard (consensus standard, not a Regulation provision).
• Instructions for use are a mandatory label item under section 21(1)(i).
• Algorithm change management should be described at submission and planned against amendment fee tiers.
• The MLMD pre-market guidance date and scope are pending verification.

2. Legal basis

The sources for this article mix verified Regulation provisions, verified Health Canada page content, one consensus standard, and one item explicitly marked as pending verification. Where the official text of the MLMD guidance could not be confirmed, the item is recorded on the list of unverified sources rather than stated as fact.

3. Expert insights

Insight 1: software is not a separate classification, but it can change the classification result.

Canada has no standalone SaMD category. The classification of software is determined by the Schedule 1 rules applied to its intended use and risk, under the same rules as physical devices. Software can nonetheless move a classification, because embedding software changes what the device is used for and how it acts: diagnostic software that drives a clinical decision is evaluated under the rules as they apply to that intended use, not under a special software rule. The consequence for dossier preparation is that the intended-use statement must be written carefully, since it drives both the classification judgement and, downstream, the evidence requirements. Classification should be worked at the same time as the intended use is finalised, so that the two are settled together rather than one being corrected after the other.

Insight 2: software life-cycle documentation follows IEC 62304 as the customary method standard (consensus standard).

IEC 62304 is a consensus standard, not a mandatory provision of the Regulations. Its role is to provide the methodological framework of software life-cycle processes — planning, requirements, architecture, detailed design, implementation, integration, verification and maintenance. The documentation effort should scale with the software safety classification the standard assigns: more demanding documentation for higher safety classes, proportionate documentation for lower ones. Writing the documentation to the safety class keeps the submission proportionate and credible; padding a low-risk software product with the full document set of a high-risk one adds cost without adding persuasiveness, while under-documenting a high-safety-class product invites deficiency requests that cost far more than the documentation would have.

Insight 3: instructions for use are a mandatory labelling item for software devices.

Under section 21(1)(i), the label must include instructions for use — measured for decorative contact lenses against safe use, and for other devices against safe and effective use. For software devices, the instructions are typically delivered electronically, and electronic delivery does not soften the obligation: the content must still satisfy the provision, and the language requirements must still be determined under section 23. Software teams sometimes treat the user interface, the help system and the labelling as separate workstreams owned by different functions; the Regulation treats them as one compliance surface. Agreeing early which content is the instructions for use, where it is delivered, and in which languages prevents the common late-stage discovery that the electronic content and the regulatory obligations do not match.

Insight 4: algorithm change management must be described at submission.

For products containing adaptive algorithms, the dossier should explain how algorithm updates are controlled. That explanation determines how subsequent changes are handled: whether a change is processed as a licence amendment (under the procedures relating to sections 34, 68.13 and 68.14) or whether it triggers a new application — which directly affects the amendment fee tier (4,470 / 11,369 / 16,251 Canadian dollars). The control description should cover how updates are validated before release, how the change is documented, and how the safety and effectiveness conclusions from the original submission remain valid. An adaptive algorithm without a change-control narrative leaves the reviewer unable to predict the regulatory path of future versions, and leaves the manufacturer unable to forecast the cost of its own product roadmap.

4. Practical recommendations

• Classify the software under the Schedule 1 rules; do not apply SaMD concepts as a separate category.
• Organise the software documentation around the life-cycle processes, with depth proportional to the safety class.
• Prepare the instructions for use under section 21(1)(i) and determine the language requirements under section 23.
• Describe the algorithm change management scheme at submission and plan it together with the amendment fee tiers.
• Implement the MLMD guidance requirements only after obtaining the official Health Canada text, not on the basis of secondary articles.

5. Verification checklist

• □ The software classification has been determined under the Schedule 1 rules.
• □ The software life-cycle documentation is organised by safety class.
• □ The instructions for use have been prepared under section 21(1)(i).
• □ The language requirements have been determined under section 23.
• □ The algorithm change management scheme is described and planned against the amendment fee tiers.
• □ The MLMD guidance requirements are marked as pending verification and no unverified content has been relied on.

Regulatory information verified as of October 28, 2026.

How GRZAN can help. GRZAN provides medical device and IVD registration, quality system, authorised representative and local testing support for the Canadian market. Our team manages Health Canada Medical Device Licence and MDEL applications, prepares risk-classified dossiers, and supports post-market vigilance obligations. Business enquiries: info@grzanglobal.com