Change Management and Notification Procedures under REG-2024/08 in Israel

1. Key takeaways

Israeli procedure REG-2024/08, effective from 1 January 2025, defines which situations constitute a change (distinguishing significant from non-significant changes) and which situations require re-registration. The routing rule is: Class I and Class A devices may submit changes through the declaration route regardless of the scope of the change; products meeting the fast-track conditions may submit changes through the fast track; and minor or administrative changes to some Class III devices may also use the fast track. There are four typical situations that require re-registration rather than a change submission: a change of intended use, an increase in the risk classification, a change of the active ingredient in a combination product, and the addition of a new component to the device system. Getting this classification right before implementation is the core discipline of Israeli change management, because the route chosen determines whether the modified product remains legally covered by a registration while it is being placed on the market.

2. Legal basis

The table below summarises the instrument governing change submissions, its parent provisions, and the reference documents commonly used to judge significance.

3. Expert insights

The first principle of change management is classify first, act later: the classification must be completed before the change is implemented, not after implementation when the application is patched together afterwards. The reason is straightforward: if a situation is later found to require re-registration but was submitted as a change, the product, once modified, is being sold without registration coverage, which is close in character to unregistered sale. The exposure therefore arises at the moment of implementation, and no subsequent paperwork can fully cure it.

GRZAN classifies changes in four steps:

Step one, check whether the situation falls within the re-registration list. A change of intended use, an increase in risk classification, a change of the active ingredient in a combination product, and the addition of a component to the device system: these four categories go directly to a new registration. There is no discretionary space at this step; the list is determinative.

Step two, look at the product’s original route. Class I and Class A devices always submit changes through the declaration route, regardless of scope; products meeting the fast-track conditions use the fast track. The route follows the product’s existing eligibility, so it should be confirmed against the registration file before any submission is drafted.

Step three, judge significant versus non-significant. Where no mandatory Israeli guidance document exists, the logic of the European MDCG 2020-3 (for non-IVDs) and MDCG 2022-6 (for IVDs) may be followed (practical estimate). These two documents grade changes across dimensions such as design, materials, software algorithms, sterilisation methods, labelling and instructions for use, and as a judgement framework they are highly practical.

Step four, perform the notification duty. Section 15 of the Regulations requires the registration holder, upon becoming aware of a change to any matter listed in Section 3(a), to notify the Director General and the healthcare institutions that purchased the equipment as soon as possible; a proposed change must be submitted for approval under Section 6.

One frequent error is treating a software version upgrade as a non-significant change. If the upgrade changes algorithm logic, the coverage of indications, or safety-related functions, it usually constitutes a significant change; only a patch that fixes defects without changing functions or performance may fall into the non-significant category. Software should therefore always be classified separately from hardware changes, and the reasoning behind the classification should be written down before the upgrade is shipped. A disciplined file of classification decisions also protects the company in retrospect: when AMAR or the IRH later asks why a particular version was treated as non-significant, the answer is documented rather than reconstructed from memory, and the same logic can be reused for the next upgrade in the same product family.

4. Practical recommendations

• Establish a change classification committee: regulatory, quality and R&D functions jointly sign off, and the classification result is archived.
• Turn the four re-registration situations into a red-line list: R&D checks against it at the moment a change project is initiated, not before submission.
• Classify software upgrades separately: apply a binary test of whether algorithm logic, indications or safety functions are changed.
• Do not omit the notification duty: after a change is approved, notify the Director General and the healthcare institutions in the same cycle (Section 15 of the Regulations).

5. Verification checklist

• □ The change has been assessed against the four situations requiring re-registration
• □ The submission channel has been determined according to the product’s original route (declaration / fast track / standard)
• □ The significant / non-significant judgement has been completed and the basis for it has been archived
• □ Software version upgrades have been classified separately (algorithm logic / indications / safety functions)
• □ The notification duty of Section 15 of the Regulations has been performed (Director General plus healthcare institutions)
• □ Implementation of the change postdates approval, with no implementation before approval

Regulatory information verified as of 29 October 2026. The regulation names, numbers, publication dates and article numbers cited in this article were checked against official Israeli legal databases and authoritative public sources on that date. AMAR procedural documents are updated frequently, so before any formal submission please rely on the current version published on the website of the Israeli Ministry of Health.

How GRZAN can help. GRZAN provides medical device and IVD registration, quality system, authorised representative and local testing support for the Israeli market. Our team manages adverse event reporting and recall coordination with the MOH, and supports post-market vigilance obligations. Business enquiries: info@grzanglobal.com