A medical AI project does not qualify for SR&ED simply because the model is novel, the dataset is large, or the product needs a Health Canada submission. The useful question is narrower: did the team face a scientific or technological uncertainty that available knowledge could not resolve, then test possible explanations through experiment or analysis?
That distinction matters for imaging, diagnostics, and clinical decision software because the same development program can contain eligible experiments, routine engineering, and regulatory work.
Start where the expected method stopped working
Consider a team whose imaging model performs well with data from one hospital but loses sensitivity on images from another scanner or patient population.
If established calibration, preprocessing, and training methods solve the problem, the work may be routine engineering. If the team cannot explain the failure using knowledge reasonably available to it, the problem may present a technological uncertainty.
The team might test whether acquisition parameters, annotation differences, class imbalance, scanner artefacts, or model architecture explain the change in performance. Each experiment needs a reason, an observable result, and a clear connection to what the team tried next.
The CRA's current eligibility guidance describes SR&ED as work aimed at scientific or technological advancement and carried out through systematic investigation or search by experiment or analysis. A product objective alone does not answer that test.
Data work follows its purpose
Medical AI teams spend substantial time labelling, cleaning, harmonizing, and reviewing data. Some of that work may directly support an eligible experiment. Routine data preparation and normal operations are excluded.
Creating another standard training set does not become SR&ED because a model will use it. A focused dataset built to test why performance fails under a specific clinical condition may be support work if its extent matches the needs of the experiment.
Keep the reasoning visible. Record the failure being investigated, why the selected cases can test it, how the reference standard was set, and what the result changed. Our article on routine data collection explains this boundary in a broader medical-research context.
Regulatory evidence answers a different question
Health Canada's current guidance for machine learning-enabled medical devices covers safety and effectiveness evidence across the product lifecycle. It discusses data selection, development and training, testing, clinical validation, transparency, and post-market monitoring. It also describes predetermined change control plans for certain planned model changes.
Those requirements do not determine SR&ED eligibility.
A validation study may confirm that a finished model meets a known specification. That can be important regulatory work without being experimental development. The SR&ED question is whether the team had to generate new scientific or technological knowledge because it did not know how to reach the required result.
One protocol can contain both types of work. Separate the experiment that addresses the uncertainty from conformity testing, documentation for the licence application, deployment, and routine monitoring.
Preserve the experiment history clinicians already create
Medical AI teams often have useful evidence in model cards, experiment trackers, code history, error analyses, protocol versions, annotation instructions, and performance reports. Those records become more useful when they show the logic between iterations.
What could the team not achieve at the start? Which explanation did it test? What happened? Why did the next experiment change?
A list of model runs without that reasoning can look like ordinary optimization. A short decision log can show how the team tested its hypotheses and what it learned, including why an approach failed.
Success is not required. The CRA's guidance states that success or failure in meeting the project objective does not determine whether the work satisfies the advancement requirement. The work still needs the uncertainty, experimental approach, and supporting evidence.
If your team is developing medical AI, diagnostics, or imaging software, a review of SR&ED for medtech companies can help separate the experimental work from the engineering and regulatory work around it. To discuss the facts of a project, contact MITRAS through the consultation form.