Handling Inconsistencies in Quality System Certificates for Overseas Registration of Software Medical Devices

If quality system certificates are inconsistent during overseas registration of software medical devices, companies should first determine whether the software product falls within the target country's medical device regulatory scope, then confirm the risk class and registration pathway, and evaluate whether existing certificates can be reused. The core task is to establish a quality management system covering the software lifecycle, risk management, cybersecurity, clinical evaluation, and post-market surveillance, and to form a complete chain of evidence linking certificates with technical files, labeling, and local agent authorization documents.

Published: 2026-08-01 22:31 | Updated: 2026-08-01 22:31

Key Summary

In overseas registration of software medical devices, inconsistencies in quality system certificates are a common deficiency risk. These typically appear as mismatches between the scope, version, validity period, or production address stated in NMPA, CE, FDA, ISO 13485, or MDSAP certificates and the registration requirements of the target country.

Companies should first determine whether the software product falls under the target country's medical device regulatory scope, then confirm the risk class and registration pathway, and evaluate whether existing certificates can be reused.

The core work is to establish a set of quality system documents covering software lifecycle, risk management, cybersecurity, clinical evaluation, and post-market surveillance, and to link the quality system certificates with product technical files, labeling, and local agent authorization documents to form a complete chain of evidence.

Common risks include: certificate mismatch with software version, production address changes not synchronized, ISO 13485 certification scope not covering the software, missing quality system elements required by the target country, and certificate validity not covering the registration review period.

Companies should, at the early stage of the project, sort out the target country list and quality system requirements, clarify which documents can be reused and which must be localized, and ensure that the local agent has control of certificates and the ability to notify changes, thereby reducing the risk of repeated documentation and deficiency corrections in multi-country registrations.

Applicable Scenarios and Core Issues

During overseas registration of software medical devices, inconsistencies in quality system certificates often lead to deficiency notifications or refusal letters from regulatory authorities. The term “inconsistency” does not only refer to expired certificates; it means that the submitted quality system evidence conflicts with or cannot be mutually corroborated by the target country's regulatory requirements, the product risk class, the actual content of technical files, and production address information.

Common scenarios include: a company already holds an NMPA registration but plans to enter Southeast Asia, the Middle East, or Latin America, and finds that the ISO 13485 certificate's scope does not cover the software product; or a company holds a CE certificate but the target GHWP member country requires an MDSAP certificate, which the existing quality system cannot satisfy; or after a software version upgrade, the quality system documents and control measures were not updated in sync, causing inconsistencies in version numbers and cybersecurity descriptions between the certificate and the technical files.

The core issue in such projects is that companies lack a “registration chain of evidence” mindset. They treat quality system certificates as an isolated document and ignore the underlying system operation evidence, the relationship between the product and the system, and the target country's localization requirements for system certificates.

Registration Judgment Logic

When facing quality system certificate inconsistencies, companies should make judgments in a logical order.

Step 1: Determine Whether the Product is Regulated as a Medical Device in the Target Country

Software medical devices are regulated differently across markets. Some are managed as medical devices themselves, some as accessories or SaMD, and some may be classified as health software rather than medical devices. Companies should first consult the target country's regulatory authority definitions for software devices, such as the FDA SaMD framework in the United States, the MDCG guidance under the EU MDR, and the IMDRF SaMD classification referenced by some Southeast Asian countries, to determine whether registration is required.

Step 2: Confirm Risk Class and Registration Pathway

Assess the software risk level according to target country requirements, for example, by classifying according to IEC 62304 safety classes or the IMDRF risk framework. This determines whether the registration pathway is self-declaration, registration filing, or a substantive registration application submitted through a local agent. Different pathways have different requirements for quality system evidence. Substantive registration often requires an ISO 13485 certificate and evidence of system operation, while self-declaration may only require basic proof.

Step 3: Evaluate Reusability of Existing Quality System Certificates

List all existing certificates and compare them against target country requirements: certificate type, issuing body, certification standard version, covered product scope, production address, and validity period. Focus on whether the certificate covers the software product and includes relevant requirements for software lifecycle processes, cybersecurity, and risk management.

Step 4: Verify Consistency Between Technical Files and System Evidence

Even if certificates are valid, cross-check the quality system certificates against the software description, version number, risk management report, clinical evaluation, and labeling in the product registration technical files. If any version mismatch or coverage gap exists, a consistency correction plan must be established in advance.

For multi-country registration scenarios, companies should identify a “baseline quality system certificate” (such as ISO 13485 or MDSAP) as the underlying support for global registration, and then make supplementary localizations for specific countries, rather than rebuilding a new system for each country.

Documents and Evidence

Solving quality system certificate inconsistencies relies on a complete evidence package, not just replacing a certificate.

• Valid quality system certificates, including ISO 13485, MDSAP, or other certification recognized by the target country.
• Certificate attachments or scope descriptions to prove that the software product is covered.
• Quality manual and procedure documents, especially procedures related to software lifecycle, risk management, configuration management, version control, cybersecurity, and post-market surveillance.
• Verification and validation records for the software product, including development testing, performance verification, reliability verification, and regression test reports after updates.
• Risk management documents, including risk assessment, risk control measures, and residual risk evaluation.
• Clinical evaluation or clinical evidence if the software claims clinical use.
• Labels, instructions for use, and user training materials.
• Agreement with a local agent or authorized representative clarifying regulatory communication, certificate holding, and change notification responsibilities.
• Post-market surveillance system documents, including complaint handling, adverse event reporting, post-update surveillance plans, and periodic risk summary reports.

Companies should establish a version baseline for these documents to ensure they match the software version submitted for registration, and use a traceability matrix to map system evidence, technical files, and application documents.

Common Mistakes

• Only checking certificate validity without reviewing the certificate attachment and scope, resulting in submitted system evidence that does not cover the software product.
• The standard version used in the certificate does not match the target country requirement, e.g., the target country requires ISO 13485:2016 but the certificate is still the old version.
• After a software version upgrade, the quality system documents and technical files are not updated in sync, causing conflicts in version numbers, function descriptions, and risk analyses.
• Production or R&D address changes are not promptly updated on the certificate or reported to the target country regulatory authority.
• Ignoring cybersecurity requirements; the quality system lacks corresponding evidence for IEC 62304, ISO 27001, or specific national cybersecurity guidelines, leading to deficiencies.
• Directly translating NMPA system documents without adapting to the target country's regulations, such as missing documents required by the local agent or locally required language labels.
• Blindly trusting third-party consultants' “guaranteed approval” promises and neglecting the completeness of internal system operation evidence.
• Repeatedly organizing documents for multi-country registrations without establishing a unified evidence baseline, causing significant rework for each country.

Company Preparation Checklist

• Establish a cross-functional team consisting of registration, quality, R&D, and overseas business personnel to develop a quality system certificate consistency checklist.
• Sort out the number of target countries, registration pathways, and system requirements to determine which certificates, scopes, and standard versions are needed.
• Review existing system certificates and attachments to verify whether they cover the software product, validity periods, and address information.
• Build a traceability matrix linking software versions, system documents, and technical files to ensure controlled synchronization of every update.
• Prepare quality system procedure documents and records covering software lifecycle, risk management, cybersecurity, labeling, and post-market surveillance in advance.
• Sign agreements with local agents or authorized representatives defining certificate control, regulatory communication, and change notification obligations.
• Conduct an internal compliance review of system evidence and application documents before the first registration, and rectify any issues immediately.
• Develop a multi-country registration document reuse strategy, defining the core document library and localization conversion guidelines to reduce repeated work and deficiency risks.

AIMEILI Regulatory Interpretation and Business Impact

The most common misjudgment in overseas registration of software medical devices is treating quality system certificates as just “a piece of paper.” Some companies only start looking for certificates at the deficiency stage, not realizing that regulators actually examine the system operation capability behind the certificates. Before starting a project, companies should perform a thorough gap analysis: compare the target country's regulatory requirements with your existing system documents line by line, and identify gaps in certificate coverage, standard versions, software lifecycle management, cybersecurity, and post-market surveillance.

Many companies spend time searching for a “universal certificate” and neglect building an internally consistent chain of evidence, resulting in repeated failures due to version mismatches or scope exclusions. In terms of document reuse, ISO 13485 and MDSAP certificates and corresponding system documents are usually reusable, but you must confirm that the certification scope covers the software product. Technical files, risk management reports, and clinical evaluation reports can reuse underlying data, but labeling, local language documents, and some risk management sections must be localized. For GHWP member countries and Southeast Asian markets, pay special attention to the role of local agents and authorized representatives. Control of certificates must remain with the company or a trusted agent; otherwise, subsequent changes, renewals, and adverse event reporting will become very passive.

For multi-country registration, we recommend that companies do not organize quality system documents separately for each country. Instead, build a “master evidence package” containing core system files, product technical files, and risk evidence, and then add variable supplements according to target country requirements. This approach reduces repetitive work and effectively avoids deficiencies caused by version inconsistency. Inconsistency in system certificates is never a single-certificate problem; it is a systemic issue that must be resolved simultaneously from three dimensions: system operation, technical files, and registration process.

Frequently Asked Questions

If the quality system certificate scope does not include our software product, can we substitute other documents?

No, substitution is not acceptable. Regulatory authorities usually require the quality system certificate to cover the software product; otherwise, they determine that the system operation is not relevant to the product. The company should apply to the certifying body to expand the certification scope as soon as possible, and submit alternative evidence of system coverage, such as internal audit records and management review reports, along with an explanation of why the product was not covered. However, the safest course is to complete scope expansion promptly and avoid prolonged reliance on alternative evidence.

Does an MDSAP certificate automatically satisfy all target country requirements?

No. MDSAP is a system audit program recognised by certain countries, but it does not mean all regulatory authorities accept it. Companies must still verify whether the target country accepts MDSAP certificates, or whether a local ISO 13485 certificate is required. Even if MDSAP is accepted, check that the manufacturing addresses and relevant procedures on the certificate cover the software product.

After a software version update, does the system evidence need to be resubmitted?

Yes. A software version update may involve changes to functions, algorithms, or applicable standards. The design and development change control, risk management, and verification records in the quality system must be updated accordingly. If the update affects the registered content, a change notification should be submitted to the regulatory authority, and a registration amendment may be necessary. The system certificate itself may not need to be replaced, but evidence of system operation must match the latest version.

Related Reading

• What to Prepare Before Renewing Overseas Registration for Software Medical Devices?
• How to Prepare Performance Verification Documents for Overseas Registration of Home Medical Devices?