How to Determine Product Classification for Overseas Registration of Software Medical Devices?

Software medical devices face a critical first question in overseas registration: how is the product classified in the target country? Classification determines the regulatory pathway, technical requirements, and post-market supervision intensity. This article from AIMEILI provides a systematic approach to classification determination, supporting manufacturers, distributors, CROs, and regulatory affairs teams.

Key Summary

When registering software medical devices overseas, product classification is the starting point for regulatory authorities in each country to assess the registration pathway, technical requirements, and post-market supervision intensity. Companies cannot directly infer the target country's classification based solely on NMPA or CE classifications. Instead, they should first confirm whether the software falls within that country's medical device definition, and then make a comprehensive judgment based on that country's classification rules, intended use, risk level, standalone software vs. embedded software form, and whether it has clinical decision support functions. During the determination process, key preparations include the intended use statement, algorithm logic description, risk management report, clinical evaluation or usability evidence, cybersecurity description, labeling and instructions, and local agent authorization documents.

Common risks include directly copying classification conclusions from other countries, ignoring localization rules, and confusing the category definitions of standalone software and hardware components. Enterprises should establish a core technical documentation library, map NMPA, CE, FDA, ISO 13485, or MDSAP materials, and perform localization conversion for target markets such as GHWP member countries, especially classification basis, clinical evidence, and labeling language. Once product classification is determined, it directly affects the applicant entity, scope of the quality management system, local agent responsibilities, and post-market update and change management.

Applicable Scenarios and Core Questions

The first question in overseas registration of software medical devices is often not "how to submit" but "how is my software classified in the target country?" This classification decision directly determines whether the registration pathway is a self-declaration, notified body review, or competent authority pre-approval.

Software medical devices cover a wide range, including diagnostic decision support systems that exist as standalone software, imaging processing software, patient monitoring data management software, and software embedded in hardware as a component of the device. Different countries have different classification rules for software medical devices, but most refer to the IMDRF SaMD framework when assessing risk levels.

There are typically three practical scenarios: first, a software product already holding an NMPA registration certificate is preparing to enter other markets; second, a software product already holding CE or FDA clearance is seeking registration in multiple GHWP member countries simultaneously; third, a product under development needs early planning for overseas registration strategy. In all these scenarios, product classification is the starting point and cannot be skipped. Many companies find that a classification conclusion in one country differs from another, not because the product is different, but because classification rules, intended use statements, and regulatory interpretations differ.

Therefore, determining the product classification of software medical devices for overseas registration is essentially a comprehensive judgment process combining "target country regulatory analysis + product technical feature matching + intended use constraints." Enterprises should invest sufficient effort in the early stages of a project to determine the classification basis, supporting evidence, and localization methods, which is more effective at reducing rejection or correction requests than blindly submitting registration.

Registration Classification Logic

Step 1: Determine whether the target country regulates the software as a medical device. Not all medical-related software is considered a medical device; some countries exclude software that is solely for lifestyle, sports recording, or health promotion. Therefore, companies should compare the medical device definition in target country regulations to confirm whether the software is intended for diagnosis, monitoring, treatment, mitigation, or prevention of disease, and whether it processes patient data and provides medical recommendations.

Step 2: Determine classification based on intended use and risk level. Countries usually have classification rules, for example, based on whether the product provides decisive clinical information, is invasive, delivers energy, or controls a medical device. Enterprises should write a clear, traceable intended use description, specifying the target population, use environment (hospital clinical use, home user use, or professional physician use), and whether it automatically generates diagnostic conclusions to assist decision-making. The way the intended use is described significantly affects classification results. For example, the same image reading software may be classified as lower risk if it states that a physician makes the final confirmation, whereas an automatic diagnostic function raises the risk level.

Step 3: Assess the reusability of existing certification materials. If a company already holds an NMPA medical device software registration certificate, CE-MDR or IVDR certificate, FDA 510(k) or De Novo authorization, or has passed ISO 13485 or MDSAP certification, these materials can serve as the technical basis for classification determination. However, note that classification conclusions cannot be directly copied; they must be mapped against the target country's classification rules item by item.

Step 4: Confirm the registration pathway and applicant entity. After a software product is assigned to different classes, the registration pathway may be self-declaration by the manufacturer, submission to the competent authority after capability verification, or submission by a local authorized representative. The applicant entity also involves the manufacturer itself, the EU headquarters for design and development, or an overseas subsidiary. Different countries have different requirements for manufacturer address and quality management system audits. The scope of authorization of the local agent or authorized representative should also be confirmed, as well as whether the full technical file, clinical evidence, and cybersecurity documents must be submitted before market launch.

Finally, all factors must be considered: technical files, performance validation reports, risk management, clinical evaluation or clinical evidence, labeling and instructions, local agent, authorized representative, and post-market maintenance requirements. This step is not simply translating existing documents; it also requires adjusting the format, language, applicable standards, cybersecurity, and real-world data requirements according to the target country's classification rules and registration acceptance criteria.

Documentation and Evidence

Classification determination for software medical devices requires a range of evidence, not just self-declaration. Enterprises should prepare a complete intended use description, including the functions implemented by the software, input data sources, output result types, target users, and use environment. This description must be consistent with the registration submission documents to avoid contradictions.

Risk management documentation is also critical. A risk management report based on ISO 14971 should clearly identify software-specific risks, such as algorithm bias, data misinterpretation, system failure, cyber attack, output errors, and the mitigation measures. The hazard identification in the risk management report should correspond to the risk level descriptions in the classification rules, which helps the competent authority understand the basis for the product's risk classification.

Performance validation and software confirmation materials include software requirements specifications, software test reports, algorithm validation data, usability engineering reports, and cybersecurity validation records. If the product involves machine learning or artificial intelligence algorithms, additional materials must be prepared, including training dataset descriptions, validation result sets, and external validation data of algorithm performance. Many countries, when reviewing classification, need to determine whether the software has the ability to self-learn and change its output, which may affect whether it can be submitted through the traditional software pathway.

Clinical evaluation or clinical evidence is another important pillar of classification determination. If the software involves diagnosis, screening, prognosis prediction, or treatment decision support, clinical evidence is usually required to prove its clinical effectiveness and safety. Existing FDA clinical trial data, CE-certified clinical evaluation reports, or real-world data from other countries can serve as a basis, but supplementary local clinical data may be required according to the target population, language, and cultural background. In particular, several GHWP member countries require clinical data to include local population samples or usability tests with local physicians.

Labeling and user documentation need to be language-converted and comply with local regulations. The language, units, medical terms, warnings, and symbols in the software interface must be localized. The classification review also checks whether the intended use description on the label matches the submission documents. The description must not arbitrarily expand the functional scope and avoid exaggerated expressions such as "all diseases," "automatic diagnosis," or "replace physician."

Local agent or authorized representative documents are also part of the classification submission. In most overseas markets, foreign manufacturers must designate a local agent, submit an authorization letter, quality management system certificate, and technical documentation. The local agent must assist in communication with regulatory authorities, receive post-market surveillance reports, and handle adverse event reporting. When selecting an agent, companies should not only consider price but also confirm that the agent is familiar with the classification context and registration requirements for software medical devices.

Common Mistakes

• Directly copying classification conclusions from other countries. For example, declaring a CE Class IIa product as the target country's Class IIa without checking the differentiated provisions in the target country's classification rules, leading to inconsistency between the submission and classification basis.
• Classifying based solely on the module name. For example, assuming that "image storage" or "information management" software is naturally low risk, while overlooking features such as automatic lesion marking or quantitative analysis that can trigger higher risk classification.
• Writing an overly broad or vague intended use description. Different diseases or use scenarios can lead to different classification results. Writing too broadly affects classification and may lead to complicated post-market review requirements.
• Ignoring software form differences. Standalone software and embedded software may be subject to completely different classification rules in different countries. Some countries classify embedded software together with the hardware, while standalone software is classified separately. Failing to distinguish these can lead to omissions or errors.
• Submitting applications with insufficient clinical evidence. For software products involving diagnostic decisions, authorities often require adequate clinical effectiveness and safety evidence. A common mistake is submitting performance test data as clinical evidence, which extends the correction cycle.
• Not incorporating cybersecurity requirements into classification evidence. Many countries have explicit cybersecurity requirements in classification files. If a company only mentions "data encryption" in the label without providing penetration testing or threat modeling reports, it may be considered unprepared.
• Localization limited to language translation without considering differences in terminology, standards, and clinical practices. Measurement units, reference ranges, disease codes, and diagnostic standards in medical software can vary by country, and ignoring these can affect classification and the speed of subsequent registration.

Company Preparation Checklist

• Confirm whether the software falls under the medical device definition in the target country's regulations, and record the relevant regulatory provisions.
• Draft a standardized intended use statement, clearly specifying the clinical purpose, user environment, and whether the output assists decision-making.
• Perform an initial risk classification self-assessment using the IMDRF SaMD framework, then compare with the target country's classification rules.
• Organize existing NMPA, CE, FDA, ISO 13485, MDSAP certificates and reports to establish an international registration core documentation library.
• Identify documents requiring localization: instructions, labels, user interfaces, clinical evidence, risk management reports, and cybersecurity documents.
• Sign agreements with the target country's local agent or authorized representative, confirming the agent's scope of responsibilities, and understand the registration process and fees in advance.
• Develop a clinical evaluation or clinical evidence generation plan. Different countries may require additional localized data, so budget should be reserved in the project.
• Clearly define the post-market maintenance plan, including adverse event reporting procedures, update and change notification clauses, and periodic safety update report requirements.

AIMEILI Insights

In assisting companies with multi-country software medical device registrations, AIMEILI most often encounters the misjudgment of "using one market's classification conclusion for all other markets." The differences in the boundaries and classification rules of software medical device definitions across countries exceed the expectations of most internal teams. Therefore, we recommend that companies do not skip the traceability analysis of classification conclusions before starting registration. Even if a product has been approved in one market, when entering a new GHWP member country, it is advisable to have a regulatory consultant familiar with local rules to re-evaluate the intended use, risk level, and applicable standards.

In the early stages of a project, the most important action is to define the product boundary. Write down the minimum set of software functions and optional modules, determine which versions belong to the same registration unit, and identify which additional features may lead to classification upgrade. Doing this work at the early R&D stage yields the greatest benefit. If you wait until software development is complete to adjust the intended use, it often means redoing part of the validation or even redesigning.

For document reuse, ISO 14971 risk management files, software development lifecycle documents, ISO 62304 software lifecycle process records, usability engineering reports, and cybersecurity design and validation reports are the most reusable materials across countries. However, clinical evaluation reports, instructions, user interfaces, and local usability validation must be localized and cannot be submitted as direct translations. For example, the algorithm thresholds validated in European or American populations may not be suitable for certain Asian populations, and authorities may require external validation data from local populations.

Local agents and certificate control are particularly risky for software products. Software updates are frequent, and some countries require manufacturers to apply for supplementary approval or submit change notifications before changes. If the local agent is not professional or the scope of authorization is unclear, the change process can be delayed, and in severe cases, the certificate may be suspended. AIMEILI recommends that companies clearly define in the contract the local agent's specific responsibilities in regulatory consultation, change submissions, post-market reporting, and regulatory inspections, while also retaining control over all original certificates and electronic archives.

To reduce repeated document preparation and correction risks in multi-country registration, the best practice is to establish a management model of "core technical documentation + target country difference table." Core documents cover product specifications, risk management, software validation, clinical evidence, cybersecurity, and manufacturing information. The difference table records specific differences per country in classification, clinical requirements, language, standards, agent, and post-market requirements. Each time a new country application is made, start from the difference table and generate only the local documents, rather than retranslating and reorganizing the entire technical file. This significantly reduces time and minimizes omissions.

Frequently Asked Questions

What is the difference between writing "for auxiliary diagnosis" and "for diagnosis" in the intended use for classification?

The difference is significant. In most countries' classification rules, auxiliary diagnosis may be classified in a lower risk category, while diagnostic decision-making or automatic diagnostic conclusions are classified in a higher risk category. If the label clearly states "auxiliary diagnosis" and the physician retains final judgment, clinical evidence requirements and classification risk are correspondingly lower. However, the company must ensure that the product's actual functions align with the description. Deliberately downplaying functions to achieve a lower classification carries compliance risks after market launch.

If the software is a driver or control program for hardware, is it necessary to register separately as a software medical device?

Usually no separate registration is required. Embedded software is considered part of the hardware medical device and is registered together with the hardware. However, if the same manufacturer sells the software separately or allows it to be used with multiple brands or types of hardware, the standalone software attribute becomes prominent and separate classification and registration may be required. Additionally, if embedded software includes independent decision-making functions, some regulators may require separate review of that software module's impact.

What are the differences in classification determination between AI self-learning software and ordinary software?

Many countries are developing special rules for machine learning and AI medical devices. For software that has the ability to self-learn, update algorithms automatically, and change behavior after deployment, classification determination tends to be stricter. Regulators focus on training data, validation data, algorithm locking mechanisms, performance drift monitoring, and update management. Companies should identify early whether the product falls into this category and proactively provide algorithm governance and cybersecurity descriptions during classification to avoid extensive supplementary requests due to conceptual ambiguity.

Source: Compiled based on AIMEILI Registration Practice Database, Medical Device International Registration Knowledge Base, and public regulatory information. Specific projects should be based on the latest requirements of the target country's regulatory authorities and the product documentation.