IVD Device Software - Risk Classification

Tidge said:

I can see the general point being made, yet "Inherent By Design" is a recognized category of risk control.

Click to expand...

And we're back at square 1; when considering any design feature that could cause a hazard if not specified correctly, the specification selected is ALWAYS a risk mitigation, as inherent safety by design.

Thus when considering the imaginary heater; the selection of a 200W heater that cannot result in a hazardous output of heat must be considered as a risk control measure, and for the purpose of FDA LOC for software where you must consider the effect of software failure pre-mitigation, should I be considering the possibility that the manufacturer has specified a nuclear reactor to generate the necessary heat and give us a Major LOC?
Or perhaps a 1Kw element and it's Moderate?

Where do you draw the line?

If it's not SAMD, I would just apply the LoC for the "software system" (which historically has just been "all software in the device") per the medical device. It is completely possible to do the later segregation to satisfy the LoC-based required deliverables and the 62034 SSSC-based deliverables. The subtle point is this: For a MAJOR LoC that only has (appropriately classified) SSSC Class A elements, the deliverables required for the LoC submission will be required, but they won't (necessarily) directly be an output of the 62304-compliant process. LoC is literally just establishing the materials that the FDA expects to see in a submission; it has nothing to do with the materials that need to be generated to make safe and effective medical devices.

The MAJOR LoC medical device had better have it's own risk assessment and design architecture that makes it clear how those MAJOR risks are allocated among system elements. As long as these docs for the medical device make this allocation and analysis very clear (YMMV), the FDA reviewers are unlikely to pitch a fit if the 62304-compliant software deliverables all align with Class A effort. The FDA reviewers will almost certainly have an initial set of questions about this, so my recommendation is to have a very clean set of links between the medical device's Hazard Analysis and a Software Hazard Analysis. The FDA reviewers aren't going to play a game of "gotcha", and I have never seen a software-inclusive submission NOT have questions (in my experience, all have been very basic items that already had been included in the submission *1) but even the greenest reviewer will have more seasoned colleagues that will have more familiarity with software submissions and are available to help parse responses to questions.

(*1) I don't want to leave the impression that any of the FDA reviewers I've interacted with have been anything but professional. Individually, they don't have infinite time to grok all the details of every submission, so it is common that they have an initial question and sometimes don't circle back around to find answers to those questions (that are already included in the submission). It doesn't help them that every company does submissions differently. When I've had live interactions with "green" reviewers, they have commonly had a more seasoned hand listening in... I assume that there always has been some sort of after-action debrief/teaching moment after the calls between the agency members. I have never felt like I've been in a "fight" with a reviewer of a submission (over software)... I've had a different interaction with agency auditors, but that is a completely different circumstance.

So having had another look at the FDA's current and draft guidance documents, here is how I would interpret it.

In your example, the designers could theoretically have designed the system with a 2000W heating element. Very true. But the system didn't really need the element to get that hot or heat that quickly, and a 200W element would work just fine. The use of a 200W element also completely eliminates the risk of severe burns in the event of some runaway heating condition, so the 200W element is identified as a risk mitigation / risk control for "severe burns". So far, so good.

Now, lets say there is a software-driven temperature control system which ensures the 200W heating element never gets above 30 C, even though it could get a bit hotter (not "severe burn" hot, but "uncomfortable to touch for too long" hot). If this control system fails the worst case injury is "mild burn/discomfort." So this temp control system is identified as a risk control / risk mitigation for "mild burns."

You could mitigate the risk of the temp control system failing by having some kind of separate (non-software driven) warning light that comes on if the temp gets above a certain amount. Hopefully this light will never come on, because of the temperature control system. But it's put in place just in case that control system DOES fail. This warning light would also be identified as a risk mitigation for "mild burns."

Now... FDA says "We recommend that you determine the Level of Concern before any mitigation of relevant hazards."

Because the system WILL NEVER USE a 2000W element, I would not consider "severe burn" to be a relevant hazard/harm, from the perspective of the temperature control system failing.

A 200W element WIIL BE used, and knowing that, the worst case outcome, from that software perspective, is "mild burn/discomfort." If the temp control, my warning light, and all other risk controls all fail together, the worst case harm is still limited to "mild burn." The fact is, the 200W element isn't going to magically turn into a more dangerous hazard. So I would say the LOC of this temp control system if Moderate, since its failure could result in a minor injury.

To Tidge's point, it's about being able to clearly identify what the risks (theoretical and actual) are, and how they are mitigated amongst system elements. In this case, the theoretical risk of severe burn is mitigated by heating element selection. Once the heating element is specified, that theoretical risk no longer exists. There remains a real risk of minor burn, which is mitigated by the temp control system.

Hopefully I'm not off in left field with this line of reasoning.

Tidge said:

I would just apply the LoC for the "software system" (which historically has just been "all software in the device") per the medical device.

Click to expand...

I'm going to ask a question that makes it sound like I have no idea what I'm doing here; how would I go about that at the system level with regards to "all software in the device" without breaking down what each part of the software is intended to do?

Using the imaging system the whole purpose of the software is to control the digitisation process and prepare accurate accurate high resolution images of the pathology slides, including the stitching of individual frames, and generating a patient record in a database with the images based on the attached barcode image.

Using the heater example, it could be for a baby incubator, or a heated blanket, or something more intricate that has other functions too - where the whole intention of the software for the first two would be to monitor the temperature and turn on/off a heating element (which could be done completely with hardware and no software at all, but that's besides the point for this discussion)

I've typically only gotten involved at the point where software has been broken down into subsystems, items and units.
If you have any recommendations for resources (other than 62304 itself) that could help me, I'm all ears (or, I guess eyes, being that this is a message board).
I've been contemplating finding a training course, but more often than not I find that the 1 day training courses you pay a thousand dollars for just read you through the standard and don't actually help with the practicalities of actually using it.

Hi_Its_Matt said:

To Tidge's point, it's about being able to clearly identify what the risks (theoretical and actual) are, and how they are mitigated amongst system elements. In this case, the theoretical risk of severe burn is mitigated by heating element selection. Once the heating element is specified, that theoretical risk no longer exists. There remains a real risk of minor burn, which is mitigated by the temp control system.

Click to expand...

But that theoretical risk is only controlled because you identified it, analysed it, evaluated it, and controlled it.

ThatSinc said:

I'm going to ask a question that makes it sound like I have no idea what I'm doing here; how would I go about that at the system level with regards to "all software in the device" without breaking down what each part of the software is intended to do?

Click to expand...

I apologize if this comes across as lacking an appreciation for nuance, and recognizing the potential confusion for bringing terms with an accepted, consensus definition into this (older terminology) FDA question.... based on the essential performance(*1) of the device (see 60601-1 definition) it should be immediately obvious if the system level risk of the device (in its entirety) is minor, moderate or major.

In the case of the incubator or heating pad... in the absence of consideration of unacceptable risks, it is possible that a manufacturer would land on moderate... but in light of unacceptable risks my personal assessment would be that it would always be major. If all the software is doing is handling the "moderate" stuff, then treat those software elements as moderate. If the software is implicated in, or otherwise relied upon to address, the "major stuff", then treat those elements as major.

You can also take a page from 62304: "If you honestly can't (or don't want to) figure it out, treat it as the most serious." There is a small possibility that you will face some embarrassing question from the FDA reviewer along the lines of "why did you submit all this material?" and a slightly more probable likelihood of confusing/delaying a reviewer, but you will be engaging with the reviewer anyway so why risk not having done the work if you don't know how much work to do to support the submission?

(*1) Also don't overthink essential performance. I wouldn't even refer to "essential performance" in the determination of Level of Concern, rather my advice is to make sure that the stories told to different authorities (regulators, NBs, NRTLs, customers) all support each other.

Tidge said:

If all the software is doing is handling the "moderate" stuff, then treat those software elements as moderate. If the software is implicated in, or otherwise relied upon to address, the "major stuff", then treat those elements as major.

Click to expand...

Agree 100%.
To continue with examples, if you had some device and all the similar/competitor products used radioactive material for some reason, it would reasonable to assume that your device also had a risk of harm associated with radioactive material. But if your company found a way to accomplish the same goals/performance without radioactive material, then for your device there would be no such risk. If there were software controlling your device, you wouldn't say that the software played a role in preventing radioactive material-related harms. Those risks were completely eliminated by using non-radioactive material.
So in the heater example, the risk of severe burns was completely eliminated by the choice of using a low wattage heating element. The software doesn't play any role in preventing severe burns. With the lower wattage element in use, the software does play a role in preventing minor burns or discomfort, and so the LOC of that software function/unit/item should be determined based on that role.

This is where I like the new language in the 2021 draft guidance (page 8, lines 254 to 261) where it talks about distinguishing between "probable" and "purely theoretical" risks. In the 2019 guidance document Factors to Consider When Making Benefit-Risk Determinations in Medical Device Premarket Approval and De Novo Classifications, the FDA says "In general, a ‘probable risk’ and a ‘probable benefit’ do not include theoretical risks and benefits, and instead are ones whose existence and characteristics are supported by valid scientific evidence."

In other words, "Be reasonable. Use some common sense. Don't claim greater risk or greater benefit than what is really supported by evidence."

ThatSinc said:

Tidge said: "I would just apply the LoC for the "software system" (which historically has just been "all software in the device") per the medical device."
...how would I go about that at the system level with regards to "all software in the device" without breaking down what each part of the software is intended to do?

Click to expand...

I'm pretty sure what Tidge is saying is that first you determine the LOC of "the software system" (aka "all the software in the device") based on the overall risk of the medical device. And that for simplicity purposes, you could just say that all lower level SW units/items have the same LOC as the overall system. So if the device uses a nuclear reactor as its heat source, then the LOC of the "the software system" and all lower level items gets determined assuming that heat source. But if the heat source is a low wattage heating element, then you assign an LOC based on the risks associated with that heat source.

ThatSinc said:

more often than not I find that the 1 day training courses you pay a thousand dollars for just read you through the standard and don't actually help with the practicalities of actually using it.

Click to expand...

I see you and I have attended some of the same training sessions.

ThatSinc said:

I'm going to ask a question that makes it sound like I have no idea what I'm doing here

Click to expand...

I've seen enough of your questions and comments to know this isn't the case. But boy, have I wondered the same thing about myself sometimes. I often have to remind myself of the old adage "keep it simple, stupid."

Hi_Its_Matt said:

I'm pretty sure what Tidge is saying is that first you determine the LOC of "the software system" (aka "all the software in the device") based on the overall risk of the medical device. And that for simplicity purposes, you could just say that all lower level SW units/items have the same LOC as the overall system. So if the device uses a nuclear reactor as its heat source, then the LOC of the "the software system" and all lower level items gets determined assuming that heat source. But if the heat source is a low wattage heating element, then you assign an LOC based on the risks associated with that heat source.

Click to expand...

I think it's more along the lines of the device intended use rather than any specific design feature, though I could be wrong.


E.g.

This device is intended to keep premature babies at a constant temperature
Does the device have software that in some way controls functions related to the intended use? Yes.

If the device fails, could serious injury or death occur? Yes, clearly .

without any further thinking, software LOC = Major.



or in the case of the imaging system


The device is intended to provide a digital image, representative of the prepared slide, for the purposes of supporting the process of diagnosing cancer
Does the device have software that in some way controls functions related to the intended use? Yes.

If the device fails, could death or serious injury occur?

this is where, as an IVD, the answer becomes more of a "it depends" because it is very indirect and there are lots of factors that come into play regarding the clinical decision making process.
But saying "it depends" means that sometimes, perhaps less than 1 in a million, the answer is yes. which would give a Major LOC.

Is that the intention?