According to industry experts1, the medical device software market is expected to grow 69% between 2019 and 2026. This incredible growth is in part thanks to mobile devices and platforms, cloud-based software, and integration with advanced technologies.
If you are in the early stages of developing your medical device software project, it can be overwhelming to understand how to effectively get your medical device software to market. To give you a better understanding of the steps required, take a few minutes to learn about the categories of medical device software.
Categories of medical device software
Medical device software is classified into four main subclasses:
- Software as Medical Device (SaMD)
- Examples of SaMD are standalone software that services a medical product, like an app that calculates appropriate insulin dosage based on a person’s blood glucose levels; or software that uses artificial intelligence (AI) to review MRIs for anomalies.
- Software in a Medical Device (SiMD)
- Sometimes called “embedded” medical device software, it is integral to the medical device, such as that which controls a device through Bluetooth or WiFi; or software that operates a pacemaker.
- Software as an accessory to a medical device
- Software that does not in itself have a medical purpose.
- General purpose software
- Software that is not a medical product by itself.
Medical Device Software Regulations
No matter the category of software, because it is a medical device, it needs to meet specific requirements to ensure its safe use. These requirements are laid out in the International Electrotechnical Commission (IEC) standard 62304. The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising all national electrotechnical committees.
There is also guidance from the United States Food & Drug Administration for software contained in medical devices.\
Safety & Level of Concern
Because the range of medical device software is so vast, both the FDA & IEC have developed classifications for SaMD. These classifications are based on the safety and level of concern the SaMD could present to patients.
IEC 63405 Safety Classes
Safety class, as defined in IEC 62304, is based on risk of harm to patient, operator, or other people resulting from a hazardous situation to which a software system can contribute in a worst-case scenario.
The safety classes are:
- Class A: Software cannot contribute to a hazardous situation or software failure does not result in unacceptable risk
- Class B: Software can contribute to a hazardous situation after external risk control measures, and the possible harm is non-serious injury
- Class C: Software can contribute to a hazardous situation after external risk control measures, and the possible harm is serious injury or death
Not sure?
When applying the IEC 62304 requirement, there are two principles you should understand:
- Highest Risk Applies in a Group
If your SaMD / SMD is part of a group of software items, the highest classified item drives the processes and tasks required for the whole group unless the Risk Management File contains rationale for using a lower classification. - Class C Applies
If you’re not sure what your SaMD / SMD safety classification is under IEC 62304, don’t worry. Until a software safety class is assigned, Class C requirements apply.
FDA Levels of Concern
The level of concern, based on the FDA guidance, comes from the “estimate of the severity of injury that a device could permit or inflict, either directly or indirectly, on a patient or operator as a result of device failures, design flaws, or simply by virtue of employing the device for its intended use.”
The levels of concern are:
- Minor: Failures or latent design flaws are unlikely to cause any injury to the patient or operator
- Moderate: A failure or latent design flaw could directly result in minor injury to the patient or operator, or indirectly result in minor injury to the patient or operator through incorrect or delayed information or through the action of a care provider
- Major: A failure or latent flaw could directly result in death or serious injury to the patient or operator, or indirectly result in death or serious injury of the patient or operator through incorrect or delayed information or through the action of a care provider
Aligned Medical Device Software Safety Classes
To simplify things a bit, we can group the two regulations together. IEC’s software safety class and FDA’s level of concern generally align as follows:
- Safety Class A generally aligns with a Minor Level of Concern
- Safety Class B generally aligns with a Moderate Level of Concern
- Safety Class C generally aligns with a Major Level of Concern
Medical Device Software Safety Class and Level of Concern
Once determined, the safety class and level of concern are documented in the Software Development Plan (SPD). The SDP is part of the basic software development life cycle. However, for software systems classified as Class B or C, additional risk control measures external to the software system may be implemented, allowing subsequent assignment of a new safety classification.
Next Steps
Once you’ve determined your SaMD requirements, you can really get into the software development life cycle activities like:
- Design review
- Requirements tracing
- Software problem resolution
- Risk management
- Software configuration management
If you’d like the opportunity to leverage our experience with QMS implementation for software-as-a-medical-device (SaMD) organizations to create a smarter Quality Management Systems (QMS) that is right-sized for your Medtech business no matter the field, contact us at marketing@cannonqg.com.
