Registration of SaMD and Software-Containing Medical Devices in Iran

1. Key takeaways

Standalone software (SaMD) and software-containing devices in Iran are classified under the same risk framework, but the composition of the documentation differs markedly: software is required to submit lifecycle process documentation rather than physical performance data. The judgment of GRZAN is that the greatest risk in software projects is under-determining the software safety classification — whether the software is determined as Class A or Class B/C under IEC 62304 directly determines how much process documentation must be submitted, and an under-classification will lead to deficiency requests once the reviewer reaches the lifecycle materials. Determining the safety class correctly at the start is therefore cheaper than defending an under-classification at the end. In software projects the safety class determination is therefore the first milestone, not a formality attached to the end of classification.

• The device risk class and the IEC 62304 software safety class are two separate determinations, and both must be stated with their reasons in the dossier.
• A device may fall into risk Class B while its software is determined as IEC 62304 Class C, so equating the two scales leads to an insufficient volume of documentation.
• The seven categories of lifecycle process documentation are requirements, architecture, detailed design, verification, validation, configuration management and problem resolution, mapped item by item to the determined safety class.
• For artificial intelligence software, whether a model update changes the intended use determines whether the change is handled as a filing or as a re-application.
• The Persian-language interface is a hard, directly visible item: the software interface, error messages and help documents must all be Persianised and are inspected at the sample review stage.
• Where a corresponding ISIRI standard exists for software lifecycle processes, the ISIRI determination prevails.
• The change rules agreed with the authority at first submission should be hardened into the internal change management system.
• An under-classification discovered during review forces rework of the entire lifecycle documentation set, not a single supplementary document.
• The version and version number management rules should be established before first submission, since lifecycle documents reference them throughout.

2. Legal basis

On the software lifecycle standard: IEC 62304, covering medical device software and software lifecycle processes, is an international standard generally accepted by the Iranian competent authority. Where a corresponding ISIRI standard exists, the ISIRI determination prevails — this is a practical estimate. Software teams should therefore verify the ISIRI catalogue position before deciding which standard edition to cite in the dossier.

On the risk classification framework: software products are classified within the A/B/C/D framework, with classification based on the intended use and field of application declared by the manufacturer. This is documented in public industry database records; the official document number has not been released through public channels, and this is a practical estimate.

On language: the requirement for a Persian-language interface and instructions for use is likewise a practical estimate as to its formal source, but it is directly verifiable at the sample review stage, which makes it a de facto requirement in practice regardless of documentation status.

3. Expert insights

Insight 1: the software safety class and the device risk class are two dimensions. A device may fall into Class B as a device, while its embedded software is determined as IEC 62304 Class C. Companies frequently equate the two scales, which results in an insufficient volume of process documentation. GRZAN requires that both determinations be explained separately in the dossier, each with its judgment and its reasons, so that the documentation set matches the stricter of the two scales rather than the looser one. The two scales exist for different reasons and must be documented with different reasoning even when the outcome is intuitive.

Insight 2: artificial intelligence software faces continuing compliance pressure from algorithm changes. Whether a model update changes the intended use determines whether the change is handled as a filing or as a re-application. This question should be confirmed with the competent authority already at the time of the first submission, and the answer should be hardened into the internal change management system, so that later updates follow a rule that the authority has already accepted rather than one invented under time pressure. A rule confirmed once at submission time removes an entire category of uncertainty from every later update.

Insight 3: the Persian interface is a hard, visible item. The software interface, error messages and help documents all need to be Persianised, and this is inspected directly at the sample review stage. Unlike documentary deficiencies, an unpersianised interface cannot be argued around; it is visible to the reviewer immediately and produces a rejection or a resubmission without further discussion. Persianisation should therefore be treated as a release criterion of the software build, not as a documentation task.

4. Practical recommendations

• State both determinations separately: give the device risk class and the IEC 62304 software safety class each their own judgment and reasons.
• Complete the seven categories of process documentation according to the safety class: requirements, architecture, detailed design, verification, validation, configuration management and problem resolution.
• Complete the seven categories of process documentation according to the safety class: requirements, architecture, detailed design, verification, validation, configuration management and problem resolution, rather than a generic template.
• Agree the algorithm change rules up front: at the first submission, clarify which updates require a filing and which require a re-application.
• Complete the Persian interface and help documents together: deliver them as one synchronised package to avoid rework at the sample stage.

5. Verification checklist

• □ The device risk class and the software safety class have each been determined and recorded separately
• □ The lifecycle process documentation has been completed according to the IEC 62304 safety class
• □ The change rules for algorithm and model updates have been confirmed with the competent authority and hardened internally
• □ The Persian interface, error messages and help documents have been completed
• □ The software version and version number management rules have been established

How GRZAN can help. GRZAN provides medical device and IVD registration, quality system, authorised representative and local testing support for the Iranian market. Our team manages IFDA registration applications, prepares reference-country dossiers, and supports post-market vigilance obligations. Business enquiries: info@grzanglobal.com