Risk Management Documentation Requirements for Overseas Registration of Software Medical Devices

Key Summary

For overseas registration of software medical devices, the risk management file is not simply an ISO 14971 report submitted as-is. It must align with the target country's regulatory framework, product classification, technical documentation, quality management system, and post-market surveillance requirements. Companies should first confirm whether the product falls under the target country's medical device regulatory scope, then determine the risk class and registration pathway, and assess whether existing NMPA, CE, FDA, or ISO 13485 documentation can be reused.

The risk management file should cover intended use, patient safety, cybersecurity, data integrity, and clinical benefit-risk analysis, and must be consistent with the software version, instructions for use, labeling, and clinical evaluation. When registering in GHWP member countries, local authorized representatives, local language requirements, change control, and renewal obligations must also be considered. The most common risks include disconnection between the risk management report and other technical documents, failure to localize globally applicable data, failure to identify software-specific cybersecurity risks, and lack of a closed loop for real-world post-market data feedback. Companies should establish a lifecycle risk management process, plan the evidence chain in advance, clarify the authorized representative's control over the certificate, and develop a multi-country registration document reuse and gap analysis strategy to reduce the risk of deficiency letters and delays.

Applicable Scenarios and Core Issues

The definition and regulatory scope of software medical devices differ across countries. The first step is to confirm whether the product qualifies as a medical device and is subject to local regulations. For example, the EU MDR includes standalone software as a medical device or in vitro diagnostic device, while the U.S. FDA regulates software under its SaMD framework; GHWP member countries may have different classification rules. If the product is merely a health management app or for non-medical purposes, it may not require medical device registration. However, if it is used for disease diagnosis, treatment decisions, or monitoring, it falls under regulatory oversight.

When planning overseas market entry, the applicable scenarios for risk management documentation include at least initial registration, change registration, certificate renewal, multi-country registration, and post-market surveillance. Each scenario imposes different requirements on the risk management file, but the common core is to demonstrate that clinical benefits outweigh risks and that risk control measures are implemented and form a closed loop. Companies often confuse 'medical device risk management' with 'software engineering risk management'; the latter emphasizes cybersecurity, algorithm robustness, human factors, and continuous monitoring.

The core question is how to satisfy the ISO 14971 framework in one risk management file while integrating the software lifecycle process and meeting the target country's specific requirements. For instance, the FDA requires a cybersecurity risk management plan, the EU MDR requires mutual iteration between clinical evaluation and risk management, and some Middle Eastern countries may require additional post-market risk reports. Companies that prepare only one English risk management report and attempt to use it for all countries often face questions from local authorized representatives or technical file deficiencies.

Therefore, companies should first clarify whether the product falls under the target country's regulatory scope, then determine the registration pathway based on risk class, and build a series of evidence chains around the risk management file. The risk management file should not be treated as an isolated document; it must cross-reference product definition, specifications, test records, clinical evaluation, labeling, and software version update records to form a complete registration dossier.

Registration Decision Logic

The first step is to determine whether the product is a software medical device. If it is standalone software or an embedded software module used for medical purposes, it is generally considered a software medical device. The second step is to determine the risk class. Different countries use different classification rules, such as EU MDR Rule 11, the FDA SaMD risk framework, and GHWP member countries' Class II or Class III classification. The risk class directly determines the registration pathway, the degree of regulatory scrutiny, and the level of evidence required.

The third step is to assess the reusability of existing documentation. If the company already holds an NMPA registration certificate or has passed CE or FDA review, the relevant risk management documents, software verification records, and clinical evaluation data can be partially reused. However, each country has local requirements, such as risk summaries in the local language, local epidemiological data, or clinical benefit analysis for specific populations. Companies should assess the applicability of each document rather than copy-pasting.

The fourth step is to determine the applicant and the local authorized representative. Overseas registration typically requires a qualified applicant or an authorized representative. The authorized representative must be able to explain the risk management process when submitting the risk management file to the regulatory authority. If the representative is not familiar with the product's technical details, companies should anticipate the regulator's potential questions and provide clear, sufficient explanations in the documentation.

The fifth step is to establish a post-market risk management system. Global registration does not end with obtaining the certificate; adverse events, cybersecurity incidents, and user feedback must be continuously collected. The risk management file should include a post-market surveillance plan and performance indicators, with regular risk assessments updated accordingly. For software medical devices, version upgrades are frequent; any change affecting safety or effectiveness may require a change application and an update to the risk management file. Thus, the registration decision logic is not linear but an iterative process.

Documentation and Evidence

The risk management file for overseas registration of software medical devices typically includes a risk management plan, risk management report, risk analysis table, risk control measures, and verification records. These documents must conform to the ISO 14971:2019 framework and incorporate evidence from the IEC 62304 software lifecycle process. Evidence to prepare includes software requirements specification, software architecture design, unit and integration test reports, system test reports, fault diagnosis records, cybersecurity threat modeling, and penetration test reports.

In the risk management plan, the intended use, target population, use environment, key performance indicators, and safety tolerance criteria should be clearly defined. For software medical devices, the risk class of each software functional module and the risk acceptability criteria for each module must also be defined. The risk management report should summarize all identified hazards, verification results of risk control measures, and whether residual risks are acceptable.

Clinical evaluation data are an essential part of the risk management file. For higher-risk software, clinical literature reviews, expert opinions, or clinical investigation data may be required. If the company uses algorithms or technologies equivalent to those already on the market, equivalence must be demonstrated. Cybersecurity evidence is also increasingly important; both FDA and EU MDR require cybersecurity risk assessment and corresponding risk control measures.

Information in labels and instructions for use must be included in the risk management file. Companies should verify that warnings, precautions, and contraindications on the software interface are consistent with the risk management report. All language versions should comply with target country requirements; improper localization translation may lead regulators to question the reliability of the risk management file.

Finally, companies must provide documented post-market surveillance records, such as adverse event reporting procedures, customer complaint handling processes, and periodic review mechanisms. These prove that the risk management file is not static, but has a dynamic update mechanism. If the target country requires periodic update reports, companies should establish an annual or regular review plan.

Common Errors

• Using a globally generic risk management report without considering target-country specific requirements, such as local language, local statistical standards, or specific clinical guidelines.
• Risk management file disconnected from software versioning; one report corresponds to multiple versions, making it impossible to trace the risk assessment of a specific version.
• Focusing only on traditional functional safety, neglecting cybersecurity, privacy, and data protection requirements, leading to deficiency requests during review.
• Risk control measures described only at design level without providing verification evidence or test records, so regulators cannot confirm effectiveness.
• Ignoring post-market data collection and feedback; the risk management file lacks input from market use information.
• Failing to cross-reference clinical evaluation documents, especially for AI or machine learning features, resulting in insufficient clinical benefit-risk analysis.
• Authorized representative lacks understanding of risk management technical details, causing inconsistencies when answering regulatory authorities.
• Not planning certificate control rights in advance, making certificate changes or renewals dependent on an unstable representative, delaying document approval.

Company Preparation Checklist

• Identify the target country and its corresponding medical device regulations and classification rules; complete product qualification assessment.
• Determine the product's risk class and registration pathway; select an appropriate registration approach.
• Establish a risk management process based on ISO 14971, with personnel competent in software safety and IT security.
• Organize existing documentation, systematically check against target country requirements, and mark files that are reusable or need localization.
• Write risk management plan and risk management report consistent with the current product version.
• Prepare software lifecycle technical documentation, including software development plan, requirements, architecture, testing, and code review records.
• Prepare cybersecurity risk assessment and penetration test reports covering data encryption, authentication, access control, and logging.
• Prepare clinical evaluation data or clinical evidence, ensuring consistency with risk analysis.
• Prepare instructions for use, labeling, and user interface text; complete localization translation and review.
• Appoint a local authorized representative and sign an agreement clearly defining change and renewal responsibilities.
• Establish post-market adverse event and cybersecurity incident monitoring mechanisms; develop a periodic review plan.
• Perform a multi-country registration gap analysis and create a mapping table for submitting the same technical file to different countries.

AIMEILI Perspective

In overseas registration of software medical devices, one of the most common misjudgments is believing that the risk management file is simply a translation and submission of an ISO 14971 report. In fact, regulatory reviewers focus more on whether the risk management file reflects the software-specific risks and the continuous iterative control measures. If the risk management file is only filled out from a template without deep integration with the software architecture and specific functions, it will be difficult to pass review even if the format complies with the standard. We recommend companies engage regulatory consultants who are familiar with target country requirements at an early stage, rather than supplementing documentation at the last minute.

The most important early actions are product definition and risk class determination, as these directly affect the scope and depth of all subsequent documentation. Companies can first conduct a gap analysis using existing materials to identify what needs rewriting, translating, or supplementing with new evidence. For example, the FDA has requirements for algorithm transparency for SaMD, the EU MDR imposes higher demands for clinical evidence, and some Southeast Asian countries may accept CE or FDA documentation but require a local language summary.

Regarding document reuse and localization, the core logic is that basic technical documents, test records, system architecture, and development standards belong to 'database' information and can be reused. Conversely, hazard scenarios, probability estimates, benefit indicators, clinical evidence, and sections of the instructions for use related to target population and regulatory requirements must be localized. For instance, a blood pressure monitoring software developed for European or American populations may need to supplement analysis of local population blood pressure distribution or the impact of ambient temperature on algorithm performance when registering in Southeast Asia.

Why are local authorized representatives, certificate control rights, and change/renewal management important? The local representative mainly communicates with regulators, but certificate control rights should remain with the company to avoid disruption if the representative or regulatory consultant changes. Change management is the norm for software medical devices. If regulators deem a software update to be a significant change, new risk management documentation may be required. Companies should develop a change submission strategy at the outset of registration to avoid increased compliance costs from frequent updates. Renewal is equally critical. Some countries require periodic updates of the risk management report; without early planning, companies may face certificate interruption.

In multi-country registration, the key to reducing duplicate document preparation and deficiency risk is to establish a two-tier structure of a 'common technical document' and 'country-specific difference files.' The common technical document contains product technical, safety, and performance data, while the country-specific files include local representative information, language versions, and regulatory-specific requirements. Before each submission, only the country-specific differences need to be checked, avoiding the need to recompile documents from scratch for every registration. Additionally, using a unified risk coding and hazard numbering system helps regulators in different countries understand the documentation. In AIMEILI's past consulting cases, proper multi-country documentation planning reduced deficiency rates by more than 40% and shortened the overall registration cycle by approximately 4 to 6 months.

Frequently Asked Questions

Is an ISO 14971 risk management report sufficient to meet all overseas country requirements?

No. ISO 14971 provides a basic framework, but different countries have additional requirements. For example, the FDA requires a specific cybersecurity risk management plan and follows its precertification approach for SaMD; the EU MDR requires risk management to be linked with clinical evaluation and adds usability-related risk requirements; many Middle Eastern or Southeast Asian countries may require local clinical data or risk assessment for specific populations. Therefore, companies should supplement the ISO 14971 framework with target country-specific regulations.

Must software be re-registered after an update?

Whether re-registration is required depends on whether the update affects safety or effectiveness. If it is only a general performance optimization that does not alter algorithm logic, change registration may not be necessary. However, if the update modifies indications, adds new diagnostic functions, or changes the target user, a change application is generally required and the risk management file must be updated. It is recommended to establish a change assessment process and initiate risk assessment early in development to avoid interruption of market plans due to major changes.

Can the same risk management file be submitted identically for multi-country registration?

It is not recommended. Even if countries mutually recognize each other's approvals, local administrative and technical differences must still be met. For example, requirements for language, standardized content, and clinical evidence vary by country. Companies should establish a core risk management document as the base, and prepare country-specific sub-documents and a difference matrix for each country. This reduces duplicate work, but each country's file still needs individual review.