Human Factors & Usability: An Interview with Expert Shannon Hoste


The FDA perspective on human factors and usability in health care was first published on July 18, 2000, with the issuance of US FDA draft document, “Medical Device Use-Safety: Incorporating Human Factors Engineering into Risk Management.” That non-binding guidance kicked off industry discussion for more than a decade. On June 21, 2011, the US FDA issued new information in an updated guidance draft.  

Most recently, in February 2016, updated final guidance was published, “Applying Human Factors and Usability Engineering to Medical Devices.” Right around this same time, the international standard, Medical devices — Part 1: Application of usability engineering to medical devices, IEC 62366-1:2015 released in December 2015, with the current version being IEC 62366-1:2015/AMD 1:2020.   

As part of this significant, exciting, and ongoing industry opportunity (and responsibility), we were delighted to sit down with Shannon Hoste, President of Agilis Consulting Group, to talk about her work in human factors and usability. 

Human Factors

Shannon was leading the CDRH Human Factors team at the time of the guidance release and is also on the AAMI HE – Human Factors Engineering Committee providing input to IEC/SC 62A/JWG 4 – Medical devices - General requirements for safety and essential performance – Usability, through the U.S. TAG to IEC/SC 62A.  

OHP: Hi, Shannon, thank you for joining us today. We have really been looking forward to this. Why don’t you tell us a little bit about your background and how you became one of the early proponents of human factors and usability in health care. 

SH: Thank you for inviting me. Happy to be here. I am a systems engineer, by training and disposition, with a background in human factors. I didn’t start there, however, my undergrad degree is in mechanical engineering. When I first started working, I was hired into a medical device group. As I got under way in my new job (and my new industry), I ran into field failures on an injection pen project I was working on, and we couldn’t figure out why the device was experiencing failure. After months of testing and detective work, we determined that there was butter and motor oil on the device. The oils then embrittled the plastics. It was a great example of how human factors issues manifest. People using the injection pen didn’t like how “tight” the device was, so they lubricated it. This made me think, how do you write suitable requirements when people can literally do anything to a device? As a result of this sort of revelatory moment, I started taking classes around human performance, capabilities, and how people make decisions in the moment. From there, I was hooked and went the systems interface route.  

Remember that “human factors” was not really on the radar at this point in the late 1990’s. I realized that this was going to have to become a part of the process—a major part—in the way people developed medical device products. From that moment,  I was keenly aware that human factors was a key to the future success of safe and effective medical products.  

As I continued work in the medical device industry, the folks in packaging and labeling became my fast allies. They immediately understood the need for human factors. What I experienced was that packaging and labeling tended to get pulled in late, leaving them with the need to become the catch-alls for user interface optimization. For example, at the time, the term “user error” was still prolific, implying a blame on the user and new labeling or packaging requirements were made to address the “silly” user.  What we could clearly see from these late efforts is that optimization of the user interface (inclusive of the product, packaging and labeling) throughout development resulted in a better design and less opportunities to induce use error.  

I soon started finding the kindred spirits and identified opportunities to grow awareness and knowledge about human factors.  And that is really how I launched this exciting journey. 

OHP: You were a real pioneer in the industry. Would you say there is more acceptance and desire to implement human factors and usability now?  

SH: Yes, through the guidance and standards, but also through the groups that have been working to build knowledge and practice. I attribute this to the Human Factors community, to folks such as Bob North, Ron Kaye, Molly Story, and Patricia (Pat) Patterson, who started my current company in 2000. I was fortunate to meet Pat and Bob early on, knowing the work that they were doing in  promoting the conversation. They talked about human performance, instructional material design, task analysis, etc. This helped me realize what I could do within this industry. Now, 20 years later in the current landscape, those talking points are better understood in how these factors contribute to use-related risk.  

‘Use-related risk’ is the foundation for medical device human factors/usability so let me start there. Even in 1998, it was standard practice to think of risk associated with design failure modes or process failure modes. However, use-related risk was a newer concept. And that idea got some big help from the FDA, specifically from Jay Crowley and Ron Kaye. They had written some of the early FDA guidance around human factors. They were not in the pre-market review offices, so one could argue at the time, it was considered by industry as interesting.  Subsequently a draft guidance was released in 2011 around Human Factors for Medical Devices and these processes were now better defined and discussed. “Have you evaluated use risk and human factors?” Having the regulators start to ask that question, around 2011, really created the push.  

Shortly after that time, I joined the FDA human factors team in the Centers for Devices and Radiological Health and moved on to lead that team.  

OHP: So it’s safe to say you were involved in human factors and use-related risk from the very start.   

SH: Pretty early, yes. It has been truly amazing to see this discipline grow and the impact to medical products and patient safety. When at the FDA, the team supported the various review divisions so it was interesting to see all the different device types and how people were looking at human factors.  

OHP: Are you saying that human factors were different for cardiovascular vs. respiratory, that kind of thing?  

SH: Well, the FDA team finalized Human Factors and Usability guidance in 2016 and the international standard was updated in Dec. 2015 (IEC standard). While using some different terminology, these both outline a process for human factors (aka usability) engineering and how it is built into product development. Having that information published helped with consistency, giving guidance for industry AND reviewers. What varies was the request on when human factors data was needed—and this was based on the review division, predicated on use-related risk. If a use error could lead to high severity harm, the human factors data helps you understand that risk. Based on this perspective, against a backdrop of post-market data, there are areas where specific questions need to be understood.  

OHP: Is the main question being asked by regulatory bodies around human factors testing, then?  

SH: In my experience, historically (and it has been changing over the past 10 years), if companies were not already integrating human factors into their development process, then a regulatory agency data request is difficult to answer. When data is requested that requires a Human Factors study, this can be a significant delay as these studies can take three to six months, if they have not been planned for. So in such cases, it is reactionary. However, with more awareness of the process, to include human factors early and throughout the development process (on the full user interface: product, packaging and labeling), then companies start to see the efficiencies and value of these activities. Starting early is not only expected but smart, because you build data to inform the design along the way. That is the ideal situation. It is similar in concept to software or quality–you are building quality and usability into the product, and at the end of the day, you have something that supports safe and effective use. 

Tune in next week for the conclusion of our interview. 

Comments (0)