Human Factors & Risk Management: What's Needed & Why?

Don’t give up on risk management. It’s the backbone of the product development lifecycle and human factors is one of its most important activities. It serves as a tool to guide development, allowing you to improve your products by turning risk into a value-add type of activity.

In this episode of the Global Medical Device Podcast, Jon Speer and Etienne Nichols talk to Shannon Hoste, President of Agilis Consulting Group and former lead for the FDA’s Human Factors Team.

Shannon explains her philosophy and approach on how the pieces of human factors, risk management, and product development come together. It’s all about user-related risks and making the right design decisions early on during product development.

LISTEN NOW:

Like this episode? Subscribe today on iTunes or Spotify.

Some highlights of this episode include:

• Human factors is a risk management activity that the FDA and International Organization for Standardization (ISO) requests. It’s all about use-related risk.

• Risk management helps make design decisions around safety and efficacy, and human factors provide a focused view on user- and use-related risks.

• The main contributor that companies come across are deficiencies and questions regarding the human factors process, including the use-related risk assessment.

• Probability and occurrence is challenging for most people. To understand product risk, understand risk is probability and disparity. To know what’s driving human factors, understand what could lead to high-disparity harm or kill someone.

• Based on user needs and human behavior, risk management helps companies understand users, how they interact with your product, and what can go wrong.

• Step-by-step process of risk assessment is to identify all tasks, identify what can go wrong, stay focused to build information, and then identify solutions.

• Product development engineers want their product to be safe and work. Embrace human factors to improve that as a likelihood. Do not resist it.

Links:

Shannon Hoste on LinkedIn

Agilis Consulting Group

Pathway for Patient Health

FDA - Medical Devices

FDA - Human Factors Considerations

FDA - Human Factors and Medical Devices

ISO 62366 - Medical Devices — Part 1: Application of usability engineering to medical devices

The Greenlight Guru True Quality Virtual Summit

Greenlight Guru YouTube Channel

MedTech True Quality Stories Podcast

Greenlight Guru

Memorable quotes from SHANNON HOSTE:

“Human factors at its core, at least the regulatory aspect of human factors, is a risk management activity. It’s all about use-related risk.”

“All of it is a tool to guide development.”

“I need to look at anything that could lead to high-disparity harm, regardless of if it doesn’t happen that often, if it’s going to kill someone, then I want to understand it.”

“Engineers really like to solve problems. We’re going to jump in and look for solutions, and I think that the human factors, the user needs work, as well, is all about understanding the problem and not solving it.”

TRANSCRIPTION

Announcer: Welcome to the Global Medical Device Podcast, where today's brightest minds in the medical device industry go, to get their most useful and actionable insider knowledge. Direct from some of the world's leading medical device experts in companies.

Etienne Nichols: Everyone, welcome back to the Global Medical Device Podcast. This is Etienne Nichols, your co- host of the podcast. With me today is of course Jon Speer, the founder of Greenlight Guru and Shannon Hoste, a very good friend of mine, who is the President of Agilis Consulting. She has a lot of background, both with the FDA and a lot of med device experience, combination products, and human factors risk management. So I'm really excited to be here with Shannon today. Shannon, I'm sure I left something out, but do you want to speak your experience a little bit if you like?

Shannon Hoste: Sure, sure. Thanks for having me today. I'm glad to be here. So I've worked in the med device combination product arena, primarily in product development side, for about 25 years at this point and worked at Battelle and then went out to Intel to work on digital health. Stryker, to work on product development, revamped the product development management system and then joined the FDA, and ran the human factors team there, at CRDH. And came back into industry. Helped with Illumina and the risk management process, and then enable on- body injectors and now, into consulting. So it's been an exciting journey, and got to work on all sorts of different product types, along the way. So I'm pretty excited.

Etienne Nichols: Super cool. And I'll just mention, Shannon and I actually worked together at one point. It was, in a moment in my career when we were going through some risk management and I was a little bit, overwhelmed perhaps, at the spreadsheets and Shannon was the one who inspired me to, not give up on risk management. Now that I'm at Greenlight Guru, I'm a true believer in the way Greenlight Guru approaches risk. And a lot of that is sparked by, my experience with Shannon. So I'm super excited to be talking with you today.

Jon Speer: I'm guessing at that point in your career, you were probably approaching risk from a checkbox, point of view where, this was an activity, you had to get done, you had to check the box, you had to address it. I'm guessing, I'm speculating here. You can correct me if I'm wrong, but probably wasn't a value add type of activity. It probably didn't go into it, to learn how can we improve upon our product and make it better? I've been there too. And I think that's, unfortunately, so much of the industry is still there. They're still stuck there.

Etienne Nichols: Yeah, that's a good point. It was one of those things where, we have the design, we're ready to go and we've got a roadblock. We've got to finish this risk. So it was the exciting time because I got to... It was team building, in my mind and very good learning process, but yeah.

Jon Speer: Lock yourself in a room for eight hours. We're not leaving.

Etienne Nichols: Exactly. That's right. So, and with that being said, risk management. Some people look at human factors, they're over here, risk management, that's a separate team. Then you have to product development, and they're all a little bit disjointed. What's your philosophy or approach on that Shannon? Any thoughts?

Shannon Hoste: Yeah. So human factors at its core, at least the regulatory aspect of human factors is, a risk management activity. It's all about use- related risk and then the human factors, world kind of morphs and merges into user experience and product optimization and all of that. But at the core, human factors, is that risk management activity and that's what the FDA's asking for and that's what the international standards are asking for. When I think about risk management and human factors for that matter and exactly to your point, that you were just saying, is all of it, is a tool to guide development. I kind of think of risk management as the backbone, of your product development, your product life cycle, I should say. And as you are, you need to be working on those risk files early, because they're helping you make design decisions. At the end of the day, your risk management file is a record of all your design decisions, especially with regards to safety and efficacy, right? And so, human factors just provides a focused view on the user, on the use- related risk, and then a method for that, to come back into your overall product risk.

Jon Speer: I think that... And I've talked to previous episodes, where we've talked about human factors and the overlap, or the compare and contrast, with risk and design controls. I mean, I think, that too many people get too caught up. I mean, I like the way you said it, a moment ago, at the end there's human factors, there's risk, there's product development and design controls. At least the way I look, they're kind of all the same thing, but from a slightly different lens.

Shannon Hoste: Just a way to step back and look at the product, because risk is all about doing the diligence and looking at the different perspectives, right? You have your design, you assess your design failure mode, so that you can understand what risks they might lead to and process and same thing with use. And so it's all about, making sure you're catching all the lenses, to understand what is your product risk. Right?

Jon Speer: Yeah, absolutely.

Etienne Nichols: Yeah. When I think about the standard. The standard of 62366, usability standard. It's as medical devices, as it relates to safety. So even usability, I mean, it goes back to risk even with that standard. So that makes a lot of sense.

Shannon Hoste: Yup. And actually that was a big focus and partially from the FDA driving, on the latest, not latest, but the latest major update of 62366, where it moved to the dash one and dash two. The informative and the normative sections. And that was because, that standard historically had a lot of guidance in it. It had information about, ease of use and things kind of tangential to safety and what the big push there was to move that 62366-1, to be a truly, a safety standard and focus it, on that use- related risk and then take all of that other information, which was good information and put it in the dash two, which is more of the informative, then to support execution of, human factors or usability engineering. Yep.

Etienne Nichols: Right. That's something that I'm not as familiar with the different parts. So I'm going to, look back, and see what the different things are there. I am curious. So you were at the FDA for a while. What does it look like from that side, when you're looking through those submissions? What are you looking for from a human factor? You said you were, the lead of the human factors team at the FDA, is that correct?

Shannon Hoste: Yep. Yes.

Etienne Nichols: So how does that go? What are you looking for? What are the thoughts that go through the different teams? As a company if I'm submitting something, what do I need to be thinking about?

Shannon Hoste: Yep. Absolutely. So I'll tell you, coming from industry. So I had 20 years in industry before I went out there or 18 I guess, and there were a few things I noticed, going from industry into CDRH, specifically. One was that, somebody had read all of those reports I had written over the years. Right. You put a lot of your life into writing verification, validation reports, and so forth. Somebody reads those. So, that was a little bit of validation.

Etienne Nichols: Oh man.

Shannon Hoste: I was like, all right. The second, was that as I was reviewing the human factors and the risk management reports, felt like I had a blinders on. Like a filter, that I didn't experience in writing the reports. And that meaning, being that as I'm reading this report, I'm trying to frame all of the data through the lens of how does this help me understand this support, safe and effective use. Right? When you're writing those reports, you are writing that, but you have all sorts of other noise. You have your deadlines, you have your budget constraints, you have studied concerns, all sorts of things going on, that are factors of getting that report and getting that report done. But when you're reviewing it, you're just looking for safety and advocacy data. That's it, all the rest is noise. And so the better that is laid out, the easier it was to review and get to the core issues and say, okay, here's the three things that are concerned, I'm concerned about by, from reviewing the risk data, then you could dig into the report and say, okay, here's where that was evaluated and here's why it supports, safe and effective use. How those mitigations are effective. Right? But if wasn't clear. If there was a lot of, other details or if it wasn't clearly laid out, all of the data, then it could be difficult to one find the main concerns. And so it may be a question of, I don't feel like I have enough information to, even say that everything's been addressed or here's the questions I have, but I can't see where in all of this data that's been addressed. So those are kind of the things that would lead, then to questions back in IR or a deficiency. Right? Where, there are some specific, safety concerns and they aren't being addressed, somehow in the data.

Jon Speer: I think it's interesting. I mean, I've been in industry for, or since the late nineties, I mean, in those early 10 or 15 years or so, industry and FDA, I would say the relationship was somewhat contentious. It wasn't collaborative in any way, shape or form. I mean, it was usually industry would, that company would prepare submission, throw it over the wall, to FDA, cross their fingers and what... And there was not a lot of exchange of information. Any exchange of information generally was non- verbal, it was through snail mail, correspondence even. And so I'm encouraged, like today there's a lot more collaboration. I mean, I'm such a huge fan of things like a pre- submission for example but if I get to the point where I'm... The submission timeframe and I've submitted what I thought was, applicable and appropriate and sufficient, for that 510( k) or whatever the submission. And then you're getting it at FDA and you're like, oh, wow I don't feel like they've addressed the safety and efficacy, or this or that. For me, I'm thinking I'm days away from launch and now, this might put me back in a much earlier stage or phase of development. So I think there's still opportunity and still things that we can, improve upon as far as that relationship between industry and FDA. I mean, just curious, are there things that you're aware of, and from the agency side that we could do a better job of on the industry side, so that when we get to that point, we're smoother sailing. Are there other mechanisms besides the pre- sub that we can engage the agency on?

Shannon Hoste: Yeah. Well, and I think in my experience pretty with CDRH, they strove to be very interactive, as much as they could, right? Within the paradigm of the regulatory review. The other piece though, is that's once you're in a regulatory review or pre- sub. Right? But also there's a lot of, speaking engagements, where the FDA is available and approachable to talk. You can't talk about specific issues, but you can get an idea of what concern areas are happening and such. But also, there's a lot of information on the FDA website. It's not always necessarily easy to find, but it's there, beyond just the guidance documents. Right there, there's a search tool to search up the guidance documents, but there's also a lot of other information there, even on past submissions and so forth. So digging around, even in there, can be helpful. And then for small businesses, there's, specific forums and things that are presented webcasts that are presented on the regulations and on implementation execution. Right? Of getting a product approved to be clear.

Jon Speer: Yeah. Because I can imagine from your perspective, when you would receive this information, this human factor's information for a submission and you were reviewing it like, oh man, they missed this. This isn't clear. What's going on here? You don't want to be the bearer of bad news. Right? Yeah?

Shannon Hoste: Yeah. 

Jon Speer: I do your job.

Shannon Hoste: Yeah. That was actually the part that was probably the most difficult for me personally, as an engineer. Right? You like to dive in and solve problems. Right? And so you could see things and you're just like, oh, if you could just look at it this way, and so close. So yeah, that was sometimes challenging to see, but I think another challenge on the human factor side is, that human factors team consulted out to everybody. So one of the few teams that kind of did that and touched the different divisions and now offices, across CDRH. And so, what that means is, that reviewer is looking at that HF data, and they have access to the full file. But they're reviewing Hanabi, we are from CDRH, FDA presented and was saying that I believe it was, 45 reviews a month, if I remember that number. And that's similar to what I had experienced there. And so that is, the team varies from three to five people. So three people, that's 15 reviews a month. That's a lot of content. Those can be anywhere from 50 to 1100 pages. Right? To get through.

Jon Speer: Wow.

Shannon Hoste: So having that data, concise in a report, particularly for the HF section, so not saying, hey, this is often the risk management file. This is often this file. Just having it, and telling that clear, concise story of how that use-related risk has been evaluated. It's pretty important to, getting that in efficiently.

Etienne Nichols: Yeah. That is a lot of work. So I'm curious if we could go one layer, deeper, all those different things that you saw, what are some common pitfalls that you see companies getting into, maybe as it relates to HF? Anything come to mind specifically?

Shannon Hoste: Yeah. I think the... At the core of it, and again, this shows up in the stats, that Dr. Weir presented as well, is the main contributor to deficiencies or questions on human factors is the use- related risk assessment, itself. Which makes sense, when you have an appropriate model of human factors, what do I mean by that? Let me back up a second. Human factors is a process, just like risk management. And in my mind, very similar to the software development life cycle. From the standpoint of you, are implementing it early, you are understanding what are the potential risks. You're understanding that all of the users, uses use environments. All of the things that contribute to usually at risk. You're performing the risk assessment, identifying what use errors can happen, what problems can occur and then, what hazards does that create and what are the potential harms. Right? And then you are, screening through that and saying, okay, here's all of the potential use errors that can happen and the harms that could result, from that. And based on severity, what are the things that could lead to high severity harm? I'm going to look at those in my human factors process, and I'm going to dig in and I'm going to create, simulated use tests where I'm exposing people to that piece of the interface and see if they understand. If I'm giving them enough information, or if I'm putting something in there to trip them up, if I have a big green stop button. Right? Then no one knows what it's for.

Etienne Nichols: Right.

Shannon Hoste: That kind of thing. And then your final evaluation is, just saying, okay, if I did all of my research, I know what I need to look at, and then I'm going to evaluate that. And my validation is going to look at all of those and then I'm going to go through each and everything I saw in that study, just like I would in software anomaly. I'm going to go through each and everything, I saw in that study and evaluate, why did it happen? What's the root cause? And do I need to do anything about it? Does it need to be fixed, before I can move forward? Or is it okay as is and so forth? So like the software process, it's that, what do I need to focus on? What did I see? And one by one, what do I need to do with it? Right? And so what I saw in my experience and what I see in Dr Weir's, presentation was if that URA is incomplete, then I don't know that anything after that, is sufficient. Right? So if my URA is incomplete and doesn't identify everything that could potentially be of a concern, then my validation study is never going to be fully scoped. Right? And so that can be a big concern, when that happens. The other thing is, the whole probability thing, trips people up. To understand product risk, I need to understand risk is, the probability times severity. Right?

Etienne Nichols: Yeah.

Shannon Hoste: And so at product risk level, I need to understand that, but at the, what's driving the human factors level, I need to look at anything that could lead to high severity harm, regardless of, if it doesn't happen that often, if it's going to kill someone, then I want to understand it. Right? And so, it's really a kind of a safety critical system approach, to looking at use- related risk. And then all of those activities that inform the human factors process. Right? That usually did risk and severity drives the scope of my human factors work. That same data can then inform my product level risk, in where I can start to, just like with software, where I can start to understand probability and occurrence at my product risk level, if that makes sense.

Etienne Nichols: Yeah. So the way you mentioned that if your URA's is not scoped appropriately, your validation, will never be completely comprehensive. Well, that to me says, you need to bring that right up, alongside in product development, and it, they've got to be partners from the very beginning. Yeah. That makes sense.

Shannon Hoste: Absolutely.

Jon Speer: To me, just to build on that, I mean, it's part of what I've seen over the years, is there's poor definition or poor understanding of user needs. Usually, I mean, like you, it seems like somebody knows, what problem they're trying to solve with a product, but they don't dive in and really understand what's important from the end user perspective. Whether that be the patient or the clinician or whatever the case may be. And then as we've talked a little bit already, the first time I dive into risk oftentimes is mid or very late stream in the process. Whereas if I'm doing that more at the beginning, doing some sort of preliminary hazard analysis or risk assessment of some sort, with that user in mind, more on the front end. Man, that's so much more helpful, because it informs everything that I need to do and it identifies the gotchas. It identifies, my unknowns and really gives me a roadmap, to make my product development process much smoother.

Shannon Hoste: Yep. Absolutely. And it's one of those things in life and in product development in general, where, when you see it executed well, early on, it guides development, it informs the activities. It really creates from the beginning, your priority list of where you need to focus your attention. Right? Seeing that done well and early in a project, it is so valuable and then trying to help people understand that. Right? If they haven't done that and if they haven't seen it, executed well early on, and how much that impacts the success of the project. It's exciting to see, it's an exciting tool. And just seeing people I love to, I teach as well with Pathway for Patient Health in the quality science curriculum and one of the courses is risk management and being able to teach that and help people, understand some of those concepts, so that they can start to think through that, is just exciting to me because I know it can be so effective. Yes.

Etienne Nichols: Yeah. And it makes me think of the phrase, we shape our tools and then our tools shape us. I don't mean to just get on the Greenlight Guru, talk about, but in my past... Several different companies I work for, we'll have different Excel spreadsheets, where your design controls and your risk management are two different Excel spreadsheets. You have a hard time, keeping track of this hundreds, several... We have some customers who have, thousand line risk management files. So if you take that with the Excel, versus what we have with Greenlight Guru, where you can actually connect and link those things and there's informative feedback loop. It's very helpful, from what I've seen, is one of the reasons I'm still here at Greenlight Guru is I'm such a believer in the software. And so I just, we should, we use these tools. These tools, really shape how we approach work.

Shannon Hoste: Oh, sorry. You were making me think there, when I think back and something you had mentioned earlier, Jon. So I'm Systems Engineer, is kind of how my brain works, in my training. And so by that, I mean, it was at Battelle which we had a medical device group where we did consulting, but also they do a lot of, other work that has a very much systems engineering approach. What I was running into was, I would get user needs from clients. It needs to be made of honest materials and it needs to be blue. What do I do with that? Right? What does that mean? And so digging in and understanding what does honest mean? What do they truly need? Right? And it might be that it's, inconspicuous because they need to use it in public, or it might be that, it's a life sustaining product and they want it to feel high quality. Right? And then what does that mean? And working through all of those details and understanding that, and then the other piece is, seeing field failures, where a device failed and it fractured, couldn't figure out why. Turns out, people were lubricating it with butter or motor oil. And so the plastics were fracturing because plastics and oils don't get along. And then I was a bit paralyzed at that time to be honest, how do I write requirements? How do I do risk assessments, when anybody could do anything and I just need to make it blue. Right? And honest. How do I pull that together? And that's where I started study, Cognitive Systems Engineering at Ohio State, which I could walk to from Battelle. And piece together, how to understand, the user as part of that system. So it's just taking your system, boundaries and stretching it out to include the user, and then understand all the interactions, between your product and the user. Systematically walk through, understand what can go wrong and how to account for it, based on what we know about human behavior. So that's kind of the things you were mentioning, is we do have ways of starting to understand and break those things down. It's just a matter of following that process and having the tools to do it. Just like you mentioned. So in that case, again, it was in a large organization with a large system background. So our total of choice was doors. Right? Which, worked well when we had it customized for what we did, but it was a, it's a big lift. Right?

Jon Speer: Yeah. That's a behemoth. That's a monster tool. I mean...

Shannon Hoste: Yeah. And you have to have people focused on just using it. Right? So as an engineer, you could run, do that, but you're not involved in all of the other project aspects. So once I left, Battelle and was working at other places, that wasn't really a feasible option, to bring into a different organizations. It's not really, didn't fit well. And so it was always a, do you continue to work with Excel sheets or do you find a tool, that helps you tie all of that together, because it's all interrelated and every time you pull on one string, it's if I pull on a usability fix, is it impacting my product risk in some other way or my design risk, my design failure modes and so forth. So, that's where I've been a big fan of Greenlight Guru and the content that you're putting out as well as the tool, for that purpose, because it provides a tool to bring all of that together.

Jon Speer: Yeah.

Shannon Hoste: So valuable.

Jon Speer: Thank you. I mean, I think, looking back early in my career, it always felt like a little bit like a race. First job that I had was, with a decently large medical device company and my role, was a Product Development Engineer. So I was given, the concept or the idea, sometimes a prototype, sometimes a cocktail napkin sketch, and a pretty generic explanation of the problem that this product was hoping to solve. And then I was like, I went heads down. I went to almost like an isolation mode. Right? It's like, oh, what are all the requirements? And then, I might look at some other products that were similar and that sort of thing. But rarely did I circle back with, end users or at that phase. I, and I don't think there was a lot of emphasis, definitely not then.

Shannon Hoste: It was not.

Jon Speer: Probably not so much, even now, on what are user needs. Like you said, usually it was things like, oh, it's got to be blue. I mean, there's infinite shades of blue, come on. But I should have been... The older me could have applied some of these things earlier on in my life, like why does it have to be blue? Oh, okay. Why? Using just simple techniques, like why? Why? So I, it does seem like, I think a lot of times engineers, I'm picking on engineers that I can do. So because, I am one and I think the two of you would agree with this. We sort of get single track mine, very focused, got to get the requirements done. And then I just do that.

Etienne Nichols: One thing, to add to that though, is risk management and development of user needs. It feels as an engineer in me, I like materials. I like solid things that could touch measure, quantify. Some of those feels like, you have to apply a certain amount of art. And I don't know if that's been the case or your experience Shannon or, and that's one of those things that's hard. How do you teach a creative mindset to, or a solid mindset, to become more creative and actually create those things that, can be validated? Do you have any tips or tricks, that can help your human factors team, upstream all the way through the process? Any thoughts on that?

Shannon Hoste: Yeah. Well, I think part of it's a challenge and I found that people either, love working with the human factors space or they really struggle with the whole qualitative aspect of it, where it's very frustrating to them. But I think, and exactly to the point earlier brought up, was that it's engineers we like to solve problems. Right? We're going to jump in and we're going to look for solutions. And I think the human factors, the user needs work, as well, is all about understanding the problem and not solving it. So the trick is, keeping yourself out of solution space and just trying to explore what is that problem parameters around it. So that when you do move into solutions space, you have that context. So you can start to pull those pieces together. Then you can start to see, oh, these three things come together. This is something that will address all of that, kind of thing. But I think it's really important.

Jon Speer: Just jump in as, I say, I mean, in a, maybe a weird twisted sort of way, it kind of, if an engineer were to think about it in that context, it would satiate, what makes them tick. Find more problems to solve. Right.

Shannon Hoste: Yeah.

Etienne Nichols: Love that.

Shannon Hoste: Better understand the problem. Come up with a... Exactly that, then that's why I, what I find so exciting about it too.

Etienne Nichols: I think I mentioned this on another podcast, but it made me think of the phrase, the heart of the problem, is the seed of the solution. I always go back to that.

Shannon Hoste: Yep.

Etienne Nichols: And that's exactly right. That's cool. Yeah.

Shannon Hoste: So in similar, when you're actually getting in and diving in, working through the details. Right? Working in the spreadsheets. And I say useful of risk assessment, that's more of an FDA coin term. It's very similar to use FMEA, so it's just taking and identifying use errors and then, what could result from that use error and so forth. But as you're walking through that tool and I just mentioned, staying out of solution space, it's really good to walk through its stepwise. First, identify all of the tasks, don't think any further about them, just identify them and then think about, what can go wrong at each step. Again, don't start thinking about how to prevent it or what could happen? What it could be the outcome, hazard or harm from that. Just identify what can go wrong. If I need to, I don't know, I'll go simple, remove a cap from a pen. What can go wrong? I could not remove it. I could not be able to remove it. Just, breaking it down. And what does that mean? Maybe nothing, maybe something. If it's an epinephrine injector, then it's pretty important. Right? And so just kind of trying to stay, focused in those columns as you add to it and you build that information up, that then builds that landscape for you to, then step back and look at solutions. So just, I guess, if you on a device.

Etienne Nichols: No, that's really good. Well, that's great. Jon, did you have anything else or any of the thoughts or questions? This seems like a good spot, but go ahead.

Jon Speer: No, I'm good. I always enjoy talking about this, topic because, well, there's just so much confusion, unnecessary confusion. And I think for a lot of people, when I interpret the confusion, it's almost like they interpret this as a unique, almost disjointed discipline, that's in addition to all the other things, that I need to be doing. And as I know, it's the same. I mean, it's just a slightly different context. It's really actually emphasizing to your point, Shannon. What's important from the use of this product or I like what you said earlier, about making sure that I'm focusing on safety and efficacy. Safety and efficacy, which, that's big part of what we're we should be doing, as we're designing and developing medical devices. They're safe and they work so that's makes sense.

Shannon Hoste: Just the lens for that. The other piece, I think trips people up a lot is, they think of it as a test, a validation tests. Right? Because that's, the end of day, it's kind of the end of the evidence pool. And when a lot of folks, particularly medical device, when you think of testing, you're thinking of verification testing, you're thinking of 95% confidence, 95% probability kind of testing, right? Reliability testing. And it's not that it's... And again, I go back to the corollary with software, it's you are putting it through its paces. You're doing a dry run of what it's going to be like postmarket and making a list of potential issues, that you see and evaluating them piece by piece and saying, okay, here's my bug list. My anomalies that are left in my user interface, that can cause harm. And here's what I need to do about them or why they're okay. And so, that's the bulk of the validation assessment. It's not a pass, fail kind of thing. And I think that can get confusing if it's not understood, as well.

Etienne Nichols: So I came to the industry as a Mechanical Engineer, prior to being in the medical device. I was aerospace for a little while, and there was ergonomics usability and things like that. So I came to the medical device, kind of with different eyes. I'm curious. Do you see more of a blending of the human factors or do you think it will always be kind of its own division? Or do you think it's going to be pulled more into the product development and mindset? Any thoughts? I know as a consultant, you work with a lot of different companies now.

Shannon Hoste: Yeah. It's gotten better, so I've been working in this space, started out in human factors in the late nineties and it was very similar to what Jon was explaining of, it just wasn't really on the radar. And it really didn't get traction until in my experience, until the FDA started asking for it. So I think it's unique from that standpoint of, you design controls all comes out in RND, you experience it through your audits and your inspections. A lot of the push on HF, has actually been from a pre- market review standpoint. So it's coming in through your regulatory group rather than your quality group. I think, you been thinking around that a lot lately. What kind of dynamic does that cause? And so they're saying this data is needed for a submission and then that's, then pushing back to development to build it as it go. And so what I think I'm seeing anyway is that, companies were then being asked, they had to have this data and then they started to learn that, oh, hey, this is beneficial and the earlier I do it more valuable it is. Right? And so it's been growing, to be more part of that product development process, in general or time. I don't know that it fully integrated. And I think part of that is some of that confusion and understanding of how it actually wraps into risk management and product development process and so forth. What do think Jon?

Jon Speer: It is interesting to hear your experience about how, the RA side is feeling a lot of this, but it kind of makes sense at the same time. Right? They're, they have a job to complete and they're the co- owner of that regulatory submission. And if this is an obstacle for them to complete that job, I can understand how they're feeling that. I mean, it's a, but at the same time it is discouraging. I mean, I hope we're on a path and I've seen a lot of improvements just in the past decade or so, where we're so much better as an industry and really understanding, the role human factors plays, in our design and development. But man, there's still a lot, a long way to go. I mean, so the more I think we can help spread the word is, it's not that bad.

Shannon Hoste: Yeah. Yeah.

Jon Speer: It is actually...

Shannon Hoste: It's actually helping,

Jon Speer: It's actually helping. I mean, just about every product development engineer that I knew or have known in my career, they want their device to be safe. They want it to work. So this is actually, if you embrace human factors, this is a mechanism or a vehicle that helps improve that as a likelihood. So, bleed into it instead of resist it.

Shannon Hoste: Yep. Absolutely. The other thing I've noticed or thought about, is the work that human factors is doing is optimizing your product, for effective use, Right? That will happen, regardless of whether you drive it in development or whether you wait for your customer to give you that feedback and do the next gen. Right?

Jon Speer: I mean, who wants to manage all these complaints, when you launch a product?

Shannon Hoste: Right. So it will happen. It's just a matter of whether you're, investing early in doing some of that research up front or whether you're just going through product iterations to get there.

Jon Speer: But who... Really what's the role that dies, right? Let's assume you ignore, the benefit of human factors during development, you launch a product based and you get into market and now you start dealing with all these complaints and all this feedback and God forbid maybe, even some MDRs. Now you've got some bruises and maybe some black eyes with that product, so it's going to make it difficult to... You got the message now, because you're dealing with all these complaints, but that's a painful way to do it.

Etienne Nichols: Yeah. Well I think every engineer, it should be almost mandatory to read that design of everyday things. It's just like you mentioned earlier that, what about that green stop button? That's terrifying to think about. So yeah, exactly.

Jon Speer: I think that's a great point. I mean, think about all the products we use in our everyday lives. I mean, some of them are like, oh wow, this doesn't fit in my hand, very well or whatever the case may be. I mean, I think we know when there's bad design and bad user experience, more so than maybe we appreciate good user experience. But sometimes you'll figure out something and you're like, or you'll be holding a product or using a product like, oh wow. That was amazing. Right? And I think we, as medical device product developers, I think sometimes we forget, that there are humans who use our products.

Shannon Hoste: Yeah.

Jon Speer: It's just, they're not-

Shannon Hoste: They're not all engineers.

Jon Speer: They're not all engineers. Yeah. And the products aren't not necessarily, in our everyday environment. Right? Sometimes they are in an operating room and that's sort of thing. So, but there's still humans that use products. They still want a good experience. They still want, to know that product that they're using, that is familiar to them and that it functions and all these sorts of things. So I think if we just realize that, we're designing products for humans, so we, humans that we use products every day, some have great user experiences. So how can we replicate that in the things that we're designing and developing?

Shannon Hoste: Yep. Absolutely. Use them every day when we're tired, when we're dealing with all sorts of constraints. When maybe kids are around us or pet or whatever. Whatever's going on in life. We need to be able to use our products too, so.

Etienne Nichols: Yeah, I've had conversations with my wife who is a Critical Care Nurse. So she was working nights and you want your night shift nurse to be able to do what she needs to do or he, and she would ask me about some different things and I might be able to explain, well, they probably designed it that way, because the injection mold was this or that. And she's like, well, I don't care. And that's true, when you're frustrated, you don't care why it was designed away. You wouldn't it be designed correctly. So it's a good point. Well, cool. It was so good talking to you. Shannon. To you, let's see, how can we find more about your company and what you do?

Shannon Hoste: Sure. Yeah. I'm in Agilis Consulting Group and President of the group. And so we run consulting focused purely on human factors, regulatory perspective for med device and pharma. So we work to stay connected with all of the standards that we can help. And we have the deep dive into the regulatory strategy around human factors, so that our clients don't have to, we can support that, them with that and then running studies and all the other fun stuff too. So, you can find us on the website or on LinkedIn.

Etienne Nichols: Okay. And we'll put the link, in the show notes as well, so.

Shannon Hoste: Yep. My second job, is a Pathway for Patient Health. It's a second job as a kind of a passion job. And so there it's a program for students in sciences at universities. Free for any student, globally to take and get a certificate. It's a five course curriculum to study legal regulatory requirements of med device and pharma, process development and validation, risk management. And we just walk students through, we've got students from five continents, I have 90 students this semester. So it's pretty exciting, to reach out and then have been about enough, far enough in now that people have completed the program. And we've seen where they've been able to move into the industry and such too. So that's exciting too.

Etienne Nichols: Okay, excellent. We're going to have to get a link to your passion project as well. That sounds exciting. Very cool. Well, it was a good talking to you. Did you have any last comments or last words for our audience? Any suggestions, tips, anything like that? Come use you, for human factors. Right?

Shannon Hoste: Yeah. My last one is just that point we made earlier, is your product will be evaluated for human factors. It's whether you're doing it or your customers are doing it, so.

Etienne Nichols: That's good advice. Excellent. All right. Well thank you all for listening to the Global Medical Device Podcasts powered by Greenlight Guru the only medical device success platform, specifically designed for medical devices. So if you're interested in learning more, go to www.greenlight.guru or of course, check the show notes to learn more about Shannon and what she's doing. All right. Thank you all. Take care.

Shannon Hoste: Thank you.

Etienne Nichols: Bye.

ABOUT THE GLOBAL MEDICAL DEVICE PODCAST:

The Global Medical Device Podcast powered by Greenlight Guru is where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge, direct from some of the world's leading medical device experts and companies.

Like this episode? Subscribe today on iTunes or Spotify.