When does the FDA deem something "where appropriate"? 21CFR820.30(g)

[QA-Man]

In 21CFR820.30(g) is says, "Design validation shall include software validation and risk analysis, where appropriate".

In regards to risk analysis, are there any documents (with the exception of the Design Control guidance document) which discuss the agency's current thinking on when this is appropriate?

 

[QAengineer13]

Hi QA-Man,

With the exception of FDA Design Control guidance , another guidance document which deals about the Risk and Software validation is General Principles of Software Validation; Final Guidance for Industry and Staff, Document issued on Jan 11, 2002.
.

 

[Marc]

... where appropriate"...

In general, with most standards, when I see "...where appropriate..." it is a situation where the company comes up with a reason why they do, or do not do, something. In many situations (high risk situations, for example) reasons, especially when NOT doing something, are documented as to why in one way or another. I guess these days some may bring this into "Risk Based Thinking", but sometimes it's something very simple unassociated with a risk factor.

Bottom line is when the auditor comes in can you explain why you do, or do not, do something.

 

[Ronen E]

Hi,

In the past the FDA has not been very explicit with regards to risk management, and this is only slowly changing now.

I would assume that risk analysis is always appropriate, unless you have a rather obvious or overwhelming reason why it's irrelevant, N/A or the like.

More specific (or clearer) guidance might be found in the guidance/requirements specific to the device type (eg Special Controls). In some situations risk analysis / risk management might have a more defined role, and the guidance will be more detailed accordingly.

I'm sorry I can't be less vague. In part it's because the situation has some inherent vagueness in it...

Cheers,
Ronen.

 

[joylc]

820.1 a 3 isn't specific to risk analysis but it basically says "where appropriate" means "appropriate" unless you can document justification otherwise.

 

[mihzago]

The Pre-amble provides some guidance (see below). It's a bit dated (some references), but still applicable. I hope it's helpful.

In my opinion, risk analysis and software validation is always appropriate (i.e. required) unless you have a good justification for not doing it, for example, your device does not contain software. ISO14971 is a recognized consensus standard, so you should follow that for risk management activities.

From Pre-amble:
83. Several comments stated that the term ‘‘hazard analysis’’ should be defined in reference to design verification. A couple of comments stated that the proposed requirement for design verification, to include software validation and hazard analysis, where applicable, was ambiguous, and may lead an FDA investigator to require software validation and hazard analysis for devices in cases where it is not needed. One comment stated that FDA should provide additional guidance regarding software validation and hazard analysis and what investigators will expect to see. Another comment only software validation and hazard analysis, FDA was missing the opportunity to introduce manufacturers to some powerful and beneficial tools for better device designs and problem avoidance.

FDA has deleted the term ‘‘hazard analysis’’ and replaced it with the term ‘‘risk analysis.’’ FDA’s involvement with the ISO TC 210 made it clear that ‘‘risk analysis’’ is the comprehensive and appropriate term. When conducting a risk analysis, manufacturers are expected to identify possible hazards associated with the design in both normal and fault conditions. The risks associated with the hazards, including those resulting from user error, should then be calculated in both normal and fault conditions. If any risk is judged unacceptable, it should be reduced to acceptable levels by the appropriate means, for example, by redesign or warnings. An important part of risk analysis is ensuring that changes made to eliminate or minimize hazards do not introduce new hazards. Tools for conducting such analyses include Failure Mode Effect Analysis and Fault Tree Analysis, among others. FDA disagrees with the comments that state the requirement is ambiguous.
Software must be validated when it is a part of the finished device. FDA believes that this control is always needed, given the unique nature of software, to assure that software will perform as intended and will not impede safe operation by the user. Risk analysis must be conducted for the majority of devices subject to design controls and is considered to be an essential requirement for medical devices under this regulation, as well as under ISO/CD 13485 and EN 46001.
FDA has replaced the phrase ‘‘where applicable’’ with ‘‘where appropriate’’ for consistency with the rest of the
regulation.
FDA believes that sufficient domestic and international guidelines are available to provide assistance to manufacturers for the validation of software and risk analysis. For example, ‘‘Reviewer Guidance for Computer Controlled Medical Devices Undergoing 510(k) Review,’’ August 1991; ‘‘A Technical Report, Software Development Activities,’’ July 1987; and ISO–9000–3 contain computer validation guidance. Further, FDA is preparing a new ‘‘CDRH Guidance for the Scientific Review of Pre-Market Medical Device Software Submissions.’’ Regarding guidance on ‘‘risk analysis,’’ manufacturers can reference the draft EN (prEN) 1441, ‘‘Medical Devices—Risk Analysis’’ standard and the work resulting from ISO TC 210 working group No. 4 to include ISO/CD 14971, ‘‘Medical Devices—Risk Management—Application of Risk Analysis to Medical Devices.’’
FDA disagrees that it is missing the opportunity to introduce manufacturers to some powerful and beneficial tools for better device designs and problem avoidance because the manufacturer must apply current methods and procedures that are appropriate for the device, to verify and validate the device design under the regulation. Therefore, FDA need not list all known methods for meeting the requirements. A tool that may be required to adequately verify and validate one design may be unnecessary to verify and validate another design.

 

[rwend07]

It seems that risk analysis has been generally directly linked to design controls and in the post above^ it makes it seem that risk analysis does not need to be formally documented for class 1 devices that are not subject to design controls. This is the way that I have always read the regs, but I haven't had the opportunity to go through an audit where a class 1 device did not have formally documented risk analysis. Enforcement seems to be going further and further away from the regulations, so this argument makes me nervous. The way I see it, a class I device has been determined low risk and therefore formal risk analysis should not be necessary. Now, I think defining important user needs that influence safety in a project plan (sterility, biocompatibility, etc) then having the validation documents to validate they have been met is important, but I don't think it should be necessary to formally document an entire FTA/FMEA.

They never fully define and mandate risk analysis in the regulations, correct? Therefore, how can they continuously come down on companies for not formally documenting their risk analysis? Isn't the FDA's reach supposed to be defined by the regs? I actually think it is very damaging to the medical device community how far the regs are stretched without producing formal documentation defining exactly what is expected. I work for a patent lawyer so I think he has rubbed off on me when thinking about how far these federal agencies stretch the CFR. He has always made the point of "well, if its not in the regulations..." but it seems like this argument doesn't hold true in medical devices. This creates gray, judgement calls in a lot of situations that can end up resulting in major business implications when an audit comes.

 

[Ronen E]

This is the way that I have always read the regs, but I haven't had the opportunity to go through an audit where a class 1 device did not have formally documented risk analysis. Enforcement seems to be going further and further away from the regulations, so this argument makes me nervous.

Do you have concerte evidence that FDA enforces formal risk analysis on devices formally exempt from Design Controls?

 

[rwend07]

Do you have concerte evidence that FDA enforces formal risk analysis on devices formally exempt from Design Controls?

No, but I also don't have any concrete proof of someone that has not formally documented risk analysis for a Class 1 devices and has been Ok'd through an audit. That is the issue, I would not personally formally document risk analysis for a Class 1 device with the way I read the regs, but I'm not sure that the FDA won't try to come down on me for doing so.

 

[Ronen E]

With all due respect, that's a slightly strange approach in my opinion.

The only place where risk analysis is mentioned in part 820 is Design Control (820.30). If a device (e.g. most class I devices) is completely exempt from that section, where would the FDA draw the authority from to write you up for not doing it? The FDA s not omnipotent and it does need to answer to the courts. Why would they waste their resources on something that is deemed low-risk (and thus essentially off their radar) in the first place?