If you are working with software for medical devices, you will inevitably have to deal with different classifications. In a larger company, there will be more people around you, but if you are working for a smaller one, all that burden may be yours.
This is by no means to intimidate you. On the contrary! Our online course Introduction to software for medical devices and IEC 62304 is tailored specifically to help those in this field of work.
Take a look at our video from the course dedicated to classification rules:
You might ask yourself several questions here:
- Why all these classifications?
- What are the differences among them?
- Do I need to know and use them all?
Keep reading and you will find all the answers in the article. If you like what you see, you can read more articles about medical devices here.
The four concepts in the medical device software classification
It might be confusing, in the beginning, to be presented with a total of four “competitors” when it comes to classification rules. First things first, so let us name them:
- Medical Device classification
- Software safety classification
- Level of concern
- SaMD (Software as Medical Device) classification
The term “competitors” is used jokingly, of course. The four classification systems listed above are not competing against each other – they simply serve different purposes, and they are all about to be explained some more.
Medical device classification
Medical device classification separates the products into classes according to risk. This is so important that most countries have regulatory requirements that depend on the device’s risk, and the riskier the product, the higher number of requirements there will be.
In this area, the classes range from relatively harmless products to riskier ones, and they are marked by using Roman numerals, as well as sub-classes (a, b).
Low-risk devices may not need interaction with the authorities or a notified body, but those riskier will definitely need it due to the higher expectations.
An important event that needs mentioning is the introduction of MDR in Europe. It brought about Rule 11 which places software products that used to be considered less risky into a higher classification group, and in order to use it, you will most likely need a guidance document.
There is a question most people will ask here: are the rules and classifications the same in the EU and the USA? And the answer is no.
To be fair, the principles are somewhat similar, but they differ nevertheless. For example, the US market has no sub-classes. It is important to remember that it all comes to this: the riskier the product, the more requirements there will be, and it is always best to learn about the specific market and its rules.
Software safety classification
Software safety classification serves to determine the rigour of the requirements in the IEC 62304 standard and is based on the potential injury a software failure can cause – the severity of harm. The standard, however, is applicable worldwide – it is not linked to a particular market.
This classification uses letters A, B, and C, where C is used for the products of the highest risk, when there is a risk of death or serious injury.
To connect this classification to the previous – there is a correlation, but not always.
Sometimes there can be a product that is considered low device class but with a high software safety classification. Regardless of that, the manufacturer has to perform both classifications.
Level of concern
The level of concern comes from the FDA, and, in its essence, it is similar to software safety classification, based on how harmful the software can be. The difference is in the viewpoints. Therefore, the level of concern is about the documentation expected in the premarket submission. And once again, the volume of the documentation and your expected development rigour is directly proportional to the height of the risk.
When working for the US market, a level of concern for the software must be established. This is usually and most conveniently done through reviewing similar products in the FDA clearance database.
The terminology used for the level of concern is MINOR, MODERATE, and MAJOR.
Like before, there is a chance for the level of concern and software safety classification to be aligned. However, one needs to be careful at all times because the viewpoints are different, so the outcomes can be as well.
SaMD, or Software for Medical Devices, was introduced by the IMDRF (International medical device regulators forum), and it is applied to standalone software products. SaMD uses a two-dimensional approach, and, in the classification assessment, it focuses on the situations and significance. It also helps us understand the importance of criticality.Therefore, the outcome of the categorization will depend on the significance of the intended use – for what will product will be used. E.g., it will surely be higher if it is to be used in urgent, time-critical situations.
It is important to say that SaMD uses roman numerals as well, which is important to know in order not to confuse with other classifications that use them too.
In conclusion, when working with medical device software, it is important to distinguish different classification rules. And the best way to be able to do it is to learn about them.
Would you like to learn more about Medical Software Development?
Get instant access to our online Software for Medical Devices and IEC 62304 course right here. In 15-25 hours, you can learn how to be effective in medical device software development according to the IEC 62304 standard. The course is suitable for anyone working with software development, such as R&D engineers, quality assurance department and auditors of software development. The course does not cover actual coding.
Christian Kaestner is a consultant and entrepreneur with a wealth of knowledge about the medical device industry. He is an expert member of the project team authoring IEC 62304 and also actively participated in the creation of IEC 82304-1.
He has extensive experience of medical device development and, as a software developer, a strong dedication to software development. In the software domain he has worked in many roles such as software developer, project manager, auditing and quality management.