After digital health products shift from concept verification to practical registration, applicants need to prioritize core questions beyond product innovation: whether the product falls under medical device scope, its classification category, and whether software, data, algorithms and clinical evidence can support registration submission. this article serves as the opening chapter of digital health medical device registration series, helping project teams build a compliance evaluation framework at early project initiation.
In the past few years, digital health products including remote monitoring tools, chronic disease management software, ai-aided diagnosis, digital therapeutics, wearable devices and hospital data analysis platforms have gained rapid popularity. many projects are defined as health management tools or data service platforms in business plans. however, in actual registration practices, regulatory judgment is not based on product forms such as apps, cloud platforms or algorithm models, but on the intended use and associated risk level of products.
In accordance with medical device classification rules, product classification is comprehensively determined by structural features, application mode and usage conditions. for digital health products, any function involving disease diagnosis, treatment, monitoring, auxiliary clinical decision-making or rehabilitation intervention requires careful assessment for inclusion under medical device regulatory control.
Therefore, the first step for digital health product registration is not rushing to compile application documents, but clarifying product attributes, applicable scenarios, output results and boundaries of clinical application.
Many applicants tend to confuse common software products with medical device software in the early development stage. in fact, even for software products, those only applied for health popular science, lifestyle logging and general information display are generally exempted from medical device registration management. by contrast, software designed for medical image analysis, lesion identification, vital sign monitoring, disease risk warning, treatment regimen recommendation or clinical decision assistance may fall under medical device regulation.
Per the guidelines for classification determination of artificial intelligence-based medical software issued by nmpa, standalone ai software adopting medical device data for medical purposes shall be classified in line with the document. ai medical software with immature algorithms for auxiliary clinical decisions including lesion property identification, medication guidance and treatment planning is normally categorized as class iii medical device; products supplying clinical reference information instead of decision-making assistance are usually regulated as class ii medical device.
In short, developers of digital health projects need to confirm three core questions: whether processed data is medically relevant, whether output results serve clinical purposes, and whether such outputs will affect diagnosis and treatment decisions of physicians or patients.
01 Clarify Product Functions Intended Use, Target Users, Usage Scenarios | 02 Determine Medical Purpose Whether it is used for diagnosis, monitoring, treatment, rehabilitation or auxiliary decision-making | 03 Identify Data Sources Whether medical data, medical device data or patient-specific information is used | 04 Evaluate Output Impact Whether the output affects clinical judgment or patient behavior | 05 Compare with Regulatory Basis Classification catalog, guiding principles, similar approved products, classification definition when necessary |
| → | → | → | → | ↓ |
| Output Conclusion: Form "Product Attribute Judgment + Initial Management Category Judgment + Registration Path + Clinical Evaluation Strategy + Software/Data Documentation List" | ||||
Risk reminder prior to project initiation
Promotional descriptions of products can highlight innovation, whereas statements for registration submission shall be prudent, explicit and verifiable. overbroad definition of intended use may lead to higher product classification. ambiguous description on the correlation between algorithm output and clinical decision-making will increase workload for clinical evaluation and the risk of supplementary document requests from regulators.
The common compliance risks of digital health products lie not in missing functions, but in excessively broad functional boundaries, ambiguous usage scenarios, and over-promised output results. For example, if an imaging software is only used for image display, processing and measurement, the review focus is mainly on software functions, performance verification, data accuracy and risk control. However, if it further claims to identify lesions, judge lesion properties or provide diagnosis and treatment suggestions, it will be regulated under the scope of auxiliary diagnosis and clinical decision-making.
Mobile medical devices also require strict attention to boundary definition. The Guidelines for Registration Review of Mobile Medical Devices (2025 Revised Version) issued by the Center for Medical Device Evaluation (CMDE) of NMPA in 2025 defines mobile medical devices as medical devices that adopt mobile computing technology to realize one or more medical purposes. Their registration documents require systematic elaboration covering mobile terminals, network connections, software functions, data transmission and usage environments.
Therefore, applicants shall prepare two sets of standardized descriptions at the early R&D stage: one for market communication to highlight product value, and the other for registration submission focusing on intended use, applicable population, input data, output results, usage limitations and risk control.
Registration dossiers for digital health medical devices cover more than conventional documents including product overview, product specification, test reports and risk management files. for software as a medical device, applicants shall prepare traceable documents concerning software safety classification, system architecture, functional modules, version naming rules, development lifecycle, verification & validation, defect management and release control.
Where network access, remote maintenance, data exchange, cloud deployment or user access control are involved, supplementary cybersecurity documentation is required. for products equipped with ai algorithms, the evidence chain expands to training datasets, test datasets, labeling specifications, algorithm performance, generalization capability, bias mitigation, coverage of target population and governance of algorithm iteration.
| Registration Focus Points | Preparations Required by the Applicant | Common Risks |
|---|---|---|
Product Attributes | Product functions, intended use, applicable population, target users, usage scenarios | Describing general health management functions as disease diagnosis or treatment functions |
Classification Management | Refer to classification catalog, classification definition guidelines, and similar approved products | Determining the category solely based on competitor promotion and ignoring differences in specific applicable scopes |
Software Research | Software architecture, module description, version rules, verification and validation, defect management | Untraceable correspondence between software versions, test reports and registration documents |
Data Governance | Data sources, data quality, annotation rules, representativeness, privacy compliance | Unclear sources of training/test data and insufficient annotation consistency |
Algorithm Research | Performance indicators, generalization ability, bias analysis, applicable boundaries, update strategy | Only displaying algorithm accuracy without explanation of clinical applicable boundaries |
Cybersecurity | Access control, data transmission, remote maintenance, vulnerability response, user permissions | Ignoring risks caused by cloud deployment, interface calls and remote updates |
Clinical Evaluation | Preliminary judgment of clinical evaluation exemption, equivalent product evaluation, and clinical trial pathway | Discovering the lack of available clinical evidence or equivalent product data only before submission |
It is inappropriate to decide whether to conduct clinical evaluation of digital health medical devices right before dossier submission. Announcement No.73 issued by NMPA in 2021 released a series of technical guidelines covering clinical evaluation, clinical trial decision, equivalence demonstration and clinical evaluation report, establishing the fundamental framework for clinical evaluation of Class II and Class III medical devices.
Products with defined functions, manageable risks and sufficient comparable marketed products and clinical data may obtain clinical evidence via exemption catalogue from clinical evaluation, predicate device clinical evaluation, literature research and non-clinical verification. In contrast, devices for auxiliary diagnosis, clinical decision-making assistance and therapeutic intervention, or those featuring innovative algorithms and divergent applicable populations face heavy clinical evaluation burdens and may require pivotal clinical trials for registration.
This marks a core distinction between digital health products and traditional hardware medical devices: The complete evidence system relies not only on product performance testing, but also on the matching among datasets, algorithms and practical clinical scenarios. Applicants are required to verify product safety, effectiveness and risk controllability within specified intended scope instead of simply claiming favorable algorithm performance.
After digital health medical devices enter the practical registration stage, project teams need to realize a critical shift: instead of focusing R&D descriptions merely on product functions, they shall arrange R&D, clinical work and quality management around the registration evidence chain.
The R&D team shall incorporate software version control, algorithm iteration, data sources and risk control into the design and development process. The registration team shall confirm product attributes, classification routes and document checklist at an early stage. The clinical team shall assess the feasibility of clinical evaluation in advance. The quality management system needs to cover software lifecycle management, data administration, cybersecurity, post-market changes and adverse event surveillance.
For Deda Medical, its core support for digital health medical device projects is not drafting registration documents on behalf of applicants, but assisting clients in making critical judgments in early development: whether the product falls into medical device scope, its potential risk classification, customized registration strategy, compilation of software research files, adequacy of clinical evaluation evidence, and necessity of clinical trials or regulatory communication.
Industrial opportunities in digital health keep expanding, yet the timeline for registration compliance moves forward. Integrating software, data, algorithms and clinical evidence into one complete registration evidence chain at an earlier stage helps reduce review uncertainties and streamline the whole marketing approval pathway.
Project support available from Deda Medical
Focusing on digital health medical devices, software-based medical devices and AI medical devices, Deda Medical provides services including product attribute identification, classification consultation, registration route planning, clinical evaluation strategy formulation, collation of software research documentation, cybersecurity document preparation, predicate device evaluation and compilation of full registration dossiers, helping applicants identify compliance risks in the early R&D phase.
1. NMPA: Medical Device Classification Rules (Order No. 15)
2. NMPA: Medical Device Classification Catalog (Announcement No. 104, 2017)
6. IMDRF: SaMD Risk Categorization Framework (IMDRF/SaMD WG/N12FINAL:2014)
7. FDA: Clinical Decision Support Software Guidance
8. FDA: Artificial Intelligence-Enabled Device Software Functions Guidance
For customized registration strategy support, please contact our professional team to obtain the Medical Device Classification Catalog and one-on-one consultation.
This content is compiled based on public regulatory documents of the National Medical Products Administration for reference only. Specific registration strategies shall be formulated in combination with product characteristics and the latest regulatory requirements, and sufficient communication with regulatory authorities at key nodes is recommended.
