Change Control After Listing: Major and Minor Changes Under GN-10

1. Key takeaways

GN-10, Guidance Notes on Changes to Listed Medical Devices, divides changes to a listed device into 2 categories: major changes require prior approval, and minor changes require notification. The test is not the technical difficulty of the change. The test is whether the change affects the safety, performance or intended use of the device.

That distinction decides the sequence of events, not merely the paperwork. A major change must be approved before it is implemented, which means the change control system has to hold a release until a regulatory decision arrives. A minor change may proceed and be notified afterwards, which means the notification is a recording obligation rather than a gate.

Software is where this classification is most often mishandled. Software changes frequently and continuously, so the question of whether a given release is major or minor arises repeatedly rather than once. Algorithm iteration, interface updates and the addition of newly compatible models can each constitute a change that requires prior approval, and none of them looks like a change to the product in the way a hardware modification does.

2. Legal basis

GN-10 sets the framework, in its current version verified to 29 October 2026: major changes require prior approval and minor changes require notification. The MDD publication Overview of the Medical Device Listing Process in Hong Kong, uploaded on 8 October 2025, states the same rule in its change application section. Clause 5.10 of GN-01, updated and issued on 1 September 2026, provides that failure to comply with additional conditions may result in removal from the list. Software and artificial intelligence requirements sit in the technical reference documents: TR-007, Technical Reference Document on Medical Device Software and Cybersecurity, updated with a Chinese version issued on 1 September 2025, and TR-008, Technical Reference Document on Artificial Intelligence Medical Devices, updated with a Chinese version issued on 2 October 2025.

The legal basis has two layers worth separating. GN-10 governs the classification and the procedural route. GN-01 clause 5.10 supplies the consequence for failing to follow it, because removal from the list is available where additional conditions are not complied with. A change control failure can therefore escalate from a procedural irregularity to a status loss.

3. Expert insights

Change management is the continuous permission mechanism of a listing. A listing is not a one-off certificate; it is an approval of a specific configuration of a product. Any deviation from the scope as originally declared has to travel through the GN-10 channel. Together with renewal, change control forms the lifecycle management of the listing, and the two interact: an unnotified change becomes visible at renewal.

Software products are the high-risk area for change management. Changes to traditional hardware are discrete events, while changes to software are a continuous process. Where the quality system does not define the classification rule in advance, every iteration requires an ad hoc judgement, and ad hoc judgements under delivery pressure tend to conclude that no filing is needed. That is how a systematic under-reporting pattern develops rather than an isolated error.

The consequence of failing to notify goes beyond retrospective filing. GN-01 clause 5.10 provides that non-compliance with additional conditions may result in removal from the list. An unnotified major change discovered during an inspection or a complaint investigation is a serious matter, because it is evidence that the change control system did not function, not merely that one filing was late. The distinction matters: a late filing can be remedied, while a finding that the system failed cannot be undone by submitting the missing form.

Change classification is linked to the model consistency clause of the accelerated approval scheme. If a change alters the expression of the model or product identifier, an equivalence statement must also be submitted under paragraph 11 of the notes to the accelerated approval scheme. Manufacturers that treat a model rename as a labelling matter rather than as a regulatory event discover this requirement late, usually while preparing a tender response.

Ambiguity should be resolved in advance, not at the point of release. Where a change sits close to the boundary between major and minor, the practical solution is a written position recorded in the change file, supported by the reasoning and, where necessary, a query to MDD. A documented judgement made before release is defensible; a judgement reconstructed after an inspection is not.

4. Practical recommendations

• Define the rule in advance. State in the quality management system documentation which changes are major and which are minor, and include worked examples for the categories the product actually generates.
• Keep a change review record. Document the classification decision and its basis for every change, so that the reasoning can be produced as evidence during an inspection.
• Manage software by version. Map each released version to a GN-10 classification outcome and maintain a version-to-decision table that the regulatory and engineering teams both use.
• Approve major changes before implementation. Do not release a change until approval has been obtained, so that a notified-only position is never created by default.
• Submit equivalence statements where identifiers change. Where a change alters the model or product identifier expression, prepare the statement required by paragraph 11 of the accelerated approval scheme notes at the same time.

5. Verification checklist

• □ Classification rules for major and minor changes defined in the quality system documentation.
• □ Written classification record held for every change.
• □ Prior approval obtained before implementation of any major change.
• □ Minor changes notified as required.
• □ Version-to-decision table established for software products.
• □ Equivalence statement submitted where model or identifier expression changed.
• □ Notified changes reconciled with the file ahead of renewal.

Regulatory information verified as at 29 October 2026 against the official sources listed under legal basis; where those sources are updated, the latest published version prevails.

How GRZAN can help. GRZAN provides medical device and IVD registration, quality system, authorised representative and local testing support for Hong Kong, China. Our team coordinates local responsible persons, import and wholesale dealer licensing, and supports post-market vigilance obligations. Business enquiries: info@grzanglobal.com