When Should Software Medical Device Changes Be Reported for Overseas Registration?

For software medical devices (SaMD) registered overseas, not all changes require immediate regulatory submission. The key is to determine whether the change affects safety, effectiveness, intended use, or technical state. Substantive changes—such as modifications to core algorithms, clinical functions, input/output interfaces, cybersecurity features, major user interface changes, or changes to accompanying hardware or operating environment—must be reported to and approved by the original registering authority. In contrast, editorial revisions or backend non-functional maintenance that do not affect safety can be managed through periodic updates or annual reports.

Key Summary

After overseas registration of a software medical device, not all changes require immediate submission. Companies should first determine whether the change affects product safety, effectiveness, intended use, or technical state. Typically, changes involving the software's core technical algorithms, intended clinical functions, input/output interfaces, cybersecurity features, major user interface adjustments, or changes to accompanying hardware or operating environment are substantive changes and must be submitted to the regulatory authority of the original registration country for approval. Changes that are merely editorial and do not affect safety, or backend non-functional maintenance, can be managed through periodic updates or annual reports.

The determination path should be based on the target country's regulations. For example, GHWP member states generally follow the IMDRF/SaMD classification framework, the US FDA defines through guidance which changes require a new 510(k), and the EU MDR requires an assessment of whether a change constitutes a "significant change." Companies should review change management procedures and design history files, compare them with the product description, intended use, performance specifications, and risk management report in the target country's technical registration documentation, and establish a change impact assessment form. For multi-country registration, considerations include reuse of technical files, coordination with local agents, and differences in submission timelines across markets.

Common risks include neglecting to align the registration certificate with the marketed version due to continuous software updates, or exaggerating the nature of the change and causing unnecessary supplementary submissions. Companies should establish change classification standards, retain an evidence chain, and communicate with local agents in advance to avoid compliance and market access issues caused by correction requests or failure to submit.

Applicable Scenarios and Core Question

Overseas registration of Software as a Medical Device (SaMD) is not a one-time static activity. After product launch, companies often continuously release new versions for feature improvements, bug fixes, algorithm optimization, or adaptation to new regions. At this point, the registration holder must answer a core question: does this change require submission to the target country's regulatory authority?

The answer directly affects compliance costs, market access pace, and the safety of the registration certificate. If a change should be reported but is not, the registration certificate may be suspended, the product may be removed from the market, or fines may be imposed. If a change does not require submission but is submitted, time and resources are wasted, delaying version release.

Therefore, companies need to establish a change impact assessment mechanism suitable for software products, covering the regulatory requirements of GHWP member states, Southeast Asia, the Middle East, Latin America, and other different markets. Although the specific details of each regulatory body differ, they generally follow the same underlying logic: does the change affect product safety, effectiveness, or intended use?

In practice, software changes are usually divided into four categories: changes to product design, changes to manufacturing processes, changes to labels and instructions, and changes to software versions. Among these, software version changes are the most complex because they may involve multiple dimensions such as core algorithms, data interfaces, user interfaces, cybersecurity patches, and more.

Companies must recognize that the software medical device lifecycle does not have a state of "no change." Multiple iterations per year are common in the industry. The key is to place every change under a controlled quality system and determine its regulatory nature.

Regulatory Determination Logic

Step 1: Determine Whether the Product Falls Within the Target Country's Medical Device Regulatory Scope

Some software, such as health lifestyle tools or general office software, may not be considered a medical device. However, once it has a medical purpose—such as assisting in diagnosis, treatment decisions, or chronic disease management—it must be regulated.

Step 2: Determine Risk Class According to the Target Country's Classification Rules

Taking SaMD as an example, the US FDA and the EU MDR classify software into different categories based on clinical significance and importance in medical decision-making. GHWP member states also generally adopt similar frameworks. The higher the risk class, the stricter the change review.

Step 3: Analyze Whether the Change Touches "Substantive" Elements

To determine whether a change is substantive, refer to the typical trigger conditions listed in the country's regulatory guidance, such as changes to intended use, changes to input data types, changes to physiological models, changes to user interface affecting clinical understanding, or degradation of safety-related functions.

Step 4: Evaluate Whether Existing NMPA, CE, FDA, ISO 13485, MDSAP, or Other Market Documentation Can Be Reused

If the company has already obtained registration in China and established complete technical documentation, much of the verification data, risk management records, and clinical evaluation content can serve as a basis for supporting overseas change submissions.

Step 5: Confirm the Requirements for the Change Applicant in the Target Country

Some countries require the local agent or authorized representative to submit the change application, especially when the registration certificate holder is a foreign company. Companies must confirm the scope of agent responsibilities in advance to avoid delays caused by the agent being unreachable or lacking authority.

Step 6: Initiate Change Submission or Record

If the change is determined to be substantive, submit a change application according to the target country's regulations. If not, retain the change record and disclose it in the annual report or periodic review as required.

Documentation and Evidence

Submitting a registration change for software medical devices essentially means using an evidence chain to prove that the changed product still meets safety and effectiveness requirements. Therefore, the preparation of documentation should focus on the "differences before and after the change" and the "impact analysis after the change."

In terms of technical files, it is necessary to update the product description, software architecture diagram, algorithm description, data flow diagram, hardware operating environment, and other sections. All modification locations should be explicitly marked in a version change history and linked to the corresponding software design documents.

Performance verification data is one of the core evidence items. Companies should provide targeted verification reports for the specific changes, such as algorithm accuracy tests, performance comparison tests, stress tests, compatibility tests, etc. Do not simply submit a summary of the overall system test. Instead, allow the regulatory authority to trace the verification activities corresponding to each change.

The risk management report must reassess new hazards introduced by the change or changes in risk. A common practice is to update the risk analysis table using ISO 14971, explaining the control measures for new risks and the acceptability of residual risk. For changes involving cybersecurity fixes, add threat modeling updates and vulnerability management descriptions.

Clinical evaluation or clinical evidence should be updated depending on the nature of the change. If the change affects the intended clinical purpose or the way outputs are interpreted, provide new clinical evidence or a clinical evaluation report. If only backend performance parameters are modified without affecting clinical use, the original evidence can be cited with an explanation.

Labels, instructions, and user interface need to be updated in sync. When submitting a change for overseas registration, the target country's regulatory authority will be concerned about whether users can accurately understand the revised instructions for use. Therefore, instructions, quick reference guides, training materials, etc. should be updated with the version, and translation notarization or certification should be provided as required.

Documents related to the local agent and authorized representative should also remain consistent with the change. For example, the agent agreement should clearly define the obligation to notify changes, submission authority, and submission deadlines. Many countries require the agent to participate in the change submission, so companies should proactively share the change plan with the agent to avoid submission failure due to inconsistent information.

Common Mistakes

• Treating all code modifications as maintenance updates that do not require submission, while ignoring that substantive changes in software logic may affect clinical use.
• Assuming that "model retraining" can be controlled through the internal quality system alone, while ignoring mandatory submission requirements that the target country's regulatory authority may impose on such algorithm changes.
• To save time and cost, deliberately splitting a substantive change into multiple small versions to bypass submission obligations—this practice is very dangerous in regulatory review.
• Focusing only on the domestic registration certificate while ignoring the binding relationship of multi-country registration. For example, when the same set of technical files is used for registration in different countries, a submission result in one country may affect the compliance status in others.
• Failing to establish a mapping table between software versions and registration certificate versions, making it impossible to trace the marketed version to the approved version.
• Failing to provide timely change information to the local agent, causing delays in the submission window and even expiration of the registration certificate.
• Underestimating label and instruction changes, thinking that only product functional changes require submission, while ignoring that changes in user guidance information can also trigger regulatory review.
• Simply copying the original registration documents when preparing change submission materials, without highlighting the difference analysis and impact assessment before and after the change, leading to deficiency letters and rejections.

Company Preparation Checklist

• Establish a software change classification table that distinguishes at least "substantive change," "minor change," and "recording change" categories, with approval processes for each.
• Maintain a mapping table of software versions and registration certificate versions, recording the approved version number and current marketed version number in each registration country.
• Embed a software change assessment process into the ISO 13485 or MDSAP quality management system documentation, clearly defining when a regulatory submission assessment is triggered.
• Designate dedicated personnel responsible for overseas registration change submissions and ensure they are familiar with the target country's regulations and latest updates.
• Prioritize reuse of existing design inputs, verification data, risk management documents, and clinical evaluation materials, and establish a common file library for multiple countries.
• Sign clear change service agreements with local agents in each target country, including response timelines, communication channels, and fee settlement methods.
• Develop a multi-country coordinated change plan. When the same change involves multiple countries, first assess each country's submission requirements and time windows, then decide the release sequence.
• Conduct regular regulatory compliance reviews of marketed software, checking at least every six months whether the registration certificate coverage matches the actual product version.

AIMEILI Regulatory Interpretation and Business Impact

In our long-term experience advising companies on overseas software registration changes, we find that the most common misjudgment is merging "functional modification" with "safety impact." Many R&D teams believe that if the algorithm accuracy improves or the interface becomes smoother, safety must be better, and therefore no submission is needed. However, the regulatory authority is not only concerned with performance quality, but also with whether the change alters the intended use, clinical decision-making logic, or safety risk profile. Therefore, companies should place classification determination at the very beginning.

At the project stage, we recommend that companies first conduct a "regulatory gap analysis" rather than directly modifying code. List the planned changes item by item, compare them with the target country's change checklist, and mark items that may trigger submission. Then decide which verification milestones need to be reserved in the development process. This is far more efficient than retroactive testing.

Reusable documentation includes: foundational architecture design documents, algorithm principle descriptions, non-clinical performance test data, risk management templates, and most clinical literature resources. Parts that must be localized include: labels, instructions, user interface text, registration application documents in target country format, local language translations, and cybersecurity descriptions or data protection declarations required by specific market regulations.

The role of the local agent is often underestimated. The agent is not only a channel for submitting documents, but also a bridge for companies to understand the target country's regulatory requirements. Certificate control rights are crucial. If the registration certificate is held by an overseas parent company, the local agent or distributor may not be able to initiate a change submission on its own. Companies must clarify the ownership of control rights in advance through an authorization agreement.

Changes and renewals are bound to the product lifecycle. If a software version has not been submitted for a long time, the subsequent renewal may require a large amount of difference explanation, or even a full re-registration process. Therefore, we advise companies to treat change submission as a strategic investment, not a compliance burden.

In multi-country registration, special attention is needed to reduce repetitive documentation and correction risks. Our practical method is to establish two levels: a "Core Technical File Package" and a "Country-Specific File Package." The core technical file package contains all common verification and risk documentation, while the country-specific file package contains only the localized requirements. In this way, when a deficiency is raised in one country, it does not affect the submission progress in other countries.

Common Follow-up Questions

Is submission required for changes to interface text or color only?

If the interface modification does not affect the user's understanding of clinical information, does not change the intended use or operational safety, it is generally a minor change and does not require immediate submission. However, the design change record should be retained and mentioned in the periodic review or annual report. If the interface text involves warnings, contraindications, or clinical decision information, it may constitute a substantive change and require submission.

Is submission required when the software version number is upgraded from 1.0 to 2.0, but functionality remains unchanged?

The version number itself is not a basis for judgment. The key is whether the underlying code has substantive changes. If only the version identifier changes or backend performance optimization is made without affecting the intended use and safety, submission may not be required. However, if the database structure, communication protocol, or core library upgrade changes the software operating environment, it is necessary to assess whether submission is triggered.

In multi-country registration, can a change submission be made in one country and then mutually recognized?

Currently, GHWP member states and mainstream markets have not established a complete mutual recognition mechanism. Each country has its own change submission requirements and review timelines. Companies should initiate submissions in all relevant countries simultaneously and use the core technical file package to improve efficiency. Some countries may refer to the review conclusions of other countries, but this cannot replace local registration requirements.

If a product has passed NMPA change registration in China, can that be directly used for overseas submission?

NMPA change registration documentation can serve as an important reference, but it cannot be directly copied. Overseas target countries have different requirements for clinical evaluation, cybersecurity, local labeling, and other aspects. Documentation typically needs to be recompiled and translated, and submitted in accordance with the target country's format. However, Chinese verification data and risk management content often have strong evidentiary value and can be reused as core evidence.

Content Review and Applicability Boundary

Author: AIMEILI Regulatory Editorial Department. Professional Review: AIMEILI Medical Device International Registration Project Team. Source Principles: Priority is given to official regulatory agencies, international organizations, standards organizations, and publicly available regulatory information; industry media and project experience are used only as supplementary judgment. Applicability Boundary: This article is intended for preliminary understanding, documentation preparation, and project planning. It does not replace the formal requirements of the target country's regulatory authorities, testing conclusions, or legal opinions.