Drugdu.com expert's response:

I. How to Determine if a Software is Medical Device Software?

In simple terms, for the European Union (EU), a software is considered medical device software (MDSW) when it meets three conditions simultaneously:

It Performs Medical Tasks

For example, diagnosing diseases, monitoring conditions, treating patients, or assisting in surgeries. If it merely records exercise steps, reminds users to drink water, or sends notifications to doctors (without involving medical decision-making), it doesn't qualify.

Examples: A software that analyzes electrocardiogram (ECG) data to assess heart disease risk is medical device software; a fitness app that records daily step counts is not.

It Processes Data

The software should not just store or display data (such as an electronic medical record system). It must analyze, calculate, modify the data, and then generate medical-related results.

Examples: A software that automatically marks tumor locations based on computed tomography (CT) images is medical device software; a cloud drive that simply stores CT images is not.

It is Directly Used for Patients

The software's functions must target specific patients, rather than being used for hospital statistics, doctor training, or data analysis by researchers.

Examples: A software that recommends insulin doses based on blood glucose data from diabetic patients is medical device software; a reporting tool that counts the number of diabetic patients in the entire hospital is not.

Special Cases: If the software "drives" hardware medical devices (such as software that controls an insulin pump), its classification is the same as that of the hardware device. If it merely "assists" the hardware (such as software that analyzes magnetic resonance imaging (MRI) images), it is classified based on its own risk level.

II. How is Medical Device Software Classified? Higher Risk, Stricter Requirements

The EU classifies medical device software into four categories from low to high risk: Class I, Class IIa, Class IIb, and Class III. The classification mainly depends on the potential harm to patients if the software malfunctions:

Class I (Low Risk)

The software only provides general health advice and does not directly participate in medical decision-making.

Examples: An app that teaches you how to eat healthily; a tool that records sleep time without analyzing the data.

Compliance Requirements: The manufacturer can simply make a declaration stating "I comply with the Medical Device Regulation (MDR)" without review by a notified body.

Class IIa (Medium-Low Risk)

The software is used to assist in diagnosis or treatment, but malfunctions will not immediately endanger lives.

Examples: A consultation software that recommends possible diseases based on patient symptoms; a tool that monitors blood glucose but does not automatically adjust insulin doses.

Compliance Requirements: Review by a notified body is required, and technical documentation and a clinical evaluation report must be submitted.

Class IIb (Medium-High Risk)

The software monitors critical physiological parameters (such as heart rate and blood pressure) or is used for long-term management of chronic diseases. Malfunctions may lead to serious health problems.

Examples: Software that monitors premature ventricular contractions in real time; a system for tracking chemotherapy side effects in cancer patients.

Compliance Requirements: The review by the notified body is more stringent, and clinical trial data may be required.

Class III (High Risk)

The software is used for critical care monitoring (such as controlling equipment in an intensive care unit (ICU)) or malfunctions will directly result in death or disability.

Examples: AI-assisted surgical robot control software; software that controls a ventilator in real time.

Compliance Requirements: It must pass review by a notified body, detailed clinical data must be submitted, and post-market risk monitoring is required.

Key Reminders:

If the software is modular (for example, a software with multiple parts such as "data entry," "AI analysis," and "report generation"), each module is classified separately, and the overall classification is based on the module with the highest risk.

For AI-driven software (such as software that uses machine learning for disease diagnosis), the EU will also conduct additional checks on algorithm transparency, data bias, and the reliability of the model after updates.

III. 2025 Update: App Stores Are Also Subject to Regulation!

The EU now requires the following:

If an app listed on an app store claims to be a medical device (such as a "skin cancer detection app"), the platform must check whether it has CE certification and disclose manufacturer information, product identification (Unique Device Identification, UDI), etc.
The platform may conduct random inspections to ensure that the software continuously complies with MDR requirements. Otherwise, the app may be removed from the store or the platform may face fines.

Summary: The core of the EU's regulation of medical device software is "higher risk, stricter requirements." Manufacturers need to first determine whether their software is a medical device and then prepare compliance documents according to the risk classification. Especially for high-risk software (Class IIb/III), more time and money may be required for clinical trials.