The classification of medical device software (MDSWs) has very significant consequences for a manufacturer as the product life cycle reporting is strongly dependent on the risk class. Consequently, proposed changes in classification are a leading cause of concern owing to up-classification.
For manufacturers, a cautionary approach to Rule 11 may lead to situations where a previously class I device could now be class III, leading to a greater overall effort for clinical evaluation and compliance. It now appears that the characteristics of software that make them medical devices in the first place are likely to mean they must fall under Class IIa or higher, the principal exception being software having no medically related purposes. Since a vast majority of MDSWs are intended to provide information which will be used for decisions with a diagnostic or therapeutic purpose, it is understood that a large number of them will be starting at class IIa. To illustrate, software that is intended to monitor physiological processes, perform diagnoses using image analyses for treatment decisions, or software with a diagnostic function supporting a treatment path, would warrant the highest classification.
In an example of software cited that might fall under Class I, a patient-facing conception-support app that calculates a user’s fertility status based on various inputs, the Guidance implicitly states that a very narrow group of software devices could fall under Class I (those that do not have a medical purpose and are not accessories, however considered, to be devices under the MDR’s specific deeming rules).
Hypothetically, even if the software performs a relatively innocuous, medically related function, but if the resulting decision could potentially result in death or irreversible deterioration, a device is class III. On a real note though, very few decisions in the healthcare ecosystem would ever not result in death or irreversible deterioration in certain circumstances.
Introducing the term “Medical Device Software” MDSW, the MDCG describes the two sub-types as
- Independent MDSW providing information for diagnostic or therapeutic purposes:
o rule 11 a) Software providing information for diagnostic or therapeutic purposes (classes IIa – III),
o rule 11 b) Software monitoring physiological processes (classes IIa – IIb) and
o rule 11 c) all other Software (class I).
- MDSW driving or influencing the use of a hardware medical device. In this case, software must fall within the same class of device that it drives or influences.
Some of the key points addressed in MDCG 2019-11 are:
- In order to qualify as a medical device software and determine the risk class, a manufacturer must first establish the intended purpose. The significant task will be influenced largely by the product claims made by a manufacturer. For example, is the software used for direct diagnosis or interpretation or is it simply reporting vitals captured? Additionally, this depends on what the software intends to analyze – if the disease or condition needs a time-critical treatment, how fragile is the population impacted etc. However, the risk categorization does not necessarily clarify the difference between “diagnosis” and “support of diagnosis”, “screening” and “triage” and so forth. The needs of “fragile populations” are not addressed clearly and could require additional information depending on the criticality in question.
- Software, which drives a device or influences the use of a device, shall fall within the same class as the device. However, there are notable exceptions depending on the intended purpose of the software. One exception would be, for example, melanoma image analysis software to be used with a near-infrared laser light scanner, considered a Class IIa device under Rule 10 of the MDR This shows that since the tool enables cancer diagnosis, the software should be classified as Class III. Herein, Rule 11 and could have a significant impact for many software manufacturers.
- If a software drives or influences the use of a device and does not have or perform a medical purpose on its own, it may be qualified as an accessory and as such falls under the MDR/IVDR.
- Notably, software fulfilling a medical purpose cannot be an accessory.
- The Guidance also re-emphasizes that when two or more classification rules apply to the same software, the highest of the possible classifications applies.
- With regards to software that is independent of other devices, but not an accessory, (e.g., medical or patient-facing apps), the key considerations will be whether the software does more than data storage, archival, communication or simple searches and whether these actions are for individual patient benefit.
The sophistication and complexity of new technologies have resulted in greater reliance on software by patients and healthcare professionals alike, perhaps leading to the imposition of a higher level of scrutiny by the authorities. While some think this may deter the development of new software technologies, the Guidance document explains that these rules are designed to align the MDR with broader international guidance on software, and with guidance from the International Medical Device Regulators Forum.
Under the current rules, it is possible to have a modular approach to software qualification only if there can be a true separation in functionality. Different levels of risk are posed by software which acts directly in regards to a patient, and software which informs a clinician’s diagnostic or treatment decision. Software which is not directly treating or diagnosing a condition has a clear pathway to potentially justifying a lower classification.
Since classification is primarily based on the severity of the risk, if death or irreversible deterioration could potentially occur, it would be sufficient to re-classify the software as Class III, regardless of the actual risk of failure of the device, even if minimal or almost non-existent.
Thus, with an understanding that hardly any MDSW will remain as Class I under Rule 11, manufacturers and Notified Bodies must be cognizant of and prepare for an inevitable increased workload. A robust system of pre- and post-market data collection, coupled with a good risk management and quality management plan is thus absolutely essential for manufacturers to facilitate seamless dealings with Notified Bodies and Competent Authorities.