MD+DI Online is part of the Informa Markets Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

FDA Fails to Cite Its Own Human Factors Guidance

Article-FDA Fails to Cite Its Own Human Factors Guidance

FDA Fails to Cite Its Own Human Factors Guidance
Why doesn't FDA mention its own human factors guidance in another recent technology-specific guidance document? 

Why doesn't FDA mention its own human factors guidance in another recent technology-specific guidance document?

William A. Hyman

On April 20, 2016, FDA issued a Guidance Document entitled "Technical Performance Assessment of Digital Pathology Whole Slide Imaging Devices." This technology specific guidance provides a set of detailed "recommendations" for what kind of technical data should be submitted for regulatory evaluation of such a system. These are only recommendations because guidance documents in theory do not establish requirements.

In addition to an extensive set of hardware and software technical considerations, the guidance also addresses human factors under a section on User Interactions. Here it is recommended that there be an analysis which identifies the use-related hazards of the system including consideration of use errors involving failure to acquire, perceive, read, interpret, and act on information from the system "correctly or at all" and the harm that could be caused by such errors. Thus the technical capability to accomplish these tasks is properly distinguished from the facilitation by design of the ability to do these tasks correctly and consistently. This difference between capability (you could have done it right) and likely performance (you will actually do it right) is the essence of human factors design and evaluation. Note also the terminology "use error," as opposed to "user error," a distinction that first appeared in MD+DI.

Get inspired to innovate in medtech at the MD&M East Conference, June 14-16, in New York City.

The User Interactions section provides several references to human factors guides, but it does not include the FDA's own February 2016 Guidance Document on "Applying Human Factors and Usability Engineering to Medical Devices."  It is possible that the FDA not including its own Human Factors guidance in this part of the Technical Performance guidance was a result of overlapping time lines in the development of the two documents, although the draft Human Factors guidance has been available since 2011. It is also possible that the people responsible for the Technical Performance guidance simply didn't know about the Human Factors guidance, or maybe they knew about it and rejected it. While there is certainly some overlap between the two approaches to human factors testing  they are not identical, as shown in part by the Human Factors guidance being 45 pages while the corresponding section in the Technical Performance guidance is about four pages. It is therefore possible that following one would leave you out of sync with the other.

The Technical Performance guidance does reference the1993 FDA guidance on "Human Factors Principles for Medical Device Labeling." Curiously this reference is not included in the recent Human Factors guidance.

Beyond the lack of reference to the FDA's own guidance, the Technical Performance document recommends a particular concluding sentences: "The [device] has been found to be reasonably safe and effective for the intended users, uses and use environments"; that  "The methods and results described in the preceding sections support this conclusion"; and that "Any residual risk that remains after the validation testing would not be further reduced by modifications of design of the user interface (including any accessories and the Instructions for Use (IFU)), is not needed, and is outweighed by the benefits that may be derived from the device's use."

Such prescribed language can easily lead to rote assertions. More particularly, a finding that a device is reasonably safe and effective is at the core of any marketing submission to the FDA. Would you submit a 510(k) or PMA if your conclusion was otherwise? Also is it not self evident that the submitter would assert that their methods and results support the conclusion?

The final recommended sentence is perhaps even more problematic. First, residual risk is by definition that which remains at the end of the design cycle so that "residual risk that remains" is at best redundant. Second, "would not be further reduced by modifications" implies that all risk must be brought to a point where it cannot be reduced any more. This is contrary to the typical risk management exercise in which the need to further reduce a risk can be subject to analysis and decision making with consideration of the magnitude of the risk and what it would take to fix it. We might also debate whether the Instructions for Use can reduce a residual risk, especially if residual risk is more properly defined as that which remains after including consideration of the IFU.

The "is not needed" phrase is confusing to me in its construction but it might mean that you don't have to reduce a risk further if you conclude it isn't necessary to do. This is common practice but it seems to be contrary to the first phrase. Finally, "outweighed by benefits" also suggests that residual risks are acceptable whether or not they could somehow be further reduced. Should the three components of this sentence have been connected by "ors" rather than "ands"?

An FDA human factors specialist once told me that their position within the agency was screaming in the dark. Perhaps there was so much screaming others stopped listening.

William A. Hyman is a professor emeritus in the department of biomedical engineering at Texas A&M University and adjunct professor of biomedical engineering at the Cooper Union. Reach him at [email protected].


Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.