How to Prepare Technical Documents for Overseas Registration of Software Medical Devices

How to Prepare Technical Documents for Overseas Registration of Software Medical Devices

Published: 2026-07-10 08:57 | Updated: 2026-07-10 08:57

Preparing technical documents for overseas registration of software medical devices is a critical step for global market entry. First, determine whether the product qualifies as a medical device in the target country. For example, the U.S. FDA has clear classifications for Software as a Medical Device (SaMD), the EU MDR categorizes software as an active device, and regulators like China NMPA, Japan PMDA, and Korea MFDS each have specific guidelines. Next, based on the product's function, clinical use, and risk level, establish the registration pathway: low-risk devices (e.g., Class I) may require only a self-declaration or simple registration; medium- to high-risk devices (Class II and above) typically require submission of technical documents, quality management system certificates, performance validation reports, risk management files, clinical evaluation or trial evidence, labeling, and local authorized representative documentation. Companies can leverage existing NMPA registration materials (e.g., software description documents, design verification reports), CE technical files under IVDD/IVDR, or FDA 510(k)/PMA submissions, but these must be localized to the target country's language, regulations, and standards. Common risks include misclassification, insufficient clinical evidence, failure to appoint an authorized representative, and software updates triggering re-registration. It is recommended to conduct a target market gap analysis early, prioritize ISO 13485 or MDSAP certification, and engage professional regulatory consultants to minimize review deficiencies.

Applicable Scenarios and Core Issues

This guidance is for companies planning to export medical software to GHWP member countries (e.g., China, U.S., EU, Japan, Korea, Southeast Asia, Middle East, Latin America). Core issues include: whether the product falls under medical device regulation, risk classification, registration pathway selection, technical document content requirements, and how to leverage existing NMPA/CE/FDA submissions. Classification should be based on product function, intended use, algorithmic decision-making capability, and impact on diagnosis or treatment. For instance, software that helps physicians analyze images without providing a diagnosis may not be a medical device, while software that automatically detects lesions and alerts risks is considered SaMD.

Target country regulators generally follow the IMDRF SaMD classification framework, but local differences are significant. The U.S. FDA classifies based on "device software functions," the EU MDR by risk class (I, IIa, IIb, III), and China's NMPA uses the Medical Device Classification Catalog and software-specific classification rules. Companies should create a multi-country registration matrix, documenting classification conclusions, registration processes, and documentation requirements for each market as the project baseline.

Registration Decision Logic

Step 1: Determine if the product is a medical device. Evaluate whether the software is used for diagnosis, treatment, monitoring, or prevention of disease, affects patient management, or provides clinical decision support. Non-medical apps (e.g., fitness or wellness) are generally not medical devices.

Step 2: Determine risk class. Assess the risk to patients and users based on the target country's classification rules. For example, EU MDR Annex VIII includes specific rules for software (Rules 10 and 11); FDA uses "significance" and "automation level"; China's NMPA strictly manages software in Class II and III. It is advisable to create a classification decision tree that maps to each country's rules.

Step 3: Determine the registration pathway. Low-risk products may only need to comply with general safety and performance requirements and submit a declaration of conformity (e.g., EU Class I self-declaration). Medium- and high-risk products typically require review by a third-party certification body (e.g., EU notified body, FDA third-party reviewer), submission of a full technical file, QMS certificate (e.g., ISO 13485 or MDSAP), and clinical evidence. For multi-country registration, prioritize markets with mutual recognition agreements (e.g., MDSAP covers the U.S., Japan, Brazil, Canada, Australia) to reduce duplicate reviews.

Step 4: Assess reusability of existing documents. NMPA registration documents such as the Software Description Document (SDS), cybersecurity documentation, and algorithm validation reports can be partially used for the "software description" section of FDA 510(k). CE MDR technical documentation (e.g., software development lifecycle documents) can serve as a core foundation. However, clinical evaluations, labeling, and risk management reports must be adjusted to each country's requirements—for instance, the FDA requires usability engineering files, and the EU requires a Safety and Clinical Performance Summary (SSCP).

Documents and Evidence

Technical file preparation should cover the following modules:

• Product Description: Software name, version, intended use, clinical indications, target user population, operating environment, architecture overview, hardware requirements.
• Software Lifecycle Documents: Requirements specifications, design specifications, software verification and validation plans and reports, defect management records. Recommend compliance with IEC 62304.
• Risk Management File: Hazard identification (e.g., data errors, algorithm bias, cyberattacks) per ISO 14971, risk assessment, and control measures. Include risk management plan, report, and summary.
• Performance Validation and Confirmation: Functional test reports, stress testing, algorithm accuracy analysis, interoperability verification, security testing (e.g., vulnerability scanning, encryption validation). For AI/ML software, provide training and test datasets, model performance metrics (sensitivity, specificity, AUC), and generalization validation.
• Clinical Evaluation or Trial Evidence: For medium- and high-risk products, prepare systematic literature reviews, equivalent product comparisons, or clinical trial reports according to national guidelines (e.g., MEDDEV 2.7/1 Rev.4, FDA Guidance on Clinical Evaluation of Software). Low-risk products may qualify for equivalence arguments or exemption by declaration of conformity.
• Labeling and Instructions: User manual, quick start guide, screenshots, warnings, contraindications, adverse event reporting instructions. Translate to target country language and comply with local labeling regulations (e.g., EU MDR Annex I Chapter 23, FDA 21 CFR Part 801).
• Quality Management System Documents: ISO 13485 or MDSAP certificate, quality manual, internal audit records, CAPA procedures. Some markets accept equivalent systems; verify in advance.
• Cybersecurity Documentation: Cybersecurity threat analysis, security control measures, update management processes, vulnerability disclosure procedures. Specific requirements exist from FDA and EU MDCG (e.g., MDCG 2019-16).
• Local Agent/Authorized Representative Documentation: Appoint a local representative in the target country and sign an authorization agreement. The representative communicates with regulators, receives complaints, and assists in adverse event reporting.
• Post-Market Surveillance Plan: PMCF (Post-Market Clinical Follow-up), PMS (Post-Market Surveillance) reports, Periodic Safety Update Reports (PSUR). Define data collection methods, reporting intervals, and update mechanisms.

Common Mistakes

• Misclassification: Treating SaMD as a non-medical device, leading to missed registration; or registering high-risk products under a low-risk pathway, causing review deficiencies and project delays.
• Insufficient Clinical Evidence: Failing to provide a clinical evaluation report meeting target country requirements, or directly using CE reports for FDA submissions, leading to rejection.
• Software Updates Triggering Re-Registration: Failing to distinguish significant from minor updates, resulting in unreported changes and compliance risks.
• Missing Local Authorized Representative: In markets like the EU, Brazil, and Saudi Arabia, lack of a local representative prevents application acceptance.
• Language Issues in Technical Files: Key documents not translated or poorly translated, requiring resubmission.
• Neglecting Cybersecurity Requirements: Not submitting cybersecurity documentation as required by FDA or MDCG, causing review suspension.
• QMS Not Covering Software: ISO 13485 certificate does not include software design, development, and production activities, raising questions about effectiveness.

Company Preparation Checklist

• Classification Confirmation: Complete classification determination for target countries and document in writing.
• Registration Pathway Planning: Select applicant (manufacturer or agent), determine registration type (initial/change/renewal).
• Regulatory Gap Analysis: Compare existing documents with target market requirements, list missing documents.
• Core Document Preparation: Software description document, risk management file, performance validation report, clinical evaluation report (if applicable), cybersecurity documentation.
• Quality Management System: Ensure system covers software, obtain ISO 13485 or MDSAP certificate.
• Local Agent: Appoint an authorized representative in the target country, sign agreement, and file.
• Labeling: Create multilingual versions, verify inclusion of required content (warnings, contraindications, manufacturer information).
• Post-Market Documents: Prepare PMS plan and PMCF report templates.
• Project Budget and Timeline: Allocate for supplements, translation, certification fees, and review cycles (typically 6–18 months).
• Professional Consultation: If internal team lacks experience, hire a CRO or regulatory consultant with overseas registration expertise.

AIMEILI Regulatory Interpretation and Business Impact

We observe that companies most often misjudge software classification and the acceptability of clinical evidence. Many products registered as Class II in China may be classified as Class III in the EU or U.S., such as independent decision-making AI diagnostic software. We recommend conducting a pre-classification assessment with a consultant familiar with target country regulations before project initiation, with an investment of approximately 20,000–50,000 RMB (2,800–7,000 USD) to avoid major rework later.

Prioritize obtaining ISO 13485 certification that covers software processes. This is not only a prerequisite in most countries but also helps systematically organize design history files and risk management records, providing a reliable foundation for multi-country submissions. For companies targeting China, the U.S., and Europe simultaneously, we suggest a "core document + differential supplement" model: maintain a master technical file based on the IMDRF framework, then add country-specific annexes (e.g., translations, local clinical data, unique label requirements). This can reduce duplication by over 40%.

Local representatives are not just a formality; choose an experienced and qualified entity. Many companies have had certificates suspended due to representative changes or delayed renewals, forcing product withdrawal. Sign a long-term contract with the representative and set up an internal alert mechanism to handle renewals six months in advance. For multi-country registration, use MDSAP or common recognition arrangements to reduce on-site audits.

Software update management is another hidden risk. Establish a clear version control strategy, distinguish between significant updates (affecting safety or performance) and minor updates (bug fixes, UI optimization), and define corresponding change notification obligations. Missing a report can lead to the product being deemed an "unauthorized change," resulting in fines or recall.

Frequently Asked Questions

1. Is ISO 13485 mandatory for overseas registration of software products? Not all countries mandate it, but most medium- and high-risk markets (EU, Brazil, Saudi Arabia, Australia, Japan) require ISO 13485 or equivalent MDSAP certification. Low-risk products (e.g., EU Class I) can self-declare QMS conformity, but it is recommended to establish and certify the system in advance to improve review efficiency. Additionally, the certificate's scope must include "software design and development," or it may be considered invalid.

2. Can existing NMPA registration documents be directly used for FDA 510(k)? They can be partially reused but require localization. The FDA expects software description documents, performance test data, risk management reports, etc., but in specific formats (e.g., eCopy requirements under Q-Sub). For clinical evaluation, the FDA typically does not accept data solely from Chinese populations; additional validation across U.S. or multi-ethnic populations is needed. For cybersecurity, the FDA expects compliance with its Cybersecurity Guidance for Medical Devices, which is more detailed than NMPA requirements. Therefore, use NMPA documents as a starting point and supplement after a target market gap analysis.

3. How can multi-country registration reduce duplication and deficiency risks? The best practice is to use a "core technical file + country-specific modules" approach. First, create a complete set of software lifecycle documents in English based on IMDRF/ISO 13485 as a baseline. Then, for each country, add modules such as local clinical data (if needed), translated labeling, specific cybersecurity files (e.g., FDA SBOM, EU cybersecurity report), and local agent authorization. Also, prioritize MDSAP-recognized countries for system audits to reduce audit frequency. Engage a CRO with experience in multiple markets to manage submissions consistently and avoid contradictions.