Common Reasons for Additional Information Requests in Overseas Registration of Software Medical Devices

Key Summary

During overseas registration of software medical devices, receiving a request for additional information (deficiency notification) is a common step. It is essentially the regulatory authority's further confirmation of the product's safety, effectiveness, and compliance. Common reasons for deficiencies include: unclear product classification leading to incorrect registration pathway selection, such as submitting SaMD as general software rather than a medical device; mismatch between technical documents and actual product functions, with insufficient descriptions of core algorithms, intended use, clinical evaluation, or evidence chains; incomplete quality management system evidence, especially software lifecycle, cybersecurity, and change management processes not conforming to ISO 13485 or target country special requirements; lack of localization of labels, instructions, and user interface according to target country language, regulations, and cultural habits; unclear division of responsibilities between local agents or authorized representatives, causing delays in communication and document submission; and missing post-market surveillance plans or failure to meet continuous compliance requirements of GHWP member countries. To reduce deficiencies, enterprises must conduct target country regulatory research early in the project, establish a cross-departmental mechanism to close data gaps, prioritize reuse of validated core technical documents, and ensure localization evidence and agent responsibilities are properly implemented to improve registration efficiency.

Applicable Scenarios and Core Issues

This article is intended for manufacturers, CROs, and regulatory affairs teams currently conducting overseas registration of software medical devices. Software medical devices generally refer to standalone software or software embedded in a medical device, including algorithms and mobile applications used for diagnosis, treatment, monitoring, or health management. When submitting registration applications to overseas regulatory authorities, receiving requests for additional information is not rare; it is a standardized feedback on the completeness, consistency, and sufficiency of the submission.

Enterprises often wonder: why do we still receive deficiency letters even though we prepared documents following domestic registration or mature systems like CE/FDA? The core issue is not the quantity of documents, but whether the regulatory expectations of the target country for the special form of “software medical device” are accurately understood. Different countries or regions have significant differences in software classification, risk level, clinical evaluation requirements, cybersecurity requirements, and post-market surveillance requirements. Especially among GHWP (Global Harmonization Working Party) member countries, although the framework is converging, details vary substantially.

If we dig deeper, deficiency reasons can be categorized into four types: logical gaps, lack of evidence, insufficient localization, and missing sustainability plans. Enterprises need to establish a self-check mechanism against target country regulations, guidelines, and review practices before submission, rather than passively responding after receiving a deficiency notice. Starting from applicable scenarios, this article provides judgment logic, document preparation, common errors, and checklists to help registration teams reduce deficiency rates and accelerate approval.

Registration Judgment Logic

Step 1: Determine whether the product falls within the target country's medical device regulatory scope.

Not all health-related software is considered a medical device. For example, apps used only for lifestyle management or health education may not be medical devices, while software used for disease diagnosis, screening, treatment decision support, or monitoring physiological parameters is likely to be a medical device. Enterprises need to make judgments based on the target country's definitions, rules, and case guidance, and must not arbitrarily apply the classification results from China NMPA or EU MDR.

Step 2: Determine risk class and registration pathway.

The risk class of software medical devices is typically based on the intended use and the impact of processed information on patients, users, or public health. GHWP member countries generally reference the IMDRF (International Medical Device Regulators Forum) SaMD framework, but risk classes and pre-market review categories may be adjusted. Enterprises should identify target-country-specific classification rules for software, such as whether certain decision support software is classified as Class II or III, whether clinical evaluation is required, and whether substantial equivalence to similar products is accepted.

Step 3: Assess the reusability of existing documents.

Enterprises should carefully inventory existing NMPA registration dossiers, CE technical documentation, FDA 510(k) or De Novo submissions, and ISO 13485/MDSAP certification records to determine which content can be directly converted and which needs localized regeneration. Core technical documents such as requirements specifications, software architecture, risk management reports, verification and validation records, generally have high reuse value, but language, standard references, clinical evidence, and labeling must be adapted to target country requirements.

Step 4: Confirm local agent, authorized representative, and post-market maintenance arrangements.

Many GHWP member countries require overseas manufacturers to designate a local agent or authorized representative, giving them responsibilities such as receiving regulatory communications, handling adverse events, assisting with inspections, and responding to queries. If deficiencies relate to unclear agent obligations, they often result in incomplete submissions or delayed feedback. In addition, post-market surveillance plans and periodic update commitments are key audit points and cannot be omitted.

Documents and Evidence

Complete registration documentation for software medical devices generally includes administrative documents, technical documentation, quality management system evidence, clinical or performance evaluation evidence, and labeling. Administrative documents cover application forms, authorization letters, agent agreements, and legal manufacturer certificates. Technical documentation must reflect software design development, requirements traceability, architecture, safety and effectiveness verification, algorithm validation, and performance evaluation, usually following standards like IEC 62304.

Evidence chain is critical. Regulators expect to see traceability from “intended use” to “software requirements” to “implementation and verification”. Common points that companies often overlook include: management of data interfaces, cleaning of real-world data, control of algorithm bias, threat modeling and vulnerability management for cybersecurity, and the impact of software updates and version changes on registration files. Missing or insufficient content in these areas will directly lead to deficiency letters.

Clinical evaluation or clinical evidence cannot simply be considered sufficient by saying “literature exists.” For high-risk decision support software, regulators may require validation data from the target population or ethnic group, or confirmation of algorithm robustness in different clinical scenarios. If overseas clinical data is used, the representativeness of data, ethical compliance, and localizability must be assessed. If clinical data is deemed unnecessary, a full scientific rationale must be provided.

Labels, instructions, and user interface are key areas reviewed by assessors. Labels for software medical devices include information displayed on the screen, accompanying electronic instructions for use, warnings, and patient information. If the target country requires a local language and the company only provides English or Chinese, a deficiency letter is common. In addition to translation accuracy, attention must be paid to whether terminology is understandable to ordinary users and technical staff, and whether the order, color, and readability of warning information meet local regulations.

Post-market surveillance plans and periodic update documentation are also part of the registration file. Enterprises should describe how they will collect real-world performance data, adverse event reports, customer feedback, and establish procedures for triggering corrective and preventive actions and updating registration files. If omitted or insufficient, it is considered a lack of commitment to long-term safety, leading to deficiencies.

Common Errors

• Directly applying NMPA or FDA classifications without understanding target country-specific classification rules, leading to wrong registration pathway and review channel.
• Technical documents inconsistent with actual software functions, such as claims for algorithms, modules, or intended use that do not match the actual version or delivery package.
• Ignoring software version management, failing to clearly state the submitted version number, release history, and future update commitments, making it impossible for regulators to assess the impact of changes.
• Quality management system certificates not covering software design and development activities, or ISO 13485 certificate scope not including the target product, causing system evidence to be questioned.
• Insufficient clinical evaluation evidence, providing only summaries or literature abstracts, lacking complete trial protocols, statistical analysis reports, or target population data.
• Lack of target country language versions for labels and instructions, or translations that are misleading, inaccurate, or omit warning information.
• Local agent or authorized representative agreements incomplete, without clear responsibility boundaries, information transmission timelines, and document retention obligations, affecting review communication.
• Post-market surveillance plans too general, without specific performance indicators, data collection methods, and periodic evaluation mechanisms, failing to meet continuous compliance requirements.

Enterprise Preparation Checklist

• Form a dedicated registration task force including regulatory, software R&D, quality, clinical, and local representative members, with clear responsibilities and deadlines.
• Conduct target country regulatory research, collect the latest classification guidance, registration requirements, fee schedules, and review timelines, and create a gap analysis table.
• Define a unified “core clinical claim” and “intended use statement” for the product across global markets to avoid inconsistencies that trigger disputes.
• Establish a “master technical file” divided into reusable modules and target-country localization modules, with version control.
• Prepare risk management reports in advance, incorporating cybersecurity risks and safety updateability into the risk management framework.
• Organize software development lifecycle documents, ensuring traceability of requirements, design, coding, testing, and defect management records.
• Sign formal agreements with intended target country local agents, clarifying their roles and obligations in deficiency communication.
• Prepare post-market surveillance plans and sample SOPs, including performance monitoring, adverse event reporting, periodic safety updates, and change notification processes.
• Assign translation tasks to professional translators with medical device backgrounds, and conduct medical and technical reviews.
• Conduct mock reviews using an internal checklist before submission, marking any doubtful evidence and promptly supplementing or preparing explanation letters.

AIMEILI Perspectives

From our experience assisting companies with global registration reviews, deficiency letters for software medical devices are often not due to lack of capability, but rather insufficient prediction of micro-differences in target country review logic. The most common mistake is using evidence from similar functional software as substitute, while ignoring the impact of algorithm training data, clinical environment, ethnicity differences, and user habits on safety and effectiveness.

The most urgent early task is not to prepare the full set of documents immediately, but to conduct a strict applicability assessment: first confirm whether the product is indeed a medical device in the target country, then make classification and pathway decisions, and finally start document reuse and localization. Skipping these steps and directly translating domestic documents for submission is the most common source of deficiencies.

Which documents can be reused? Requirements specifications, system architecture, module design, algorithm principles, internal verification records, and IEC 62304-compliant development process reports can generally be reused based on a globally unified core technical file. Which must be localized? Clinical evidence, if relying on single-region data, needs assessment and supplementation with data representative of the target country's population or ethnicity; labels, instructions, training materials, cybersecurity management processes, user interface language, and adverse event reporting forms must be recreated according to target country requirements.

A local agent is far more than a “recipient.” In our projects, some deficiency delays were due to agents lacking technical background and being unable to communicate effectively with reviewers. Choosing a partner who can explain software technical details and involving the agent early in document preparation can significantly reduce communication costs. Additionally, control of the certificate is very important—apply in the manufacturer's name and have the agent assist with maintenance to avoid certificate invalidation due to agent relationship changes.

Changes and renewals are also often overlooked. Software updates are frequent, and frequent changes may trigger new reviews. We recommend designing a “global change assessment matrix” during initial registration, understanding in advance whether each type of change requires notification or new clinical data, and linking this process with ISO 13485 change control. For multi-country registration, adopting a “one master file, multi-country localization” strategy reduces redundant work and deficiency risk. First focus resources on preparing the core master file, then quickly adapt based on each country's feedback, rather than writing a complete new set of documents for every country. This reduces inconsistencies and improves approval rates.

Frequently Asked Questions

If the product has already obtained NMPA registration in China, can the entire dossier be directly reused for overseas registration?

No, it cannot be directly reused. NMPA registration documents reflect Chinese regulations and review requirements, and their clinical evaluation, labeling, risk management, cybersecurity, and post-market surveillance provisions differ from overseas markets. However, NMPA's systematic documents, such as technical requirements, verification reports, and quality system records, can be used as core technical files for translation and localization, then supplemented with gap items based on target country guidelines. Even if the content is complete, the format, referenced standards, and presentation of evidence still need to be re-reviewed and adjusted.

What types of documents are most commonly requested in deficiency letters for software medical devices?

The most commonly requested documents include: quality system records covering the software development lifecycle, more detailed algorithm validation data (especially subgroup analysis for specific clinical populations), cybersecurity vulnerability management plans, target country language versions of labels and instructions for use, local agent authorization letters and contact information, and sample post-market surveillance activity reports. In addition, if the product contains artificial intelligence/machine learning algorithms, regulators may also require an explanation of training data sources, bias testing, and continuous learning mechanisms.

How can we predict whether a target country will accept our existing clinical evidence?

The best way to predict feasibility is to conduct pre-submission communication with the target country regulatory authority (if such a mechanism exists) or consult with consultants experienced in local reviews. Generally, three points are considered: whether the clinical evidence originates from the target population or has sufficient justification for extrapolation, whether the trial design precisely matches the intended use of the device, and whether real-world data and long-term safety records are available. If the evidence mainly comes from Chinese or Asian populations, and the target country requires local representative data, bridging studies or local real-world data may be needed.

How should we uniformly handle deficiency requests when submitting applications in multiple countries?

It is recommended to adopt the concept of a “globally coordinated document package,” establishing a master technical file as the foundation and treating each country's specific requirements as incremental items. When a deficiency notice is received from one country, first analyze whether the feedback also applies to other countries; if so, immediately update the master file and plan coordinated corrections for other applications. Conduct regular global regulatory intelligence tracking and update the gap analysis table. Maintain regular communication between local agents and technical leads to ensure that deficiency requirements from different countries are not contradictory or duplicative.

Continue Reading

Previous: How to Prepare Technical Documentation for Overseas Registration of Software Medical Devices?

Next: How to Prepare Performance Verification Documentation for Overseas Registration of Software Medical Devices?

Recommended:

• How to Conduct Post-Market Surveillance for Overseas Registration of Home Medical Devices?
• How to Group Multiple Models for Overseas Registration of Home Medical Devices?
• How to Prepare Registration Dossiers for Overseas Registration of Software Medical Devices?
• How to Prepare Technical Documentation for Overseas Registration of Software Medical Devices?
• How to Prepare Performance Verification Documentation for Overseas Registration of Software Medical Devices?
• How to Prepare Registration Dossiers for Overseas Registration of AI Medical Devices?

Return to FAQ Center

News & Contact AIMEILI

Content Review and Applicability Boundaries

Content author: AIMEILI Regulatory Editorial Department
Professional review: AIMEILI Medical Device International Registration Project Team
Source principle: Priority is given to official regulatory authorities, international organizations, standards organizations, and public regulatory materials; industry media and project experience are used only as auxiliary references.
Applicability boundary: This article is for preliminary understanding, document preparation, and project planning, and does not replace the formal requirements, testing conclusions, or legal opinions of target country regulatory authorities.