Change Control and Notification for Registered Medical Devices in Iran

1. Key takeaways

Iran routes changes to already registered devices according to their degree of impact: major changes that affect safety and effectiveness must be re-filed, while ordinary changes can be recorded for the file or kept on record for inspection. GRZAN’s assessment is that the most common corporate mistake is to judge by the size of the change rather than by the nature of its impact — a seemingly minor change of material supplier, if it alters biocompatibility or sterilisation suitability, is a major change. The routing decision therefore has to be made on regulatory grounds, not on the intuitive impression of how large or small the modification appears to the engineering team, and the judgment has to be made before the change reaches production, not after, with the reasoning documented in the change file itself. Because the routing happens inside the company before anything reaches the authority, the decision table is the real compliance instrument here, and the quality of that table determines whether changes land in the right channel.

2. Legal basis

1. Change management practice: changes to the design, materials, manufacturing process or labelling of a registered product require evaluation, and major changes must be resubmitted — the specific classification criteria do not appear in any unified text published officially by Iran, and this is a practical estimate; the registration approval documents for the product concerned and the requirements of the competent authority prevail. Because no unified published criteria exist, the internal classification table a company builds for itself is the operative standard, and it should be written so that every change can be traced to a documented routing decision.
2. Law on the Administration of Medical, Pharmaceutical, Food and Beverage Affairs, FAOLEX LEX-FAOC227692, dated 1955-06-20, Article 3 (prohibiting unauthorised changes to composition or labelling). This prohibition is what elevates change control from a quality practice to a legal boundary in the Iranian market, particularly for labelling.
3. The change and risk management requirements of ISO 13485:2016 and ISO 14971:2019 — this is a practical estimate. These standards supply the methodological frame for evaluating changes and the risks they introduce, and they are the reference most manufacturers already work with, which makes them the natural basis for the internal routing rules.

3. Expert insights

Insight one: Article 3 lists unauthorised changes to labelling as a prohibited act in its own right. In Iran this is not an ordinary administrative defect but an act expressly prohibited by law. Labelling changes must go through the formal channel, and on this point Iran is stricter than most markets. Companies accustomed to treating label edits as trivial documentation updates should recalibrate their internal process for the Iranian market specifically, because an edit that would be a routine notification elsewhere is a prohibited act here if it is made without approval. The prohibition also means the approved label version must be archived and retrievable, since consistency can only ever be demonstrated against a reference document.

Insight two: the criterion of judgment is whether safety and effectiveness are affected, not the magnitude of the change. The same change can have a different impact on products of different risk classes. For Class D products the threshold at which a change triggers a resubmission is clearly lower than for Class A. A change routing rule that works for one risk class therefore cannot simply be copied to another, and each product family needs its own threshold documented rather than inherited from a neighbouring product line. The risk class of the product, in other words, is part of the routing input and belongs in the decision table itself.

Insight three: software changes follow an independent logic of judgment. Whether an algorithm update alters the intended use is the key question, and this question is not answered by the size of the code change. This point should be confirmed with the competent authority at the time of the first submission and fixed into internal procedures, so that later software releases do not have to be judged from scratch under time pressure, with the answer depending on whoever happens to be reviewing the release. Fixing the rule early also stops the company from renegotiating the standard with itself at every release.

4. Practical recommendations

1. Build a change classification decision table: list the judgment criteria separately for the six categories of design, materials, manufacturing process, labelling, software and scope of intended use, so that routing decisions are systematic rather than ad hoc and can be reproduced by different reviewers.
2. Use the nature of the impact as the basis of judgment: evaluate whether safety and effectiveness are touched, not the magnitude of the change, and document that evaluation for each change so the file shows the routing decision was reasoned, not assumed.
3. Route all labelling changes through the formal channel: never simplify a labelling change on the grounds that only wording was modified, because wording is exactly what the prohibition in Article 3 addresses, and the approved version should remain the single reference point for every future edit.
4. Agree software change rules in advance: clarify the criteria for judging algorithm updates at the time of the first submission, so that the standard is fixed before the first release that needs it and the company is not negotiating the rule while a release is waiting.

5. Verification checklist

• □ A classification decision table covering the six categories of changes has been established
• □ The basis of judgment is whether safety and effectiveness are affected, not the magnitude of the change
• □ Labelling changes are included in the formal change channel
• □ Software and algorithm update rules have been confirmed with the competent authority and fixed internally
• □ Change records are archived and can be presented during market surveillance spot checks

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 adverse event reporting and recall coordination with IFDA, and supports post-market vigilance obligations. Business enquiries: info@grzanglobal.com