Menu
Menu
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:
1. Why all these classifications?
2. What are the differences among them?
3. 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.
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:
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 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 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.
The documentation level 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 documentation level 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 documentation level 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 documentation level is basic and enhanced.
Like before, there is a chance for the documentation level 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.
The FDA introduced the documentation level in June 2023, so you likely bump into the legacy term “level of concern” when searching databased. The level of concern was divided into three categories: minor, moderate, and major. With the risk of oversimplifying things, a minor level of concern is similar to the basic documentation level, while moderate and major have been merged into enhanced documentation level.
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 categorisation 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.
With our medical device software course selection, you can choose between Software for Medical devices and IEC 62304 and SaMD, IEC 62304 and IEC 82304-1 depending on your interest and need.
The courses are suitable for anyone working with software development, such as R&D engineers, quality assurance department and auditors of software development. The courses do not cover actual coding.
Or if you’re looking for a tailored training to align with your company’s specific needs – contact us for inhouse training options.
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 IEC62304 and also actively participated in the creation of IEC82304-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.
Receive FREE templates and quarterly updates on upcoming courses that can help you in your career! Subscribe to our newsletter now.
When you submit this form, you will be sending personal information to medicaldevicehq.com. To comply with GDPR requirements, we need your consent to store and use the personal data you submit. Take a look at our Privacy policy for more details.
Important! Please be advised that there will be scheduled downtime across our platforms from 13:00 CET Apr 26th to no later than 16.00 CET Apr 28th. During this period you will not be able to access the website or your account. For more information, please contact us at support@medicaldevicehq.com
