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

Quick Answer

To prepare performance verification documentation for overseas registration of software medical devices, you must first determine whether the target country regulates the software as a medical device, and then select the registration pathway based on risk classification. Review existing technical documentation under NMPA, CE, FDA, or ISO 13485, assess which portions can be reused, and localize content to meet target-country language, regulatory, clinical evaluation, and cybersecurity requirements. The documentation set typically includes product description, requirements specification, risk management file, software development lifecycle evidence, verification and validation reports, cybersecurity information, and clinical evaluation or usability evidence. Avoid common pitfalls such as misclassifying the device, ignoring local representative obligations, reusing outdated documentation, or lacking a post-market surveillance plan.

Applicable Scenarios and Core Questions

Performance verification documentation for overseas registration of software medical devices refers to the technical documents used to prove that the product meets its intended performance, safety, and effectiveness requirements when the software is regulated as a medical device (SaMD) or as a component of a medical device. In practice, companies often equate 'performance verification' with a simple test report, overlooking the systematic evidence chain behind it.

This applies to companies planning to enter GHWP member countries (e.g., Southeast Asia, the Middle East, parts of Latin America), the European Union, the United States, or other overseas markets, with product forms including standalone software, embedded software, or mobile medical applications. The core question is not whether a test report exists, but whether the target country's regulatory authority accepts the existing evidence and whether the evidence covers the entire lifecycle.

Companies need to answer three basic questions: (1) whether the product falls within the target country's definition of a medical device; (2) what the product's risk classification and registration pathway are; and (3) which existing NMPA, CE, FDA, or ISO 13485 documentation can be reused directly and which must be regenerated. Performance verification documentation is not a single document but a group of interrelated evidence, including requirements traceability, design verification, validation records, risk control measures, clinical evaluation, and cybersecurity evidence. The absence of any one element can lead to regulatory requests for amendment.

Registration Determination Logic

• Determine regulatory scope: Different countries have different definitions for software medical devices. For example, the EU MDR and IVDR, the FDA's SaMD framework, and medical device acts in some Southeast Asian countries. First check whether the target country has specific regulations or guidance for software medical devices.
• Determine risk classification: Most countries manage software based on risk classification, typically Class IIa/IIb or Class II/III. Determine the classification by comparing the intended use, clinical impact, and weight of algorithmic decisions against the target country's classification rules.
• Determine the applicant entity: Some countries allow direct registration by foreign manufacturers, but many require a local representative, authorized representative, or license holder. The applicant's identity affects the submitting entity and post-market liability.
• Assess the reusable value of existing documentation: If you already have an NMPA registration certificate or CE certificate, the performance verification reports, risk management documentation, and software documentation can serve as a basis, but you must verify the target country's specific requirements regarding format, language, clinical evidence, and cybersecurity.
• Confirm post-market maintenance requirements: Registration is not the end point. Performance verification documentation must be continuously maintained, including change control, annual updates, adverse event reporting, and re-registration. For multi-country registration, coordinate the update timelines of different countries.

Documentation and Evidence

Performance verification documentation typically consists of several modules.

Product description: Explain the software architecture, operating environment, algorithm logic, inputs/outputs, and intended use, so that reviewers can understand the product's function.

Requirements and traceability: Provide user requirements, system requirements, software requirements specification, and a requirements traceability matrix to demonstrate that every requirement has been designed, implemented, and verified.

Risk management: Software medical device risk management must follow ISO 14971, combined with IEC 62304 (software lifecycle) and IEC 82304-1 (health software safety). Risk analysis should cover algorithm errors, data exchange failures, cyberattacks, and human operational errors.

Performance verification reports: Include test environment, test data, test cases, pass criteria, and results. Distinguish between unit, integration, system, and validation tests, and explain differences between the test environment and the real clinical environment.

Clinical evaluation: Depending on risk classification, some software requires clinical data. Evidence can be built from published scientific literature, prior clinical use, or your own clinical trials, but check whether the target country accepts indirect evidence.

Cybersecurity documentation: Many countries require cybersecurity risk management documentation, threat models, vulnerability management plans, and penetration test summaries. MDCG guidance and FDA cybersecurity guidance can be used as references.

Labeling and usability: Submit software interface screenshots, instructions for use, warnings, and usability test results to ensure users can understand and operate the software safely.

Localization: Core algorithms and validation data can often be reused, but language, units, regulatory references, and clinical practice differences need localization. For example, diagnostic thresholds, reference intervals, and process names may vary by country.

Common Mistakes

• Misclassifying product category, e.g., treating IVD software or wellness management software as ordinary software, leading to an incorrect registration pathway.
• Directly submitting NMPA or CE documentation without target-country format conversion or translation, resulting in a request for amendment.
• Providing only final test reports without test cases, data, environment, and version control records, thus breaking the evidence chain.
• Ignoring the traceability between risk management and performance verification, so risk control measures lack corresponding verification evidence.
• Assuming clinical evaluation is unnecessary for software, failing to collect literature or conduct usability testing, and being challenged on safety and effectiveness.
• Failing to appoint a local representative or license holder, making submission and communication impossible during the registration phase.
• Failing to consider post-market performance monitoring, leading reviewers to request additional post-market data analysis and prolonging the timeline.
• Repeatedly compiling the same information for multiple countries without a master file, causing version chaos.

Company Preparation Checklist

• Determine whether the product is a medical device and obtain the target country's regulatory classification and registration pathway.
• Appoint a local representative or license holder and sign a clear responsibility agreement.
• Establish a cross-department project team involving regulatory, R&D, quality, clinical, and operations.
• Review existing NMPA, CE, FDA, ISO 13485, and MDSAP documents; mark which can be reused and which need updates.
• Build a traceability matrix for software requirements, design, verification, validation, and risk management.
• Prepare software development lifecycle documentation, including development plan, configuration management, and maintenance plan.
• Write performance verification protocols and reports, ensuring each requirement has a corresponding test.
• Compile cybersecurity documentation, including threat modeling, vulnerability scans, and penetration test summaries.
• Create a clinical evaluation plan; collect literature or design clinical trials, and engage external consultants when necessary.
• Produce localized labels, instructions, and interface screenshots; have them translated and proofread by native speakers.
• Conduct pre-submission communication with the target-country representative or consultancy to confirm format and amendment expectations.
• Establish a post-market surveillance plan with clear adverse event reporting and performance tracking procedures.
• Monitor certificate validity and change requirements to avoid certificate lapse due to regulatory updates.

AIMEILI Regulatory Interpretation and Business Impact

For performance verification documentation for overseas registration of software medical devices, the most misunderstood point is assuming that the test report is everything. In reality, reviewers in target countries pay more attention to the completeness and traceability of evidence. Companies should prioritize building a master technical file before localizing for each country, rather than starting from scratch for every market. This approach saves time and budget.

We recommend conducting a gap analysis at the start of the project, comparing existing documentation against target-country requirements, and determining which items can be reused and which must be redone. Performance verification, risk management, clinical evaluation, and cybersecurity often need supplemental work, while labeling, instructions, and some translation must be localized and cannot be directly adopted from an English version.

The local agent or authorized representative is not merely a 'license-obtaining tool.' They manage certificate control and the continuation of responsibilities after changes. Many companies neglect change control and re-registration, resulting in certificate suspension or revocation, which invalidates prior investment. For multi-country registration, manage certificate validity and change plans centrally, using one set of core evidence to support multiple country applications, reducing duplicate work and amendment risk.

FAQ: Common Follow-up Questions

Can NMPA submission documentation be used directly for performance verification of software medical devices?

Not completely. The technical documentation frameworks required by NMPA and overseas authorities differ. For example, the EU requires CE technical documentation and clinical evaluation reports, while the US requires a 510(k) or De Novo submission, and the review logic differs. You can reuse core evidence such as requirements specifications, test reports, and risk management documents, but you must reorganize them into a format and language compliant with the target country, especially for clinical and cybersecurity sections.

Can software medical devices be registered without clinical data?

It depends on the risk classification. Low-risk software may be registered with performance verification and usability testing alone, but medium- and high-risk software generally requires clinical evidence. Check whether the target country has specific exemptions from clinical data requirements. If not, design literature studies or clinical trials as early as possible and confirm acceptability with your representative or the reviewing authority.

How should performance verification documentation be organized for multi-country registration?

Use a master technical file as the foundation, containing core evidence in English or Chinese, and generate country-specific versions according to target-country requirements. Country versions should only involve format and localization adjustments, avoiding re-testing for each country. At the same time, establish a change management mechanism: when the master file is updated (e.g., algorithm or safety features), evaluate all national registration files for synchronized updates to ensure consistent certificate maintenance across countries.

Further Reading

• How to Organize Technical Documentation for Overseas Registration of Software Medical Devices
• How to Conduct Post-Market Surveillance for Overseas Registration of Software Medical Devices
• Why Do Overseas Registration Timelines for Software Medical Devices Get Extended?
• How to Prepare Technical Documentation for Overseas Registration of Software Medical Devices
• How to Conduct Post-Market Surveillance for Overseas Registration of Home Medical Devices
• How to Group Multiple Models for Submission in Home Medical Device Overseas Registration?

Source and Applicability

Content prepared by AIMEILI Regulatory Editorial Team and reviewed by AIMEILI Medical Device International Registration Project Team. Information is based on publicly available regulatory sources, international standards, and project experience.

This article is for preliminary understanding, documentation preparation, and project planning. It does not replace official requirements of target country regulatory authorities, testing conclusions, or legal opinions.

Published: 2026-08-03 15:54 | Updated: 2026-08-03 15:54