SaMD and AIeMD Exclusion from the Reliance Pathway

1. Key takeaways

Scope Exclusions item 5 of MDS-G030 (V1.0 / 2026-09-09) places software as a medical device (SaMD) and artificial intelligence-enabled medical devices (AIeMD) in a position where they may be excluded, with determination based on intended use, risk level, novelty, complexity and other regulatory considerations the SFDA identifies. Being excluded from the reliance pathway does not mean being barred from Saudi Arabia — what is closed is the 35–60 working-day fast lane, while the conventional MDMA channel remains open as usual. For such products the SFDA maintains dedicated guidance: MDS-G23 Guidance on Software as a Medical Device, V1.0 / 2018-04-09, and MDS-G010 Guidance on AI and Machine Learning (ML) technologies based Medical Devices, V1.0 / 2022-11-29 (serial number MDS-G-010-V1/230103). Products with prominent innovative attributes will also need the Annex (11) Innovative Medical Device Summary Form of MDS-REQ1 V6.0. Regulatory information verified as of 29 October 2026.

• SaMD and AIeMD can be excluded from reliance based on intended use, risk level, novelty, complexity and other considerations.
• Exclusion closes the 35–60 working-day fast lane only; the conventional MDMA channel stays open.
• Dedicated guidance applies: MDS-G23 (2018-04-09) for SaMD, MDS-G010 (2022-11-29) for AI/ML devices.
• Innovative products also file the Annex (11) Innovative Medical Device Summary Form.

2. Legal basis

The following instruments define the exclusion, the software-specific guidances and the innovative-device summary obligation that accompany them.

3. Expert insights

1. What is closed is the lane, not the market

Many manufacturers read this exclusion as software products no longer having a route into Saudi Arabia, confusing the pathway with access itself. MDS-G030 only says the SFDA will not fast-track a software product merely because it was approved elsewhere, and the 35–60 working-day column does not apply. The conventional MDMA channel is open to every compliant application; for SaMD and AIeMD the question there is not whether to file but how long it takes and how thick the dossier must be. The teams truly blocked by this clause are those counting on a fast landing on a single overseas approval without a complete Annex (3) technical file prepared.

2. Why software products are harder to rely on

Reliance carries an implicit premise: the relied-upon object does not change easily after approval. Hardware devices satisfy it — once the production line is validated, what is made today is technically and in risk terms the same thing that was reviewed three years ago. Software does not. Version iterations, algorithm updates and drift in training-data distribution all open a gap between the software approved back then and the software running on users’ devices today; for AIeMD designed to keep learning after launch, the gap accumulates over time. By writing novelty and complexity into the determination criteria, the SFDA is pointing at exactly this: judging whether a piece of software is still the product that was originally approved requires independent professional evaluation, and that evaluation cannot be completed by borrowing someone else’s conclusion. This is also why, even for software products not theoretically excluded, Application Requirements item 5 preserves the right to request additional information. Read the other way, the clause gives Chinese manufacturers a usable clue: a software product with a low version frequency, a fixed algorithm and no post-market learning sits closer to a hardware-like stable product, and the case for its stability becomes more persuasive to the SFDA; a product that keeps iterating should invest its effort in the quality of the conventional-channel dossier rather than in arguing whether reliance applies.

3. Three alternative strategies, tiered by the product line’s novelty

First, make the novelty evidence the main evidence: organise the material under MDS-G23 and MDS-G010, covering the version-control strategy, the algorithm update management mechanism and post-market change trigger thresholds, and submit the Annex (11) Innovative Medical Device Summary Form. Second, split the combination: if the product is a hardware-plus-software combination, first check whether the hardware satisfies the general eligibility of the reliance pathway — where the software component can be decoupled from the hardware at system level, the hardware body can still be assessed separately under the normal conditions; conversely, combination products are also on the SFDA’s additional-information list. Third, reserve the time budget: even on the conventional MDMA, build in the round-trip time for SFDA deficiency requests and do not schedule to the rhythm of an ordinary hardware product. The reliance pathway overview is at https://www.grzan.cn/regulations/saudi/sfda-reliance-pathway-mds-g030-12 ; the argumentation backbone of the Essential Principles of Safety and Performance (EPSP) can follow https://www.grzan.cn/regulations/saudi/essential-principles-of-safety-and-performance-24 .

4. Practical recommendations

• Run a software component inventory before filing: for every software module in the product package, mark whether it is SaMD and whether it contains AI/ML components.
• Where AI/ML components exist, prepare per MDS-G010 the algorithm description, the training and validation dataset descriptions, and the post-market change-control strategy.
• Put the version-naming rules into labels and IFU so that a unique version can be traced back from the label, easing later post-market surveillance locating.
• For combination products judge divisibility first: assess the hardware part separately where it can be decoupled from the software, and do not let one software module slow the whole product line.
• For software devices with clear innovative attributes, complete the Annex (11) Innovative Medical Device Summary Form early rather than waiting for the SFDA to ask.
• Build the time budget on the conventional MDMA and reserve round-trip time for deficiency requests in the schedule.
• Maintain UDI data per product line with a model-to-version mapping table kept consistent with Saudi-DI.

5. Verification checklist

• □ It has been confirmed whether the product constitutes SaMD or AIeMD, and the applicability of the reliance pathway is excluded accordingly
• □ Current versions of MDS-G23 and MDS-G010 have been obtained and their clauses compared item by item
• □ The Annex (11) Innovative Medical Device Summary Form has been completed in the current format
• □ Algorithm description, dataset descriptions and the post-market change-control strategy are archived
• □ Version-naming rules are reflected in labels and IFU with traceability
• □ Feasibility of split submission has been assessed for combination products and the conclusion recorded
• □ The time budget follows the conventional MDMA account, with round-trip time for deficiency requests reserved
• □ Model and version data in Saudi-DI are consistent with GHAD

How GRZAN can help. GRZAN provides medical device and IVD registration, quality system, authorised representative and local testing support for the Saudi Arabian market. Our team manages SFDA MDMA applications across classes, prepares reference-approval dossiers, and supports post-market vigilance obligations. Business enquiries: info@grzan.com