You may not have initially considered that your software product could fall under the umbrella of medical device regulation. However, it’s important to understand that any software used to diagnose, prevent, or treat a medical condition is considered a “software medical device” and is subject to specific regulations. In the coming blog posts, we’ll delve into different frameworks in place for software medical devices in the US and EU. The main purpose of these blog posts is to give guidance and some examples how SW development process and related Quality management systems (QMS) can be implemented so that developers can still focus their time to do productive development work.
Our company has worked over 18 years in SW development, project management & business development fields and in the coming blog posts we try to highlight some of the main points that may help you around software medical device development area.
FDA and EMA
Classification in the US
In the US, the Food and Drug Administration (FDA) is responsible for regulating software medical devices. The FDA has established a framework for regulating these devices, which includes both pre-market and post-market requirements. Pre-market requirements involve submitting your software for review before it can be sold or distributed, while post-market requirements involve ongoing monitoring and reporting to ensure that the software continues to meet safety and effectiveness standards.
In the United States, medical devices are classified by the FDA into three main categories based on the level of risk they pose to patients:
Class I:
Class I devices pose the lowest level of risk to patients. Examples of Class I devices include bandages, elastic bandages, examination gloves, and simple pill reminder mobile applications. These devices are subject to the least regulatory controls.
Class II:
Class II devices pose a moderate level of risk to patients. Examples of Class II devices include powered wheelchairs, contact lenses, and pregnancy test kits. These devices are subject to more regulatory controls than Class I devices, but fewer controls than Class III devices.
Class III:
Class III devices pose the highest level of risk to patients. Examples of Class III devices include implantable pacemakers, artificial hearts, and drug-eluting stents. These devices are subject to the most regulatory controls, and they must undergo a more rigorous approval process before they can be marketed in the United States.
Classification in EU
In the EU, the regulatory framework for software medical devices is managed by the European Medicines Agency (EMA). Similar to the FDA, the EMA has established pre-market and post-market requirements for software medical devices, including requirements for clinical evaluation and performance monitoring.
In the EU, medical devices are classified by the Medical Device Regulation (MDR) into four main categories based on the level of risk they pose to patients:
Class I:
Class I devices pose the lowest level of risk to patients. Examples of Class I devices include bandages, elastic bandages, and examination gloves. These devices are subject to the least regulatory controls.
Class IIa:
Class IIa devices pose a moderate level of risk to patients. Examples of Class IIa devices include powered wheelchairs, contact lenses, pregnancy test kits, and simple pill reminder mobile applications. These devices are subject to more regulatory controls than Class I devices, but fewer controls than Class IIb or III devices.
Class IIb:
Class IIb devices pose a higher level of risk to patients than Class IIa devices. Examples of Class IIb devices include implantable pacemakers, artificial hearts, and drug-eluting stents. These devices are subject to more regulatory controls than Class IIa devices, but fewer controls than Class III devices.
Class III:
Class III devices pose the highest level of risk to patients. Examples of Class III devices include artificial hearts, heart valves, and implantable neurostimulators. These devices are subject to the most regulatory controls, and they must undergo a more rigorous approval process before they can be marketed in the EU.
It’s important to note that both the FDA and EMA have different categories for software medical devices, based on the level of risk they pose to patients. This can range from Class I devices, which pose the lowest level of risk, to Class III devices, which pose the highest level of risk. To get started you can check EMA’s guidance how to identify correct classification for your product. The regulatory requirements for each class of device will vary, so it’s important to understand which class your software falls into and follow the appropriate guidelines. In most of the cases an mobile / web app is falling into Class IIa (EU) and Class I (US) category and during these blog post we’ll use Class IIa as an example case.
Evaluating classification and QMS
If you’re developing software that you think may be considered a software medical device, it’s crucial to familiarize yourself with the relevant regulations and make sure that you’re following them. This may involve seeking guidance from regulatory bodies, working with a medical professional to ensure that your software meets medical standards, or engaging a third-party to conduct testing and evaluation. Overall, understanding and following the appropriate regulations for software medical devices is essential to ensure that these products are safe and effective for use in a medical setting. By familiarizing yourself with the regulatory frameworks in place in the US and EU and working closely with regulatory bodies and medical professionals, you can ensure that your software meets the necessary standards and can make a positive impact on people’s health and well-being.
In both cases (US and EU) the regulation forces the developer to implement a quality management systems (QMS). QMS are a set of policies, processes, and procedures that organizations use to ensure that their products and services meet the necessary quality standards. In the context of software medical devices, a QMS helps to ensure that the software is safe, effective, and reliable for use in a medical setting. This can involve implementing processes for testing and evaluation, documentation management, and continuous improvement. A well-designed QMS can help organizations to identify and address potential issues early on, ensuring that their software meets the necessary regulatory standards and can be trusted by users. In practise this can be really painful for developers, because in the worse case a QMS may reduce your productivity by over 50% but this can be avoided by implementing modern SaaS tools and fine tuning QMS processes.
