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

Tidge

Trusted Information Resource
I still get the sense that this approach is looking to eliminate work, as opposed to doing work.

My post on 17 June 2022 (above) should outline what could be done with a Major LoC, even if a 62304-compliant analysis leads a company to believe that elements of the software system are SSSC Class A. The 510(k) document requirements is for submission purposes, it is absolutely NOT the "bare minimum" necessary to demonstrate that a medical device is safe and effective. I grok that the guidance doc for submissions feels like it ought to be the bare minimum for acceptability, but I can assure you that this is the wrong approach to software system development (including scheduling).

It has been my experience that it takes more work and effort to try to get out of work than it does to do the work. (There may be some analogy to the P vs. NP problem, YMMV). I am not saying that for a well-structured software system, with a clear segregation of functions and resources, that there could be a completely risk-appropriate rationale for extremely low-coverage testing of specific software system elements... but there is going to have to be an extreme level of supporting documentation to convince a 510(k) reviewer that this is the case.

Don't lose sight of this fact: the software developer has complete freedom to define software units. If a development team has a complete allergy to doing low-level (i.e. "unit") testing for (self-assessed) low-risk elements... in my vernacular: "the developer doesn't really care how those pieces work"... then at least the developer is obligated to demonstrate that it works along with, meets the needs of, does not interfere with, the other higher-risk software system elements. Would this be a unit test, and integration test, or a system test? Hopefully whatever kind of test it is called is appropriate, as this is a medical device system that will be used for patients.
 

RhondaDQA1

Registered
First off, no one is trying to get out of work. We want to be lean and use the system to allow us to produce what is needed. Our developers are quality minded but we don't want them to waste time if it's not necessary. Why would I want to spend extra time with all of the requirements around unit testing on something like a login screen? I'd rather spend my time and the developer's time on the higher risk items. We want to be pragmatic with our testing and make sure the high risk items are tested proportionally higher than Class A or MDDS items.
 

Tidge

Trusted Information Resource
We want to be pragmatic with our testing and make sure the high risk items are tested proportionally higher than Class A or MDDS items.

I propose that if:
  1. A development and test plan for the high-risk elements is created; and
  2. There exists clear understanding of what make those elements "high-risk" and how they are different from "low-risk" elements
It should be possible to develop a satisfactory (to the budget conscious) and possibly defendable approach to why less testing is required for "low risk" elements. Plan to do work and scale back as appropriate rather than plan to do as little work as possible.
 

TomQA

Involved In Discussions
Hi @RhondaDQA1 ,

have you had any news from your side recently concerning the segregation of classes (A, B C ) taking into account the level of concern ? How did you carry this out?
Thanks !
 
Top Bottom