FDA level of concern vs IEC 62304 safety classification - 510(k) exempt device

[TomQA]

Hello,

I have a question concerning the safety classification of our software.
According to the guidance , our SaMD has a level of concern "MODERATE" whereas according to the IEC 62304, the device is a class A.
The guidance with the level of concern is intended for "Premarket Submissions" (510K, PMA, etc..). However our medical device is 510(k) exempt and therefore my question is, and this might sound a bit naive, can we only use the IEC 62304 safety classification rules since it is a recognized standard by the FDA ?

Plus, is it possible to segregate the software components, like the IEC 62304, and assign a level of concern (possibly lower than the level of the device) depending on their specific contribution to hazards ?

Thank you !

 

[Tidge]

The purpose of the FDA guidance is to detail the minimal amount of documentation necessary to support a submission; the purpose of 62304 is to document the (per consensus) minimal development activities necessary to demonstrate that the software system is safe (per the pre-determined level of risk for the software system). These are different things.

There is general alignment between Level of Concern and Software System Safety Classification, but it is not exact.

 

[mihzago]

The new FDA guidance changes the classification a bit, but it's still a draft for now. Either way there is no option in the guidance to separate modules or components. You also have to perform the assessment before any control measures in place.

You could maybe follow the IEC62304 instead of the FDA guidance, but even though your device is exempt, there may be a situation where you have to make a submission (read about exclusion to the exemption).

 

[yodon]

As @Tidge notes, the alignment between the guidance and 62304 isn't perfect. One area where I have seen this is in unit verification / acceptance. 62304 pretty much allows you to define what that is. It's been my experience recently (last few years) that FDA, for whatever reason, has been focusing on static analysis (moderate & major).

Plus, is it possible to segregate the software components, like the IEC 62304, and assign a level of concern (possibly lower than the level of the device) depending on their specific contribution to hazards ?

Short answer is yes... but it's been my experience that reviewers have a really difficult time with this.

 

[Tidge]

It's been my experience recently (last few years) that FDA, for whatever reason, has been focusing on static analysis (moderate & major).

That's interesting! It ought to be relatively simple to satisfy such a request, although I would hate to see it become de rigueur for reviewers of LoC = Minor submissions to expect it. I have only limited experience with 62304 Class A software, but even for those we've (minimally) had documented code reviews... but I wouldn't expect everyone who ends up there to do so. On some Class B&C software we've used some static analysis tools to identify some code defects (at varying levels of severity) but generally it isn't where I think the action is!

Anecdotally: we have experience with one auditor (not a reviewer of submissions, AFAIK) who always asks to see some "source code'... they ask in almost ANY context (product code, NPS, anything). I may be an unreliable narrator on this point, but in only one case was there a direct reason to even consider looking at the code... and it was because we'd done some static analysis on some units. All other cases were far less obvious, and in small number of cases the request to see "source code" was a self-inflicted distraction/delay from the audit schedule. One of the more generous explanations I have for that behavior is that maybe it helps the auditor stay interested in the job?

 

[TomQA]

Hello,
First of all, thanks for all of your responses!

There is general alignment between Level of Concern and Software System Safety Classification, but it is not exact.

Yes well this is exactly the problem, it is not exact. For the 62304 we are a class A and for level of concern were are more MODERATE so this changes the amount of documentation needed.

The new FDA guidance changes the classification a bit, but it's still a draft for now. Either way there is no option in the guidance to separate modules or components. You also have to perform the assessment before any control measures in place.

Yes I saw the draft !
By the way do you know, or is it possible to know, when this guidance will be officially published ? Thanks !

 

[Tidge]

There is general alignment between Level of Concern and Software System Safety Classification, but it is not exact.

Hello,
Yes well this is exactly the problem, it is not exact. For the 62304 we are a class A and for level of concern were are more MODERATE so this changes the amount of documentation needed.

Typically, a software development effort generates more documentation than accompanies a submission, no matter the SSSC. It is a mistake IMO to think that the minimum required documentation for an FDA submission represents the maximum amount of development effort.

Here are the elements NOT required for the FDA submission (Minor) that are required for Moderate:

• Summary of Functional Requirements from SRS
• Architectural Design chart
• Software Design Specification
• Planning/Configuration Management
• Unresolved Anomalies list
• Description of testing (acceptance criteria) at Unit/Integration/System levels.

Setting aside the final bullet point: If you were thinking of trying this strategy...

Plus, is it possible to segregate the software components, like the IEC 62304, and assign a level of concern (possibly lower than the level of the device) depending on their specific contribution to hazards ?

...You must already have the first three bullets covered. The fourth bullet must be coming along as well, if you are allocating functions, although I can accept that this could be done "sloppily"... this is not meant to be derogatory, I only mean to indicate that I recognize a spectrum of diligence when it comes to configuration management.

I can't imagine trying to market a SaMD and NOT having the fourth and fifth bullets covered, no matter the LoC. To not have those would be setting yourself up for (regulatory, business) trouble when it comes to things like complaint handling, periodic risk reviews, and design changes. The fifth bullet is actually quite relevant, because a SaMD company cannot assign blame to another software developer if that developer didn't intend to market their software as (part of) a medical device. One can try, but the FDA isn't going to bring that 3rd party to court.

The final bullet point could be where the consternation lies, but IF you know how you allocated functionality (those first three bullet points again) then it should not be at all difficult to do "lower-level" (atomic, unit) testing... if you even have units. If you legitimately don't have units, and this was a Minor LoC, you still would have to do system testing to support the submission.

 

[RhondaDQA1]

Hi all - I'm closely following this chain because we're dealing with a similar conundrum. We have a physical medical device with various SiMD applications inside. Right now, everything takes the Class C classification because we do have one of the SiMD apps that has been determined to be Class C. However, we have other SiMD pieces that are not Class C, and some are either MDDS or not considered to be medical device software.

The problem we're running into is segregating the software classifications (which is encouraged in IEC 62304) and the notion that Level of Concern cannot be segregated. Since we roll all of the software up to Major LOC, unit tests are required for all software, whereas for IEC 62304 unit tests are only required for Class B and Class C. This is problematic when we look at the amount of extra testing, effort, paperwork, etc. that is needed if all software is Major LOC.
If segregation in software was not acceptable by the FDA, why is IEC 62304 harmonized and considered the gold standard for medical device software?
Any thoughts or feedback?
Thank you all in advance.

 

[Tidge]

Perhaps I would understand the question better if instead of approaching it from "this seems like a LOT of extra work" it was better phrased as "here is what we are considering doing (for each item)."

 

[RhondaDQA1]

Good morning Tidge - as I mentioned, the required extra testing, effort, paperwork, etc. would be required for Major LOC and Class C software - such as unit tests. If we're able to downclass some of the other software pieces to Class A, MDDS, etc. then we would not need to go through that extra work.
Thank you again.