How to Prepare Overseas Registration Dossiers for Software Medical Devices

Overview

Preparing overseas registration dossiers for software medical devices starts with clarifying the product's regulatory attributes and risk classification, then structuring the dossier according to the target country's registration route. The first step is to determine whether the software is a medical device, based on its intended use, algorithm logic, and risk level. Next, evaluate whether existing NMPA, CE, FDA, ISO 13485, or MDSAP documentation can be reused; do not simply translate.

Key Summary

Commonly required documents include product technical documentation, software description and architecture, risk management reports (ISO 14971), cybersecurity statements, performance verification and validation records, clinical evaluation or clinical evidence, labels and instructions for use, quality system documents, and local agent or authorized representative arrangements that comply with target country requirements. When registering in GHWP member countries and markets in Southeast Asia, the Middle East, and Latin America, special attention must be paid to multi-country reuse of technical files and localization conversion, such as language, regulatory differences, local agent responsibilities, and post-market maintenance requirements.

The risks most often overlooked by companies are incorrect classification, incomplete evidence chains, failure to appoint a qualified local agent, and unclear allocation of rights and responsibilities between the certificate holder and the agent. Before preparing documents, conduct a gap analysis to confirm which documents are common, which need to be rewritten, and to plan for subsequent changes and renewal processes, to avoid refusal or requests for corrective action due to insufficient or non-compliant documentation.

Applicable Scenarios and Core Issues

Software medical devices, especially standalone software as a medical device (SaMD), are becoming a growth area for Chinese companies expanding overseas. However, software differs significantly from traditional hardware in the logic and focus of documentation preparation. The first question is often not 'how to prepare documents' but 'whether my product is considered a medical device in the target country.' If this determination is wrong, all downstream documentation may proceed in the wrong direction.

Applicable scenarios include: domestic software products with NMPA registration certificates seeking entry into Southeast Asia, the Middle East, Latin America, GHWP member countries, and other markets; companies preparing to apply for registration under the EU MDR or the US FDA; and companies evaluating registration feasibility in multiple countries and hoping to create a core set of reusable documents. In all scenarios, the registration dossier must be based on a clear product definition, intended use, technical characteristics, and risk classification.

Core questions include: What are the criteria for software classification? What registration pathways exist in the target countries? To what extent can existing domestic or other regional registration documents be reused? How should software-specific issues such as cybersecurity, data privacy, algorithm updates, and clinical evaluation be reflected in the registration documents? What responsibilities should the local agent or authorized representative assume? These questions directly determine the document preparation strategy and workload.

Regulatory Classification Logic

The first step in overseas registration for software medical devices is not to immediately organize documentation, but to conduct a product and regulatory matching analysis. Companies should use the classification rules or guidelines issued by the target country to determine whether the software is a medical device. For example, the FDA has a clear framework for SaMD, the EU MDR has MDCG guidelines, and China, Japan, Korea, and Southeast Asian countries have their own classification lists. The key to the determination is whether the software's intended use involves disease diagnosis, treatment, screening, monitoring, or other medical scenarios, and whether its output has a material impact on patient or clinician decisions.

After confirming it is a medical device, the second step is to determine the risk class. Different countries have different methods for risk classification, but they generally depend on the degree of impact on patient safety. High-risk software may require rigorous pre-market review, while low-risk software may follow self-declaration or simplified pathways. The class determines the scope and depth of the required documents, for example, clinical evidence requirements vary significantly.

The third step is to identify the registration pathway. For the FDA, low-risk software may be submitted through 510(k); if no predicate exists, De Novo may be required. Under the EU MDR, a notified body is usually involved. Most GHWP member countries adopt frameworks similar to the MDR or IMDRF, but specific procedures and timelines differ. Companies should check the target country's regulatory authority website to confirm whether to apply directly to the national drug authority or rely on a local agent or authorized representative to submit.

The fourth step is to evaluate the reusability of existing documents. ISO 13485 quality system certificates, MDR technical documentation, FDA submission files, and Chinese NMPA registration files may all be used in the target country, but each item must be checked for differences. For example, the FDA may accept IEC 62304 documentation but require alignment with cybersecurity guidance; Southeast Asian countries may require English versions, and some Middle Eastern countries require notarized translations. Reuse is not copying; identify which sections need rewriting, updating, or supplementing.

The fifth step is to clarify the applicant entity and local agent arrangement. Most overseas countries require a local registered entity as the certificate holder or a qualified local agent. This arrangement must be finalized from the beginning, because agent documents, powers of attorney, and quality system interfaces are part of the registration file. The agent will also be involved in subsequent changes, renewals, and post-market reporting, so it is not enough to appoint a nominal representative at the last minute.

Documentation and Evidence

The core of the software medical device registration dossier is to demonstrate safety, effectiveness, and quality control. Basic documents include product technical specifications, software description documents, system architecture diagrams, development process documents, test plans and reports, and software version and unique device identification information. These documents should objectively reflect the software design inputs, outputs, verification, and validation activities.

Risk management documents are particularly important for software registration. Companies should establish a risk management process in accordance with ISO 14971, and organize risk analysis, risk evaluation, risk control measures, and residual risk evaluation. Software risks may arise from algorithm errors, incomplete data, misleading user interfaces, cybersecurity vulnerabilities, and other areas. Therefore, the risk management document should be linked to the software development lifecycle (IEC 62304) to form a traceable chain.

Performance verification and validation records form the main body of the evidence chain. Companies need to provide functional testing, performance testing, interoperability testing, software verification and validation records, and descriptions of the test environment. For software involving artificial intelligence or machine learning, special requirements such as training data sets, validation data sets, algorithm performance, and robustness should also be considered. Test data must be authentic and complete; do not fabricate data for the sake of registration.

Clinical evaluation or clinical evidence is key to improving the success rate of registration. For medium- and high-risk software, the target country may require clinical data to demonstrate that the intended benefit can be achieved in the target population and intended use environment. If clinical use data already exists, organize it into an internationally acceptable summary; if not, companies should design feasible clinical evaluation or clinical trial plans and pay attention to ethical and data protection requirements. Low-risk software may sometimes satisfy the requirement through literature analysis or comparison with equivalent products.

Cybersecurity and privacy protection documents have become rigid requirements in overseas registration in recent years. Companies need to prepare cybersecurity risk management documents, threat analyses, control measure descriptions, and comply with target country requirements for personal information and health data, such as the GDPR, relevant data protection laws, or specific regulatory guidelines. Software security updates and vulnerability management mechanisms must also be documented in official files.

Labels and instructions for use must comply with the language and format requirements of the target country, including product identification, intended use, contraindications, warnings, precautions, instructions for use, version information, and manufacturer and agent information. Some countries also require physician manuals or patient versions. Do not simply translate; adapt to local regulations and cultural context.

Quality system documents are the cornerstone of the registration application. ISO 13485 certificates, quality manuals, procedure documents, internal audit and management review records, and supplier and partner management documents are usually reviewed by regulatory authorities. If the target country recognizes MDSAP, companies may prioritize preparing MDSAP certification to enhance credibility and reusability.

Documents related to the local agent are also indispensable, including powers of attorney, agency agreements, proof of agent qualifications, and regulatory commitment letters. Some countries require original supporting documents and notarized translations. The agent's scope of responsibilities, contact details, and post-market commitments must be clearly stated in the documents.

Finally, the post-market surveillance plan is also part of the registration dossier, including adverse event reporting procedures, customer complaint handling processes, active monitoring plans, and periodic safety update reports (PSURs). Companies need to develop a compliant post-market maintenance plan for each target country and demonstrate to the regulatory authority that the mechanism is in place.

Common Mistakes

• Failing to confirm the regulatory status of the product in the target country, either by packaging all market expectations as medical indications or, conversely, incorrectly classifying medical software as a health management product, leading to off-target documentation.
• Ignoring the target country's risk classification rules and relying only on domestic or EU classification, resulting in incorrect submission pathway and missing suitable low-risk channels.
• Directly copying NMPA or CE documents without aligning with target country regulatory updates, local language, and clinical standards, leading to rejection or frequent requests for corrective action.
• Insufficient evidence on software cybersecurity, data privacy, and algorithm transparency, which goes against the latest guidelines from authorities such as the FDA or MDR.
• Underestimating the importance of clinical evidence, claiming 'no clinical data needed' without adequate justification, or failing to refer to the target country's special requirements for SaMD clinical evaluation.
• Choosing a local agent arbitrarily without verifying qualifications, capability, and regulatory experience, resulting in invalid authorization documents or an agent unable to fulfill post-market obligations.
• Neglecting control over certificates and registration certificates. If the certificate is held by the agent, termination of cooperation may lead to certificate invalidity or difficulty in transfer, impacting market access.
• Lack of change and renewal planning. After software version updates, failing to initiate change applications in advance leads to inconsistency between the certificate and the marketed version, and even regulatory violations.

Pre-submission Checklist

• Determine the target countries and identify their medical device regulatory regulations, classification rules, and registration fees. Compare the product against the classification guidance of each target country item by item and document the determination.
• Complete a multi-country registration feasibility assessment, including intended use, risk class, available registration pathways, clinical data needs, estimated timeline, and budget.
• Organize existing quality system documents, verify whether ISO 13485 covers software products, and consider whether to obtain MDSAP certification or additional declarations of conformity.
• Build a core document package, including software technical documentation, architecture, IEC 62304 lifecycle records, risk management, and performance verification and validation reports.
• Translate and localize labels, instructions for use, key user interface prompts, and registration application documents according to target country language requirements; do not omit content.
• Appoint a local agent or authorized representative, sign a formal agreement, and clearly define the scope of authorization, responsibilities, certificate control, and post-termination handling.
• Conduct a gap analysis, compare existing documents with target country requirements, and list documents that need to be added, updated, or rewritten.
• Establish a post-market surveillance program, including complaint handling, adverse event reporting, PSUR preparation, and periodic update mechanisms, and designate responsible positions.

AIMEILI Regulatory Interpretation and Business Impact

Many companies approach us with the typical misconception that holding a domestic Chinese certificate or a CE certificate means overseas registration is only a matter of translation. In reality, for software medical devices, especially when entering GHWP member countries and emerging markets, the biggest pitfalls are often 'incorrect classification' and 'missing links in the evidence chain.' A small classification error can lead to a completely different pathway, resulting in corrective action requests at best and rejection at worst. Therefore, we recommend that companies invest sufficient time upfront in market and regulatory analysis, not only looking at their own national rules but also referencing the International Medical Device Regulators Forum (IMDRF) and major country guidance to anticipate regulatory expectations.

We particularly emphasize 'reusable but not copied.' International standard documents such as ISO 13485 system files, IEC 62304 development records, and ISO 14971 risk management documents are usually reusable across countries, but specific requirements for cybersecurity, clinical evidence, and local agents vary widely. Companies should first build a 'Global Core Dossier' and then add local chapters for each target country. This avoids starting from scratch and prevents non-compliance from direct translation.

The local agent and certificate control are issues that must be thought through clearly. The agent is not just a recipient for document submission; they are responsible for receiving regulatory notifications, handling adverse events, and accepting inspections. If the agent lacks capability or has conflicting interests, the company faces significant risk. We recommend specifying in the contract: the registration holder information, agent change mechanisms, termination conditions, certificate ownership rights, and data access rights. In addition, companies should consider future changes and upgrades during product design and establish an internal change evaluation process to ensure every new version can be marketed compliantly within the certificate scope, rather than remedying after the fact.

Multi-country registration should leverage homologous documents but should not bundle all countries into a single process. Our consulting experience shows that the most effective approach is to divide the registration project into regional axes: for example, establish a high-quality dossier under the MDR first, then make regional adaptations under the GHWP member countries or Southeast Asian common frameworks, and finally make local adjustments in specific countries. This significantly reduces the risk of redundant work and corrective action requests, and facilitates centralized management of agent relationships, registration progress, and post-market obligations across different countries.

Common Follow-up Questions

If a software version is updated, does the registration dossier need to be resubmitted?

It depends on the nature of the update. If the update only modifies interface text or fixes an insignificant bug, it may be handled through a change notification or simplified procedure. If the change affects algorithm logic, intended use, input/output definitions, or core safety logic, a new change application or supplementary submission is usually required. Companies should proactively create a change plan for software versions, including version naming rules, risk assessment, scope of impact, and post-change verification and validation records. Especially under the FDA and MDR frameworks, failing to declare a substantial update may render the certificate invalid.

If a software product has no clinical data, can it still be registered overseas?

This depends on the software's risk class and intended use. Low-risk software based on well-established algorithms may satisfy requirements through literature arguments, risk control measures, and existing clinical consensus. However, medium- and high-risk software, particularly SaMD used for diagnosis or treatment decisions, will likely require clinical evidence from at least one target population. Companies should research early in the project the types of clinical evidence accepted by the target country, such as clinical trials, real-world data, literature analysis, or equivalent device comparisons. If evidence is insufficient, consider adjusting the intended use or designing supplementary clinical trials; do not wait until the regulatory review to add data, as this will significantly lengthen the timeline.

How should overseas local agents be selected and managed?

The qualification and capability of the local agent are important factors for registration success. Companies should prioritize agents familiar with software medical devices, with a good record with the target country's regulatory authority, and able to provide comprehensive post-market services. Verify their business license, service scope, past cases, and stability before signing an agreement. For management, establish a two-way communication mechanism so all regulatory notifications, adverse event reports, and update documents are transmitted promptly. Regularly evaluate agent performance and retain the right to terminate or replace. Particular attention should be paid to certificate control: ideally, keep the registration certificate supplementary page or necessary technical document control in the name of the manufacturer or an overseas legal entity, to avoid being constrained by the agent.

Source and Applicability

Source: Compiled from the AIMEILI Registration Practice Bank, 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 authority and the product documentation basis.

Published: 2026-08-03 11:44; Updated: 2026-08-03 11:44.

Content author: AIMEILI Regulatory Editorial Team; Professional review: AIMEILI Medical Device International Registration Project Group. This article is intended for preliminary understanding, documentation preparation, and project planning, and does not replace formal requirements from target country regulatory authorities, testing conclusions, or legal opinions.