How is medical software classified under the MDR?

First qualify, then classify

Before determining the risk class, the question arises whether the application is even Medical Device Software (MDSW). The decisive factor is the medical intended purpose defined by the manufacturer according to Article 2 numbers 1 and 12 of Regulation (EU) 2017/745 (MDR). Software that merely manages appointments, billing, or unchanged documents does not become a medical device solely by being used in a hospital. However, if it processes or interprets data for diagnosis, prognosis, monitoring, or therapy, it may fall under the MDR. MDCG 2019-11 Rev. 1 emphasizes that platform, cloud operation, or embedding in hardware does not change this fundamental decision.

Rule 11 as a starting point

For standalone medical software, Rule 11 in Annex VIII is often applicable:

• Information for diagnostic or therapeutic decisions generally leads to Class IIa.
• If a decision based on this could cause a serious deterioration or require surgical intervention, Class IIb is provided.
• If it could cause death or irreversible deterioration, Class III is considered.
• Software for monitoring physiological processes is generally Class IIa; for vital parameters and potential immediate danger, Class IIb.
• Other software not subject to a more specific rule falls under Class I according to Rule 11.

Other rules must not be overlooked. Rule 15 covers software for contraception, Rule 22 addresses closed control loops where the diagnostic function significantly determines patient management. Software that controls or influences a hardware product is generally assigned to the same class as that product according to Annex VIII number 3.3.

The justification must be verifiable

Classification should be structured as a documented decision-making process: precise intended purpose, user and patient group, input data, output information, clinical context, foreseeable malfunction, and potential severity of harm. Functions or modules may need to be evaluated separately if only part of them fulfills a medical intended purpose. The highest applicable rule decides; a blanket statement like "health app = Class I" is insufficient.

The classification affects conformity assessment, involvement of a notified body, and the extent of evidence required. Therefore, it must be established before architectural and market access decisions and re-evaluated upon changes. This overview serves as a framework; the binding classification depends on the specific product and its documented intended purpose.