Class I
Class I devices are considered low-risk. They include software that performs simple tasks like providing information to support self-management of a health condition or offering general health advice. For instance, wellness apps that track fitness or nutrition data without making clinical decisions would fall into this category. The regulatory requirements for Class I devices are relatively straightforward, focusing on ensuring basic safety and performance.
Class IIa
Class IIa devices present a moderate risk. These include software that provides information used to make decisions that have a direct impact on patient care but are not critical to the immediate health of the patient. An example would be software that processes patient data to support diagnostic decisions by healthcare professionals. The regulatory requirements for Class IIa devices are more rigorous than for Class I, involving more detailed safety and performance evaluations.
Class IIb
Class IIb devices are higher-risk and include software that directly influences treatment decisions or is used to monitor vital physiological parameters where inaccuracies could result in serious health consequences. For example, software that controls or monitors the delivery of medication falls into this category. The regulatory pathway for Class IIb devices is stringent, requiring thorough clinical evaluations and evidence of safety and performance.
Class III
Class III devices represent the highest risk. These include software that makes critical decisions about patient care, such as controlling a life-sustaining device or software intended for diagnosing or treating life-threatening conditions. Due to the potential for severe consequences if the software malfunctions, Class III devices undergo the most rigorous regulatory scrutiny, including comprehensive clinical investigations and continuous post-market surveillance.
Determining the Classification
The classification of software as a medical device is determined based on the intended purpose of the software and the potential risk it poses to patients. The International Medical Device Regulators Forum (IMDRF) provides a widely recognised framework that helps in this determination. This framework evaluates several factors, including the significance of the information provided by the software to healthcare decisions and the healthcare situation or condition managed by the software.
In England, the MHRA follows the guidelines laid out by the European Medical Devices Regulation (MDR) and the UK Medical Devices Regulations 2002, which are aligned with the IMDRF framework. Innovators can use the following steps to ascertain their software as a medical device classification:
- Identify the Intended Use: Clearly define what the software is designed to do. Is it for diagnosis, monitoring, treatment, or prevention of a disease? The intended use directly impacts the classification.
- Evaluate the Risk: Assess the potential risk associated with the software’s use. Consider the severity of the condition it addresses and the consequences of inaccurate information or malfunction.
- Refer to the Classification Rules: Use the classification rules provided in the MDR, which outline specific criteria for different classes of devices based on their intended use and risk level.
Self-Certification for software as a medical device
In certain cases, software as a medical device can be self-certified, meaning the digital health innovator can declare conformity without the need for a notified body’s involvement. This is typically applicable for lower-risk devices, such as Class I devices. Self-certification involves the following steps:
Conduct a Risk Assessment: Ensure the software falls within the low-risk category of Class I devices by evaluating its intended use and associated risks.
Prepare Technical Documentation: Compile comprehensive technical documentation demonstrating that the device meets all regulatory requirements. This includes a description of the software, its intended use, design and development processes, risk management, and clinical evaluation.
Affix the CE Mark: Once compliance is assured, the manufacturer can affix the CE mark to the device, signifying conformity with the relevant regulations. For self-certified Class I devices, this can be done without the involvement of a notified body.
Register with the MHRA: Before placing the device on the market, the manufacturer must register the device with the MHRA, providing necessary details and documentation.
For higher-risk devices (Class IIa, IIb, and III), the involvement of a notified body is usually mandatory. These bodies conduct a thorough review of the technical documentation, perform audits, and issue conformity certificates.
Conclusion
Understanding these classifications is essential for digital health innovators as it impacts the development, testing, and approval processes. Navigating these regulatory requirements can be complex, but it is necessary to ensure that the software is safe and effective for patient use.
By staying informed about the classification and regulatory requirements of software as a medical device, innovators can better prepare for the challenges and opportunities in the digital health space. The future of healthcare is digital, and understanding these fundamentals is the first step towards creating impactful and safe medical software solutions.
At 6B, we provide expert support to help innovators successfully develop and launch their software as a medical device, ensuring compliance with all relevant regulations, if you are interested in software as a medical device development contact 6B today – https://6b.digital/contact.
