How to Organize Technical Documentation for Overseas Registration of Software Medical Devices?

To organize technical documentation for overseas registration of software medical devices, the core approach is to first determine whether the target country regulates the software as a medical device, then select the registration pathway and applicant entity based on risk classification. Companies should confirm the intended use, algorithm logic, clinical benefits, and risks of the software, determine whether it falls into Class IIa, IIb, or a higher category, and verify whether existing documentation under NMPA, CE, FDA, or ISO 13485 can be leveraged.

Key Summary

Technical files typically include product description, software description, requirements specifications, architecture design, risk management report, cybersecurity documentation, clinical evaluation or performance verification evidence, labeling, instructions for use, and a post-market surveillance plan. For GHWP member states, Southeast Asia, the Middle East, and Latin America, priority should be given to reusing validated core technical documents, followed by localization according to local regulations, such as language translation, local standard differences, registration entity requirements, local agent, and authorized representative arrangements. The most common risks are ignoring the impact of software updates on registration and failing to maintain a complete verification traceability chain. It is recommended to establish software version control, a requirements traceability matrix, and a change evaluation process before project initiation, and to confirm registration document formats and submission deadlines with experienced local agents to avoid amendments or registration failure due to improper documentation.

Applicable Scenarios and Core Issues

When taking software medical devices abroad, the first question is not "how to write documents" but "whether the software is regulated as a medical device." Definitions vary significantly by country; some adopt the IMDRF SaMD framework, while others provide local classification guidance. If the judgment is wrong, all subsequent documentation may be wasted.

Applicable scenarios include standalone software, embedded software, software as a component of a medical device, and mobile applications and cloud algorithms used for diagnosis, treatment, monitoring, screening, prediction, and other purposes. Different products have different regulatory attributes and corresponding technical file requirements.

There are three core questions: first, how to describe the software's intended use and clinical benefits; second, how to confirm the software's risk classification; third, whether existing documentation can be accepted by the target country. Only after clarifying these three questions can documentation work begin.

Companies often overlook "software version" and "change control" in the early stages. Unlike hardware, software does not have a fixed physical form; each update may change functionality, algorithms, or intended use. If the technical file describes only one version while the software continues to iterate after market launch, the registration certificate will become inconsistent with the actual product.

In addition, many companies equate "technical files" with "source code and development documents," which is a misconception. Regulators focus on evidence of software safety and effectiveness, not the code itself. Therefore, documentation should be organized around risk management and clinical evidence.

Registration Decision Logic

The registration decision logic should be divided into four steps. Step one: determine whether the software falls within the target country's medical device regulatory scope. Step two: determine the risk classification. Step three: assess the reusability of existing documentation. Step four: confirm the local registration pathway and applicant entity.

The first step is based on the software's intended use, whether it is used for disease diagnosis or treatment, whether it provides medical information, and whether it affects individual patients. If the software is only for health management or lifestyle advice, it may not be considered a medical device.

The second step, risk classification, mainly refers to the classification rules or decision trees published by the target country. For example, under the EU MDR, software that manages patient data and provides treatment recommendations may belong to Class IIa or IIb; high-risk decision software may reach Class III. The US FDA categorizes software into three classes based on function.

The third step, reusability assessment, focuses on reviewing existing NMPA registration materials, CE technical documentation, FDA 510(k) or De Novo submissions, ISO 13485 system files, and MDSAP audit reports. If these documents are complete, data are truthful, and they do not conflict with target country requirements, they can significantly reduce documentation costs.

The fourth step involves local registration pathways. For example, GHWP member states such as Saudi Arabia, Indonesia, Thailand, and the Philippines may require a local agent, local clinical data, or local testing. Companies need to understand submission methods, review timelines, and fees in advance to avoid delays caused by unclear pathways.

It is recommended to create a "registration decision matrix" that lists target countries, regulatory categories, required documents, agent requirements, review times, and amendment risks in a single table as a project management baseline.

Materials and Evidence

Technical documentation for software medical devices should cover the entire product life cycle and can be divided into five categories based on the logical chain.

1. Product and Software Description

Include software name, model, version number, indications, intended users, operating environment, hardware dependencies, algorithm overview, and input/output data definitions. This section should clearly define the software boundary and avoid confusion with hardware devices.

2. Requirements and Design Documents

Include user requirements, system requirements, software requirements specifications, architecture design, detailed design, interface design, database design, safety functions, and cybersecurity controls. Documents should maintain requirements traceability, ensuring every requirement is linked to design implementation and verification records.

3. Risk Management Documentation

Include the risk management plan, risk analysis, risk control measures, residual risk evaluation, and the risk management report. Software risks should identify algorithm errors, data bias, cybersecurity vulnerabilities, user misuse, and mitigation measures.

4. Verification and Validation Evidence

Include unit testing, integration testing, system testing, performance verification, clinical evaluation or clinical trials, human factors usability testing, and cybersecurity vulnerability assessment. Evidence should include test environment, test data, test results, and conclusions, ensuring traceability.

5. Labeling, Instructions, and Post-Market Surveillance

Include product labels, instructions for use, quick guides, online help, adverse event reports, complaint handling, software update release records, and trend analysis of identified risks. Different languages and formats may be required by different countries; adjust according to local regulations.

It is important to note that clinical evaluation of software does not necessarily require clinical trials. If the software has mature algorithms and similar products are already on the market, clinical evidence can be established through literature reviews, historical data, simulated data, or real-world data. However, companies must retain the complete evidence chain and not just submit a summary.

Common Mistakes

• Treating source code and development documents as registration technical files, ignoring the regulatory framework structure.
• Poor software version management, where registration materials show a version different from the marketed version, leading to requests for updates during review.
• Risk analysis only covers algorithm errors, failing to address cybersecurity, data integrity, and human factors errors.
• Clinical evaluation lacks evidence support, providing only conclusions without research data and literature sources.
• Directly reusing NMPA or CE documentation without localization, resulting in language or standards non-compliance in the target country.
• Failing to appoint a local agent or authorized representative in time, preventing submission or causing communication difficulties.
• Neglecting post-market surveillance and software update reporting obligations, making changes during the registration validity period unacceptable to regulators.
• Only organizing the submission version without keeping historical versions and change records, making it impossible to explain change impact during amendments.

Preparation Checklist

• Establish a cross-functional team including regulatory, R&D, testing, quality, clinical, marketing, and local agents.
• Create a target country regulatory analysis table clarifying software classification, registration pathway, agent requirements, and technical standards.
• Establish software version naming and change management rules to ensure the registration baseline is identifiable.
• Build a requirements traceability matrix from user requirements to software requirements, design, testing, and risk control, all traceable.
• Improve quality system documentation compliant with ISO 13485 or MDSAP, especially design development, risk management, supplier management, and corrective and preventive actions.
• Organize reusable technical document packages, classified as common documents and localization documents.
• Prepare local versions, including local language instructions, labels, quick guides, compliance declarations, and standard difference analysis.
• Sign formal agreements with local agents clarifying their responsibilities in registration submission, changes, renewal, and post-market surveillance.
• Develop a post-market surveillance plan including adverse event reporting, software update follow-up, periodic risk reassessment, and annual reports.

AIMEILI Perspective

In overseas registration of software medical devices, the most common misjudgment is "assuming the software has not changed." In reality, software updates are frequent; even if functionality remains the same, fixing vulnerabilities or optimizing algorithms may trigger re-registration or change notification. We recommend that registration be considered as a design input early in R&D, rather than supplementing documents at the end.

Conduct a "gap analysis" in the early stages of the project. Compare existing technical documents against target country requirements item by item, list missing items and gaps, and then develop a supplementary plan. This avoids wasting time and budget in the wrong direction.

What can be reused? ISO 13485 system documents, risk management frameworks, software development processes, test reports, and some clinical evidence are usually reusable. What must be localized? Language, labels, instructions, clinical data references, additional tests required by local regulations, cybersecurity notifications, agent information, and registration certificate control methods all require localization.

Local agents and control of the registration certificate are very important. Many countries require the certificate holder to be a local entity or authorized representative. If a company cannot control the certificate, subsequent changes, renewals, and transfers will become passive. We recommend clarifying certificate ownership and operational rights in agreements.

For multi-country registration, the key to reducing repeated documentation and amendment risks is to use a "core technical document" plus "localization difference package" approach. The core technical document remains stable, and only adds difference sections for target markets. At the same time, uniformly manage each amendment and review comment to form an internal regulatory knowledge base, avoiding the same issue recurring in multiple countries.

Common Follow-up Questions

Does clinical evaluation of software medical devices require clinical trials?

Not necessarily. For moderate-risk software, if clinical data from equivalent devices already exists, or if existing literature and real-world data can demonstrate safety, a clinical evaluation pathway can be used. However, for high-risk or new algorithms or new indications, clinical trials or performance studies may still be required. Companies should design an evidence strategy based on target country requirements and conduct early communication with regulators before submission.

Does software need re-registration after updates?

It depends on whether the update affects safety and effectiveness. If it is only interface optimization or performance improvement, a change application or annual report may be sufficient. If the intended use, core algorithm, clinical output, or workflow changes, re-registration or supplemental application may be required. Companies should establish a change evaluation process, comparing each update with the approved product description to decide whether notification is required.

Can a single set of documents be shared for multiple countries?

Core files can be shared, but localization adjustments must be made. Different countries may require different languages, label formats, clinical data citation standards, and local agent arrangements. It is recommended to use one master document set and generate difference packages according to each country's requirements, while maintaining version records. This significantly reduces repeated preparation time and reduces amendments caused by missed differences.

Further Reading

Recommended articles: "How to Prepare Performance Verification Documentation for Software Medical Device Overseas Registration," "How to Conduct Post-Market Surveillance for Software Medical Devices," "Why Do Software Medical Device Registration Timelines Extend?" and "How to Prepare Technical Documentation for Software Medical Device Overseas Registration." Also relevant: "How to Conduct Post-Market Surveillance for Home Medical Devices" and "How to Group Multiple Models in Home Medical Device Registration."

Content Review and Applicability

Content author: AIMEILI Regulatory Editorial Team. Professional review: AIMEILI Medical Device International Registration Project Team. Source principles: Priority is given to official regulatory agencies, international organizations, standards bodies, and public regulatory materials; industry media and project experience are used only as auxiliary judgment. Applicability: This article is intended for preliminary understanding, documentation preparation, and project planning. It does not replace formal requirements, test conclusions, or legal opinions from target country regulatory authorities.