In this video, we address device classifications, software safety classifications, and level of concern, as it relates to medical device development. We discuss each framework and how each is classified and what each classification means and determines in the product development process, and more specifically, what is required for a 510(k) or PMA submission.

 

Simplify your documentation and development process
We are excited to share our tips to help clarify the regulatory pathway that most firmware and software systems/devices take when gearing up for a 510(k)/DeNovo submission. We’ve been investing a lot of resources in this area and receive many questions regarding device classification, software safety class, level of concern, etc., so, if we can share helpful tips to simplify your development and documentation efforts, let’s schedule some time to chat.

Schedule Free Regulatory Consult

Transcript
Rightley
If you’re creating a medical device, or involved in the industry, you’ve probably heard others reference classifications such as device classifications, software safety classification, level of concern. And it may sound confusing and often times ambiguous and sometimes these terms get used interchangeably, so if you’ve ever wondered why any of this is needed and where it all came from, Dave and I are here to talk to you a little bit, very briefly, about that today. So Dave, how did these classifications all come about?
Dave
It all starts with the FDA when they created 21 CFR 820 which specifies quality system regulations and CGMP, which has 15 or so subparts including sections for quality systems management and design controls.
Rightley –
So Dave, is 21 CFR 820 where the device classifications actually come from?
Dave – 
No, they don’t come from CFR 820, they come from the FDA. The FDA decides what types of devices fall into which classes and that’s largely, What do they do? What’s the risk? That’s how they determine it. The classification determines what level of controls you need to have while developing your device. So Class I needs general controls, Class II needs special controls, and Class III needs pre-market submission.Rightley –
So what does it mean when something’s exempt? I’ve heard this term and people have heard this term probably, so what is it when a device is Class I exempt or Class II exempt? What is it exempt from?

Dave –
Sure, so only Class I and Class II devices can be exempt. And all they’re exempt from is a submission.

Rightley –
So that means that like the 510(k) for the Class II?

Dave –
Right.

Rightley –
Can things be exempt also from other parts of the process?

Dave – 
No, you really need to have design controls.

Rightley – 
Isn’t there also a special carve out for Class I?

Dave – 
Yes, Class I can actually be exempt from CGMP if you’re a certain kind of device, but in our world, software, you’re really not. Because anything that’s automated by software cannot be exempt from CGMP and requires design controls.

Rightley –
Does 21 CFR 820 tell you exactly how to make a medical device?

Dave – 
No, it does not. There are standards in place that tell you the kinds of things you need to do as far as documentation goes and documenting your design. There’s a very high level one called 60601-1 which is a general standard for medical electronic equipment. This includes an overall standard and then also particular standards for different types of devices for instance if there’s a laser or radiation, or something like that, in the device. So that is the device as a whole. When you get down a device that has software in it, the software should be following a standard called 62304 which discusses the software development life cycle. As part of that, there is risk management 62304 points to 14971 to fulfill, that’s a lot of numbers, that is a lot of numbers. That’s why this stuff’s confusing. 14971 prescribes how you should be performing your risk management and the kinds of records that come out of your risk management process.

Rightley – 
There’s 60601 at the top level and that describes the entire medical electrical equipment that you’re creating. And then 62304 specifically for the software and then there’s this 14971 that’s kind of on the side and that’s risk management and it kind of flows throughout the rest of the whole process. How do we know that these are the standards that the FDA actually says are appropriate for medical devices?

Dave – 
The FDA just points to 62304 and 60601-1 as consensus standards and you can look those up on the FDA website. 14971 is actually directly point referenced in 62304.

Rightley – 
I often hear these other terms like level of concern and minor, moderate, and major. And also there are safety classes and A, B, and C. How do these things all work together and where do they come from?

Dave – 
Level of concern is minor, moderate, and major. That’s just for any device. That’s the for the whole device. Yes. And that is determined based on your risk. Your level of risk for using the device for people, or environment, or property, whatever. You determine your level of concern prior to applying any risk control measures that you come up with. So if your level of concern is major, you’re major no matter what you do to control that risk. That’s minor, moderate and major. And based on your level of concern, that determines the content of your submission.

Rightley –
What I actually have to submit to the FDA [Dave – Yes] when I submit to get pre-market notification or pre-market authorization.

Dave – 
Now you mentioned Class A…

Rightley –
Yes what’s this software class or A, B, and C?

Dave – 
A lot of people confuse A, B, and C, with I, II, and III, and they’re different. So 62304 has software safety classifications A, B, and C. And those classifications come from the level of risk that the software puts into the device. So if your software could cause, expose someone to a hazardous situation that can cause serious or fatal injury, you’re a Class C.

Rightley –
Got it, so that’s the most serious.

Dave –
Right. Non-serious injury, Class B, no risk of injury, Class A. The thing that’s different with software safety classifications and level of concern, well one of the things that’s different, is that your software safety classification can be reduced through risk mitigation.

Rightley –
So I can have a moderate level of concern device with a Class A set of software in it. It could be Class B, it could be Class A, but it’s after the mitigation.

Dave –
Right.

Rightley – 
So how does that relate to A, B, and C, how does that relate to what software documentation you need to put together?

Dave –
It’s pretty clear in 62304 which pieces of documentation are required for Class A, Class B, and Class C. And basically, if you’re doing Class C, you’re doing everything. If you’re doing Class B, you’re doing most of it, and if you’re doing Class A there’s a few things you can leave out. And Class B I think the architectural design and the detailed software design you can leave out.

Rightley –
So Dave, give me an example of something that is required in, perhaps, a software safety class C, but maybe not in B, or A.

Dave – 
So software design is one of those things. In Class C you have to break your software down into units and do very detailed designs. Class B you just kind of have to list them out and give them a summary. Class A, you really don’t have to do a design.

Rightley –
Dave, thank you for helping us shed some light on the differences and similarities between the level of concern, device classification, and software safety classes.

Dave – 
You’re welcome.

Rightley –
All of these standards are available on the internet. In fact, all of the FDA standards are free and freely available on FDA.gov. The other standards are available; however, at at price, from the standardization bodies of ISO and IEC. If you require any additional information it’s all out there or give us a ring and we’d be happy to help.

 

PARTNER WITH PSI

Our engineers have the capability to develop software and firmware that meets all FDA requirements. Tell us about your next project!

Take a look at the many projects we have completed that fit today’s, and tomorrow’s, requirements!

 

Resources:

 


No Comment

You can post first response comment.

Leave A Comment

Please enter your name. Please enter an valid email address. Please enter message.