How Should Multiple Models of Software Medical Devices Be Grouped for Overseas Registration?

For software medical device overseas registration, grouping multiple models into one submission is not a simple merger. It requires determining the product classification, intended use, and degree of difference according to the regulations of each target country. Companies should first confirm whether the product is regulated as a medical device in the target market, and then divide the registration units according to risk level. The key to grouped submission is proving equivalence among models, including consistency in core algorithm, clinical use, and safety and effectiveness. Unified technical documentation, performance verification, and risk management reports are typically needed to support the joint submission. At the same time, quality system, labeling, local representative, and post-market maintenance requirements must also be aligned. GHWP member states and markets in Southeast Asia, the Middle East, and Latin America have different requirements for registration unit division. Companies should systematically assess the reusability of existing NMPA, CE, and FDA documentation to avoid amendments or registration failure due to improper grouping. For software medical devices, grouping also involves version compatibility and update frequency considerations. Companies need to clarify naming rules, software version identifiers, and configuration management for each model, and describe them clearly in the technical files. A common risk is ignoring regulators' distinction between standalone software and embedded software, causing the grouping to be rejected. By planning the registration strategy in advance and allocating resources and time reasonably, duplicated work in multi-country registration can be significantly reduced. This article aims to help companies map out a complete path for grouped submission.

Key Summary

In overseas registration of software medical devices, grouped submission for multiple models is not a simple merger. It requires determining product classification, intended use, and degree of difference according to target country regulations. The key is demonstrating equivalence among models, including core algorithm, clinical use, and safety/effectiveness. Unified technical files, performance verification, and risk management reports are needed, along with aligned quality systems, labeling, local agents, and post-market maintenance. GHWP members and other markets have varying details. Companies should assess reuse of NMPA, CE, FDA documents and avoid grouping errors. Version compatibility and update frequency must be considered. Risks include ignoring regulatory differences between standalone and embedded software. Early strategy planning can reduce repeated work.

Applicable Scenarios and Core Questions

Software medical devices (SaMD) often have multiple models or versions, such as clients based on different operating systems, modules with different functional configurations, versions for different clinical scenarios, and implementations of the same algorithm on different hardware platforms. Before applying overseas, companies must first determine whether each model falls under the target country's medical device regulatory scope, then decide whether these models can be submitted as one registration unit.

The core question is whether the multiple models belong to the same registration unit. If regulators conclude that the intended uses, core algorithms, and clinical risks are not substantially different, they usually allow combined submission. Otherwise, separate submissions are required. Many companies mistakenly believe that similar product names are enough, ignoring differences in software architecture, algorithm versions, and operating environments—a major cause of amendments.

Therefore, before starting overseas registration, companies must conduct a systematic difference analysis of the multiple models and form a clear basis for dividing registration units. This basis should demonstrate to regulators that all models share the same safety and effectiveness evidence chain.

Registration Determination Logic

Step 1: Determine if the product is a medical device. Different countries have different definitions and classification rules. For example, the US FDA has a standalone SaMD classification, the EU MDR uses Rule 11 among others, and China's NMPA has its own definitions. Companies should assess each target market and determine risk class.

Step 2: Select the registration pathway according to risk class. Low-risk products may only require self-declaration or simplified registration; high-risk products require full technical document review and clinical evaluation. For multiple models, the risk class should be based on the highest-risk model or determined separately before grouping.

Step 3: Assess reusability of existing documentation. If the company already has NMPA registration, CE certification, or FDA approval, it should review whether these documents can directly meet target country requirements, especially for software version, clinical evidence, and risk management reports. If the core algorithm is consistent, most technical files can be reused, but local adaptation is needed for language, regulatory format, and standards.

Step 4: Confirm localization requirements. Every country has specific rules on labeling, local representatives, and post-market surveillance. Some countries require an authorized representative to be responsible for product safety; others require a local registrant. In grouped submission, the authorized representative's scope must cover all models, or certificate maintenance may be affected.

Documentation and Evidence

Technical files supporting grouped submission should be based on one "core" technical document with separate statements of differences for each model. This document should contain a general description, software architecture, core algorithm, intended use, and clinical improvements.

Key contents to prepare include:

• Software description document: describing functions, interfaces, and version management of all models.
• Risk management report: covering risk analysis, risk control measures, and residual risk evaluation for all models.
• Performance verification report: including functional verification, performance testing, safety testing, and interoperability testing, reflecting all models.
• Clinical evaluation or clinical evidence: to prove effectiveness and safety of each model, unless exempted.
• Cybersecurity statement: addressing security updates, data protection, and privacy controls.
• Labels and instructions for use: prepared separately or with a difference table when models vary.

These materials must be organized according to the target country's format and language, and naming and version identifiers for all models must be consistent.

Common Mistakes

• Grouping models with different intended uses, leading to requests for separation.
• Ignoring the impact of software version differences on safety and effectiveness, and simply merging.
• Lacking unified configuration management, so technical parameters of different models conflict.
• Failing to assign a local agent that covers all models, or leaving the agent's responsibilities unclear.
• Not customizing labels and instructions for the target country's language and regulatory requirements.
• Post-market surveillance plans not covering all models, leading to suspension or withdrawal of certificates.
• Defining grouping rules based on internal assumptions rather than accepted standards in the target country.

These errors usually trigger requests for additional information (amendments), prolong the registration cycle, and can even lead to failure. Internal review before submission is essential to ensure the grouping basis is sufficient.

Company Preparation Checklist

• List specifications and differences among all models to create a product matrix.
• Confirm the regulatory scope and classification of each target country, and designate a registration strategy.
• Compare existing technical files against target country requirements to identify gaps.
• Establish a unified software version naming rule and configuration management plan.
• Prepare a core technical document template applicable to all models.
• Engage or confirm a local agent and define its responsibilities and authority.
• Plan translation and localization of labels and instructions for use.
• Establish post-market surveillance and adverse event reporting procedures covering all models.

Following this checklist can help companies proceed systematically and reduce omissions and rework.

AIMEILI Regulatory Interpretation and Business Impact

In consulting projects, we find that companies often misjudge grouped submission as a shortcut to "save effort," overlooking the stringent equivalence requirements behind it. In fact, grouped submission demands stronger evidence management capability because if one model undergoes a significant change, the entire registration certificate may be affected.

Our recommendation is to conduct a target-country regulatory brief and product difference analysis early in the project, and clarify the grouping strategy. Do not start translating documents at the very beginning. Instead, build a "core evidence package" that identifies which content can be reused and which must be localized. For example, clinical evaluation is generally reusable, but labels, instructions for use, and use environment must be adapted to local language, culture, and standards.

Local agent and control over the certificate must be designed from the start of registration. If the agent lacks technical response capability, or the company cannot control change and renewal processes, the situation will become passive. For multiple models, a change may require re-review of the entire registration unit.

We advocate a "systematic registration" approach to manage multi-country projects, using one core document as the backbone and parameterizing adjustments according to target country requirements. This can significantly reduce repeated formatting and amendments. Grouped submission of multiple models is not a simple merger; it is a smart registration strategy.

Common Follow-up Questions

Can different operating platforms (e.g., iOS and Android) be submitted as one registration unit?

This depends on target country regulations. If the core algorithm and intended use of the two versions are exactly the same and the only difference is the platform, many regulators allow submission as the same registration unit. However, companies must explain in the technical file the impact of platform differences on performance and cybersecurity, and provide cross-platform validation data.

Can rule-based and deep-learning-based versions of the same algorithm be submitted together?

Usually not. The difference in core algorithms may lead to different performance profiles and clinical risks. Regulators will consider them as having different technical characteristics and will require separate clinical evidence. Therefore, it is advisable to submit them as separate registration units.

If a new model is added after registration, is a new submission required?

It depends on the extent of change and regulatory requirements. If it is a new configuration based on the same core algorithm, a change notification or supplemental filing may be enough. If it involves an expansion of intended use or a major algorithm update, new registration or a public announcement of change is generally required. Companies should define a change management strategy in advance to avoid affecting existing certificates.

Continue Reading

• How is the responsibility of an authorized representative divided for overseas registration of software medical devices?
• How should technical documents be organized for overseas registration of software medical devices?
• How to prepare performance verification materials for overseas registration of software medical devices?
• How to conduct post-market surveillance for overseas registration of software medical devices?
• Why does the registration timeline for software medical devices get extended?
• How to prepare technical documents for overseas registration of software medical devices?

This article is based on the AIMEILI registration practice question bank, the medical device international registration knowledge base, and publicly available regulatory information. For specific projects, the latest requirements of the target country's regulatory authorities and the product documentation basis shall prevail.