Software Medical Device Registration Requirements in China

1. Key takeaways

Software studies are one of the nine non-clinical study types in Article 28 of the Medical Device Registration and Filing Measures (SAMR Order No. 47, published 26 August 2021, effective 1 October 2021). A device containing a software component, or a standalone software device, must complete this work before applying.

• The skeleton of a software submission is the software life cycle. It answers not whether the software runs but how it is developed, maintained, changed and retired.
• Version naming is a change classification matter: how the number moves determines whether a variation or thirty-day filing follows under Article 79.
• Cybersecurity is now a separate block. For connected software, remote updates and external data exchange, the completeness of cybersecurity material directly affects the review conclusion.
• Article 29 requires method validation, and where statistics apply, the statistical method, sample size basis and acceptance criteria, which govern algorithm performance confirmation and dataset design. Article 31 means the evidence must follow the version.
• GRZAN’s assessment: the difficulty is keeping evidence aligned with versions; losing control leaves the filed, verified and marketed versions inconsistent, inviting systemic challenge.

2. Legal basis

Administrative regulation. The Regulation (State Council Order No. 739, published 9 February 2021, effective 1 June 2021) provides:

• Article 5: supervision follows risk management, whole-process control, scientific oversight and social co-governance.
• Article 14: seven categories of materials, including risk analysis, technical requirements, test report and clinical evaluation.
• Article 21: substantive changes to a registered product require variation registration; other changes are filed or reported.
• Article 22: five-year certificate term; renewal filed six months before expiry.

Departmental rule. Order No. 47 specifies:

• Article 19: applicable mandatory standards met; inapplicable ones explained with materials.
• Article 24: risk management across the life cycle. Article 26: objectively determinable specifications and test methods.
• Article 28: the nine study types include software.
• Article 29: method validation required; where statistics apply, the statistical method, sample size basis and acceptance criteria must be specified.
• Article 30: testing against the requirements must pass before trials or application. Article 31: samples must represent the product applied for.
• Article 41: deficiencies notified once in full, answered once within one year, otherwise review terminates with a refusal.
• Article 79: substantive changes require variation; other changes are filed within thirty days; certificate items fall to variation, holder and agent details to filing.

The Provisions (former CFDA Order No. 6) require in Article 4 that content be scientific, true, complete and accurate and consistent with the registered content, and in Article 9 that text be in Chinese.

Normative documents. Announcement No. 121 of 2021 sets the dossier catalogue. No. 63 of 2025, Part Four, clarifies review requirements and covers artificial intelligence, medical robots, high-end imaging and novel biomaterials. No. 126 governs self-testing; the QMS inspection guide (notice No. 50 of 2022) defines four outcomes. Standards referenced are IEC 62304 for software life-cycle processes, ISO 14971 for risk management and IEC 60601 for electrical safety and essential performance.

Background: the 2025 Annual Medical Device Registration Report (NMPA, published 24 February 2026) records 76 innovative devices approved in 2025, up 17 per cent, and 25 priority review devices, up 212.5 per cent; software and AI remain a high share of both.

Practical estimate: version numbering rules, life-cycle documentation depth and cybersecurity content have no clause-level mandatory format; current guidelines, review points and recommended standards govern. Search guidance separately for standalone software and components, and design naming with change classification.

3. Expert insights

Process credibility, not only correct results. A physicochemical study can close with a test report; software cannot, because any change may alter clinical behaviour and is invisible on the finished product, so Article 28 focuses on process.

The fourth row is the most neglected, yet it sets post-market compliance cost.

Standalone software and software components. Both fall under Article 28, but the documentation differs.

The test is whether the product is marketed as a device in its own right; getting it wrong misaligns the whole documentation set and causes rework.

Version naming as a compliance interface. A four-segment scheme, bound to regulatory actions, works well.

Write the table into the change control procedure with trigger examples per segment; otherwise each upgrade needs an improvised route decision, inviting missed or incorrect notifications.

Cybersecurity is a separate block. Functional verification asks whether the software performs its task; cybersecurity asks whether it stays safe under attack, data corruption or environmental abnormality. Four layers apply: data confidentiality, integrity and availability; access authentication; interface security and encryption; and abnormal handling with fail-safe states. Identify hazard scenarios in the risk file, state controls and prove effectiveness with test or analysis evidence; one missing link breaks the chain.

Statistics in algorithm confirmation. Three points: dataset design, meaning how training, tuning and test sets are split and kept independent, with sources, inclusion criteria and population distribution; sample size per dataset rather than whatever data exist, including rare classes and subgroups; and criteria, meaning target values and acceptance limits for sensitivity, specificity, accuracy and similar measures, with their basis. All three must be fixed before development and validation.

Version consistency. Article 31 extends to four versions: the verification version used in algorithm studies, the testing version in the submitted sample, the filing version in the dossier and the marketed version first delivered. They should match, and differences must be explained. The usual break is algorithm confirmation completed mid-development with later fixes never re-confirmed; a hard rule requiring a consistency review before every release prevents it.

4. Practical recommendations

• Decide standalone or component status first, then align the unit and documentation.
• Build a requirements traceability matrix through design, implementation and test.
• Bind each version segment to a regulatory action, with examples.
• Organise cybersecurity across data, access, transmission and runtime layers with control evidence.
• Fix dataset splitting rules and independence before algorithm development.
• State sample size basis and criteria, including subgroup considerations (Article 29).
• Trigger a consistency review at every pre-market version change.
• After a version change, decide between variation and thirty-day filing (Article 79).

5. Verification checklist

• □ Software studies completed under Article 28, covering both forms?
• □ Standalone or component status determined, documentation aligned?
• □ Life-cycle documents complete, with a traceability matrix from requirements to test?
• □ Risk file covers failure modes with control evidence?
• □ Naming rule set, each segment mapped to an action?
• □ Cybersecurity across four layers with scenarios, controls and evidence?
• □ Dataset split, independence, sources, inclusion criteria explained?
• □ Sample size basis per dataset, including subgroups (Article 29)?
• □ Target values, acceptance limits and their basis defined?
• □ Four versions consistent, differences explained (Article 31)?
• □ Chinese interface and instructions consistent with registered content?
• □ Cited standards current; inapplicable ones explained (Article 19)?
• □ After version change, variation or filing decided (Article 79)?
• □ Correction answered once within one year (Article 41)?

Regulatory information verified as at 29 October 2026. Legal texts follow the versions published by NMPA, SAMR and gov.cn and must be rechecked after amendment or repeal. Time limits, fees and catalogue scope reflect the official position on that date; content marked practical estimate has no legal effect.

How GRZAN can help. GRZAN provides medical device and IVD registration, quality system, authorised representative and local testing support for the Chinese market. Our team prepares NMPA-compliant dossiers, coordinates typetesting and clinical evaluation documents, and supports post-market vigilance obligations. Business enquiries: info@grzanglobal.com