How Are Authorized Representative Responsibilities Divided for Overseas Registration of Software Medical Devices?

Key Summary

For software medical devices undergoing overseas registration, the division of responsibilities for the authorized representative depends on the regulatory requirements of the target market and the manufacturer's own registration strategy. The manufacturer must first determine whether the product falls within the scope of medical device regulation in the target country, and then identify the registration pathway based on risk classification. In GHWP member countries and the European Union, a local authorized representative or local agent is generally required to communicate with regulatory authorities, receive post-market surveillance information, and handle adverse event reports. The core of responsibility allocation lies in the ownership of localization tasks for technical documentation, quality systems, labels, and instructions for use, as well as post-market maintenance and change control duties. Manufacturers should prepare software description documents, cybersecurity statements, and clinical evaluation evidence that meet local requirements in advance, and define the authorized representative's scope of authority clearly. Common risks include unclear division of responsibility between the representative and the manufacturer, inaccurate document translation, and failure to notify the representative of changes in a timely manner. It is recommended that manufacturers define a clear responsibility list, response timeframes, and cost-sharing arrangements in the agreement, and establish a dual-review mechanism to ensure traceability of responsibilities in multi-country registrations.

For Chinese medical device enterprises, a prudent approach is to first conduct a product classification and documentation gap assessment, then determine whether NMPA, CE, FDA, ISO 13485, or other market documentation can be reused. Target-market registration typically affects technical files, the authorized representative, importer coordination, label language, quality system certification, and subsequent change maintenance. If the project is initially driven solely by a “list of documents to submit,” compensatory submissions or rework commonly arise regarding model coverage, evidence-chain consistency, label claims, and control over certificates. AIMEILI recommends that this issue be planned as part of a unified GHWP member state and multi-country market access strategy, using a reusable core technical documentation set to support localized submissions across different markets, rather than recreating documents for each country on an ad hoc basis.

This article is compiled based on the AIMEILI registration practice question bank, the medical device international registration knowledge base, and public regulatory information. For specific projects, the latest requirements of the target country's regulatory authority and the product documentation basis prevail.

Applicable Scenarios and Core Issues

In overseas registration of software medical devices, the authorized representative role is often regarded by companies as a “nominal agent.” However, regulatory authorities in different markets do not define the obligations of the authorized representative uniformly. If companies are unclear about responsibility allocation, they may find themselves in a passive position during the late registration stage, changes, or adverse event handling.

Scenarios discussed in this article include: Chinese software medical device developers submitting registration applications to GHWP member countries, the EU, Southeast Asia, or Latin American markets; companies that already hold an NMPA registration certificate or CE/FDA certificate intending to reuse documentation; and markets where designation of a local authorized representative or local agent is mandatory to complete registration.

Core issues include: Who continues to be responsible for the safety and effectiveness of the product? Does the authorized representative bear legal consequences? Who reports software updates or cybersecurity issues to the regulatory authority after market placement? And how can companies clearly establish boundaries through agreements and evidence chains?

Registration Decision Logic

Companies should first determine whether the product falls within the scope of medical device regulation in the target country. Software that merely provides health management functions may not be regulated as a medical device; software used for diagnosis, treatment decisions, monitoring, or physiological parameter analysis generally requires registration.

Next, determine the risk classification. Under the EU MDR, for example, software is generally classified as Class IIa or above, but some decision-support software may be classified as Class IIb or III. GHWP member countries each have their own classification rules, usually referencing the IMDRF software classification framework. The risk classification determines the registration pathway, depth of technical documentation, and whether a notified body must be involved.

With regard to the applicant entity, most markets require that the local registrant be a local entity, or that a local authorized representative serve as the compliance contact for the foreign manufacturer. In such cases, companies must distinguish between the “applicant” and the “manufacturer,” and clarify whether the authorized representative may submit the registration in its own name.

The next step is to assess the reusability of existing documentation. NMPA registration files, CE technical documentation, FDA 510(k) submissions, and ISO 13485 or MDSAP quality system certificates can serve as basic materials. However, they must be reassessed against the target country's requirements, particularly with respect to software description, cybersecurity, and clinical evaluation.

Finally, confirm whether labels, instructions for use, user interfaces, warnings, and after-sales maintenance plans require localization. The authorized representative is typically responsible for receiving local complaints and inquiries, but translation and adaptation work remains primarily with the manufacturer.

Documentation and Evidence

Companies should prepare at least the following documentation: software product description and intended purpose statement, risk management file (ISO 14971), usability engineering file (IEC 62366), cybersecurity documentation (e.g., IEC 81001-5-1), software lifecycle process documentation (IEC 62304), clinical evaluation or clinical evidence summary, label and instruction draft, and quality system certificates.

For the authorized representative, the following must be provided: evidence of legal entity status, authorization letter or agency agreement, communication record templates with the manufacturer, adverse event reporting procedures, and a change notification mechanism. Some markets require the authorized representative to hold relevant business qualifications or registration filing information.

Even when CE or FDA evidence already exists, direct copying is not possible. Different regulatory bodies have differences in requirements for algorithm interpretability, data integrity, and external interfaces. Companies should perform gap analyses based on the original versions and develop target-country-specific technical documentation.

Common Mistakes

• Treating a registration project as a simple document submission without first clarifying product classification, evidence coverage, and local responsibility relationships.
• Directly translating NMPA documentation for submission without reorganizing evidence according to the target market pathway.
• Having too many model variants while the test reports, clinical evidence, or labeling coverage are insufficient.
• Selecting a local agent only based on sales cooperation, without defining regulatory responsibilities, certificate control, and post-market maintenance duties.
• Inconsistencies among labels, instructions, promotional materials, and registration documents, leading to supplementary submissions or post-market compliance risks.
• Failing to plan for multi-country documentation reuse in advance, resulting in repeated compilation for each country, increasing cost and timelines.

Enterprise Preparation Checklist

• Confirm whether the target country regulates the software as a medical device and which authority is responsible.
• Determine the risk classification and registration pathway, and identify whether an authorized representative is required and what specific qualifications the representative must hold.
• Draft a “responsibility matrix table” listing responsible parties for registration, changes, post-market surveillance, complaint handling, adverse event reporting, etc.
• Collect and organize existing technical documentation, compare it to target country requirements, and produce a gap analysis report and correction plan.
• Sign a detailed agency agreement with the authorized representative, specifying authority, timeframes, fees, confidentiality, and liability for breach.
• Establish a change control process to ensure any software update, labeling modification, or major quality system change is promptly notified to the authorized representative.
• Assign an internal regulatory affairs officer as the point of contact and maintain regular communication with the authorized representative, at least quarterly.

AIMEILI's Perspective

The division of responsibilities for a software medical device authorized representative is essentially an extension of the manufacturer's quality system to the target market. The most common mistake companies make is treating the authorized representative as an “emergency contact” and failing to update the agreement and evidence after registration is completed. We recommend reviewing the responsibility matrix with the authorized representative at least every six months, and keeping the representative informed of software version upgrades, cybersecurity vulnerability fixes, and instructions for use changes.

At the project planning stage, we recommend conducting target-market regulatory due diligence before deciding whether to first obtain EU or Southeast Asian registration as a stepping stone or to directly enter higher-requirement markets. ISO 13485, MDSAP, CE, and NMPA documentation are often reusable, but clinical evaluation, software description, cybersecurity, and label localization must be redone or deeply adapted. For multi-country registration, we recommend using a unified Summary Technical Documentation (STED) framework and treating country-specific regulatory differences as “country-specific variations,” avoiding the need to compile full technical documentation separately for each country.

Local agents, certificate control, and change management must always remain with the manufacturer. The authorized representative does not have decision-making or control authority. If a company loses ownership of its certificate, multi-country registration may face uncontrollable risks. We recommend including in the agreement a clause that all regulatory communication records must be copied to the manufacturer, and that any withdrawal, suspension, or cancellation operation requires the manufacturer's written consent.

Common Follow-up Questions

Is the authorized representative equivalent to the registrant on the registration certificate?

In most regulatory systems, the registrant shown on the certificate can be the manufacturer itself or the authorized representative. If the manufacturer does not have a local entity in the target country, the authorized representative typically holds the certificate in its name, but the technical responsibility for product registration remains with the manufacturer. The specifics depend on the registration format. For example, EU MDR requires the certificate holder to be the registrant, and the registrant must be an entity established within the EU.

If the authorized representative is changed, can the original registration certificate still be used?

Most markets allow a change of authorized representative, but require a written change application to the regulatory authority and a handover letter from both the old and new representatives. The original certificate remains valid until the regulatory authority approves the change, but the manufacturer must immediately notify the previous representative to avoid rejection of regulatory communications. We recommend a parallel period of at least 90 days during the transition.

At what point does a software update require a new application to be filed through the authorized representative?

The key criterion is whether the update affects the intended purpose, safety, or basic performance. If it merely fixes interface text or minor bugs, recording it through the quality system and notifying the authorized representative is sufficient. If the algorithm model, target population, or diagnostic thresholds undergo major changes, a design change process must be followed and a new registration may be triggered. Companies should predefine a list of “major changes” in the agreement.

AIMEILI Regulatory Interpretation and Business Impact

This FAQ underscores the need for software medical device manufacturers to view the authorized representative not as a mere formality but as a critical compliance partner. The regulatory interpretation is that the authorized representative carries defined obligations under the target market's laws, including communication with authorities, post-market surveillance, and adverse event reporting. Business impact is significant: unclear responsibility division can lead to delayed registration, certificate loss, or post-market non-compliance, especially during software updates or cybersecurity incidents. Therefore, manufacturers should integrate the authorized representative into their overall quality system and multi-country registration strategy. AIMEILI advises adopting a reusable STED-based core technical file, maintaining a clear responsibility matrix, and ensuring contractually that the manufacturer retains decision-making authority and certificate control. This proactive approach minimizes rework, accelerates market access, and supports sustainable international growth.

For further guidance, consult AIMEILI's knowledge base or contact our regulatory affairs team.