Integrating Human Factors into the Quality System (QMS)

So, the way this is gonna work today. is a little bit different than usual. I'm glad everybody's here, and a lot of people are joining, so as the people are joining, I am going to talk about how this is gonna work. We have a slide deck prepared, but it's intended to elicit response from everybody participating. You can… Respond either, verbally, you know, hey, my opinion is, my experience, and what we're really trying to do is tap into the group experience. And, the collective knowledge that exists within this group, because we have so many senior people from such a diverse

group of areas, from engineering, to human factors, to risk, to quality, and regulatory. So, absolutely, chime in in the chat, chime in, in, the, by joining as a panelist. I would encourage everybody to say what country they're dialing in from, and what their main area of focus is, whether it be regulatory quality, risk, human factors. Just, you know, to give us an idea, put that in the chat, and… we will go from there. For those of you who aren't aware, We worked with Claramid to develop a,

MedTech Usability Prep Kit, which is a 21-page guide with… that you can, use, along with the 5-Day Email Companion email course, where every day you get a short, exercise, delivered to you, understanding different aspects of human factors. You know, this has been, another one of… another one of our experiments. You know, and I'd love to get your feedback, so if you would like a copy of the prep kit, just write prep kit in the chat, and we'll make sure that you get it one way or another. And now I'm gonna go backwards to the first slide, and I'm gonna go ahead and kick this off and introduce today's speaker, who is Liz Wellwood, who I met recently.

She is Director of Quality Services and Operations at Claramed. I'm gonna let her tell you about her background. But I'd also like to welcome everyone else to the call today. I'm gonna encourage as many people as possible to join live. You know, please don't hijack the call for your own personal benefit, but feel free to contribute. And I would, love it if we could go ahead and get started. Hi, Liz! Welcome!

Hello! Thanks, Sean. Thank you, everyone, for being here. I'm super excited to… come and speak, or at least lead the conversation, on this topic. I have been… Living my world in quality for the past 14 years. And all of that has been in consulting. And so I've been with ClareMed for about 2 years now, and before that, I was with a, consulting firm that only did quality. So… I've seen quite a lot of things, go really, really well and not so well, throughout my career. But I am, you know, I would say I definitely do not have all the answers, but I am very excited about the topic. We're gonna…

go through today. And as Sean mentioned, the goal of this, or the hope for this session, is that it's a little bit more interactive and collaborative. And that we can just all kind of bring our collective experience into the conversation. And so in order to do that, it does require some participation. So as we go through the slides, you'll see prompts, and we'll ask you to drop your answer in the chat, and then we'll call on a couple of you to kind of join in on the conversation. And there will definitely be times where if I get asked a question, I might toss it back to the group. I think there's a wealth of knowledge here, and I'd love to tap into that.

Alright, let's get rolling. So, the party really starts now. For me, this is kind of… this slide is kind of the heart of why we're here. Like I said, I spent majority of… I mean, my entire quality career has been in consulting, and I've kind of always seen human factors as being integrated into the quality system. So coming to ClareMed and experienced other… experienced other type of clients, and… and not really seeing that connection everywhere has been a little surprising to me. But… human factors kind of sneaks into our work in ways that we may not even realize, right? So, anytime we question a design step, anytime a Kappa uncovers, like, you know, unexpected user behavior.

Anytime an IFU gets rewritten because you know, people keep doing it wrong. That's all human factors kind of, like, tumbling its way into our world and into our work. And it does… I don't… I think sometimes it doesn't really get noticed. And what I really want to do here is, ground this conversation in all of our collective experience. So in a moment, I'm going to prompt you guys, the first prompt of the morning, or day, depending on where you're calling from. I'm gonna ask everyone to complete the sentence in the chat. QN factors shows up in my work when? But first, I wanted to kind of break the ice by sharing one of my own experiences of when I say human factors kind of slammed its way into my work.

There was, one point in my career I worked with a design team, and… My… my kind of team was brought in to support The protocol creation, the report creation, and then helping put all of the data analysis together. And one thing that kept coming up in this particular, device was, there was a step that users kind of consistently either skipped. Or misunderstood. The step itself, like, when you took the step back, the step itself wasn't intuitive, it wasn't, like, visible enough in the workflow, and the designs team immediate reaction was, okay, like, let's just get back to training, and let's really kind of…

Hone in on this particular task. And when you take a step back, and you think about humans and using these devices, human factors really encourages us to take a step back… excuse me, take a step back and ask a different question. Are we trying to train the user out of a design problem, right? Are we trying to… fix… something with training that really just won't, you know, it can't be fixed. And once you apply that lens, and in this situation, when we applied that lens, it became very clear that this was not a training issue. The user interface itself was driving the confusion. The task really didn't align with the user's natural expectations or mental model, right? Like, how they…

visually, in their minds, see this working. And from there, we were able to kind of, like, revisit the user interface and the task flow and set it up in a way That it was more visible and, intuitive. And from that point on, the issues with that particular step stopped. People were continuing to actually follow the steps and not skip steps. And when I think about this. distant memory. This, to me, is such a great way that we kind of show how human factors strengthens the quality system. Training is essential, right? And… humans definitely impact training, but it's not a substitute for a good design, right? So,

there was some tweaking that had to be done here, and once that was done, that kind of human error that we thought we were seeing, like, it was kind of fixed and no longer an issue. So now I want to turn to the chat. And I'm gonna ask Sean to call on a couple of people. We want to, like, expand a little bit on, on what you've dropped in there as when you… when Human Factors has kind of Slammed its way into your work world.

Okay, let's start with beyond.

Chase.

Sean, you're not sharing this slide. Same thing.

What'd he say?

Hang on a sec. Yeah, I'm gonna, I'm gonna ask, Bijan to share. Okay.

Yeah, yeah. So, human factors is a major player in safety risk management, which is my world, and in fact, it's been said that it's the largest contributor to medical device safety risks, far more than the design failures or software failures. And creating a intuitive and, understandable interface with, for a user is not an easy thing. Yeah. And I think… all of us who have been involved in creation of medical devices. I mean, some things, like a tongue depressor, maybe it's easy, but when you get more complicated, it's not so simple. So it is a major challenge, and I think human factors is really one of the largest contributors to device safety.

Yeah, I totally agree. And you're right, it's not a simple task, But I think humans and our nature were so complicated that it makes sense. But I do think it is such an important part of design safety, that I think sometimes gets downplayed a bit. I don't know if you guys agree with that, but… I've seen it kind of throughout my career, So, do we want to pull on some other chats?

Absolutely. Let's… let's hear from Hendrik for a moment, if he's online. Are you live, Hendrik?

Yeah, yep. Yeah, so as I told you, I work in, yeah, human factors and usability engineering, so I, see it all day, and, what's interesting to me is that, other than understanding our users, we, tend to forget that we also have to understand our client contacts. If I'm talking to a risk management, yeah, professional, if I'm talking to a risk manager and supporting use-related risk analysis, then I have to understand that they have a different view of all of this. And that I have to cater the human factors contents that I want to be included in the risk management.

To them in a way that leads to inclusion and proper, yeah, proper mitigation.

Are you guys seeing, the speaker on the screen at the moment? It's… I'm… I'm having a little trouble sharing.

No, it just… it's dark right now.

Oh, it's dark, okay. But… I will go back to sharing. My desktop. I thought that I was. Now, are you seeing it?

No.

Not yet.

Let me go here.

Boom. Now we see our desktop.

Right, okay. And here, and…

There we go.

Now you see the slide.

So, are you able to see the speakers? Like, who's speaking? Or are you just seeing… Yeah, in the speak…

Now, the speakers show up in the gallery.

Okay, sorry, I'm inept today. Let's… let's keep moving forward, because we've got a lot to get through, but, I think we're starting to get the hang of this, and, I would, you know, encourage you to raise your hand if you'd like to share, but the, We will… we will keep moving.

Is that okay, Liz? Yeah, let's roll.

Keep moving.

That's an… Sean, we do have a question in the chat.

Yeah.

Is human factors similar to usability? Could you please provide the specific example of human factors?

I would love for maybe one of our human factors experts to jump in and answer that question.

Yeah, sure, I can… I can speak to that if you like. No problem, Louisa Harvey from Claramed. Is human factors similar to usability? Absolutely is, and the wording is used interchangeably. I know the… if you actually looked at the dictionary definition of both of them, there will be a slight nuance between the two. However, as far as the FDA is concerned and other regulators, they consider usability and human factors are the same thing, so that's probably the easiest way of describing it. One thing that is different is user research. That's a separate topic and can get confused with usability, but anybody else can feel free to chip in on that.

Thank you.

Yeah, I think…

I think in my world, when I… when I was doing a lot of hiring of, you know, human factors. the, professionals, I would get a lot of usability engineers applying to the roles. And in that case, at least for the role that I was looking for. they didn't have the experience that I wanted. And what was the experience that I wanted? It was working in a regulated environment. So there can be a lot of usability work in all of the products that we use around us commercially, but not all of those are regulated like medical device, and that's where you see a lot of the human factors experience coming through, is in, you know, aerospace.

in medical device.

And you're like.

they get to know your regulations, so I think even though They can technically be very, very similar and related. It's the regulations that get you on the human factor side, in my experience.

Federal regulation.

Carrie, would you like to comment on that?

If you don't… I… yeah, engineers don't always seem to get it. In my experience, and then, you know, trying to explain to them that we need to start early in the process, and it's the critical task, and bringing it back to the human, and the intended use, and the health factors, they just… a lot of times, it's really… It's just… The connection there seems to…

Hmm.

I don't know, Liz, you can probably speak to it as well, but the critical tasks, they seem to get really confused and… You know, you need to dictate how your design choices also affect the regulatory outcomes, and you need to start early, and…

Yeah.

It's, you know… the FDA and what, you know, when you're building a device, or a drug, or anything like that, it all has to do with your user inputs and the actual… what you're building in your market outcomes. So, you know, your marketing team has these user… Or marketing, or whatever you want to call it at the beginning of what they want to do, and they all need to trace back, and It's a big old circle, and it's not that hard.

Blah. It's interesting that you say that, though, Carrie, because I think, before I came to ClareMed. human factors, usability has kind of seemed like this, like, incredibly… I'm not saying it's easy, right? And there's complexity to it. But it was just, like, this mystified process that kind of always seemed really, like, beyond me kind of thing. And then I actually am working with people that specialize in usability and human factors, and it… it seems like it's not as difficult or as this kind of, like, mind-blowing concept as I thought before. So it's been… it is interesting to kind of see how other people work, how they're different, like.

a quality engineer versus somebody that, like, they do human factors, and that's kind of what they do. It's been an… it's been a really interesting experience for me, to say the least.

And to try.

Yeah, something good.

For all the groups, because you need to bring all the groups together early, and try… it's basic, it's not that hard, and as long as everybody's together in the beginning, and see how it rolls all the way down, and then bring it all back together at the end. You know, that it makes it… Easy if you bring it, you know, start at the beginning and let everybody see how it trickles down at the end. Yeah. Let everybody work together in their silos, you know, and then at the end have it as a big surprise that, oh, it's the big usability, and it's afraid. Because the FDA, that's what they want to see at the end. It's, you know…

You don't want to redesign it at the end and say, oh, we have to do this huge usability, and…

Yeah.

it's this big, ominous thing. It's not. It's… it's honestly… it's pretty simple. So…

I want to add something. To move forward.

Sorry, Sean.

And then, I mean, there's gonna be… there's gonna be time. We have a lot of slides, we have a lot to cover, and I want to make sure that, so, Alexandra, you can comment in the next section. There we go. But let's move forward.

Definitely, yeah, I could keep talking about that, Carrie, forever, but thank you, Sean, for keeping us on track. So right now, we're looking at what we're calling the structural spine. These are some pretty pivotal pieces of a quality system, right? design, risk, VNV, labeling, suppliers, training, complaints, etc, right? this really is the spine that keeps your quality system upright. Some pretty big elements of it, anyways. And this kind of goes on to what we're talking about, or what Carrie was saying. something that I've seen, and it varies, right? Like… Companies kind of do what they want, when they want, and as consultants, we can do our best to try to kind of advise

the way that we think it might be easier. And something that I've always found interesting Is, teams kind of experience human factors at different points along the spine, right? So some see it in early design, others feel it in risk reviews, right? And then, and some don't see its impact until… until post-market surveillance, which… Seems crazy to me. But, I do kind of want to open up the chat again, so let's just kind of go over where, where you guys see human factors pop up in the quality system first. I think it's an interesting, topic to discuss as a group.

That's great. So I'm gonna turn to Leia first.

Previous to this role… it happens in this role too, but, In my last role, I was at a company for 11 and a half years, and I got to be on the core team. And… That expir… before HF existed on that… in that 11 and a half years, they didn't have human factors on the core team. It wasn't part of the corporate structure, and they didn't have enough knowledge with any of the other team members between marketing, quality, R&D, clinical, medical. They knew it was in the background, but they didn't have the knowledge or the experience to know the importance of it for the product that we were making, which was a home use…

pump, wearable pump. And they very quickly realized that they needed someone on the core team who knew what they were talking about. So that, in that experience. you know, you really see the interaction from start to beginning in product development, where, you know, I was working with marketing to develop user needs, doing marketing studies, you know, different heuristic analyses. Architectural inquiry studies were going into the places where people were using similar products to watch how they were observed.

How they were using products, not just how they said they used them, but how they actually use them. What do they work around? What do we have to account for. And then…

Quality. Quality was, like, was my best friend. Even… even… I love quality. They're the ones doing all of the risk analysis, usually, right? So, whatever the R&D team and whatever the teams are building, they have to demonstrate to quality as, like. the police, right, in the industry to say, hey, this product's not safe yet. Keep going. To show that your risk management process is underway, and that you've got all the mitigations in place. And then from the medical, clinical side, is your product meeting the needs from a clinical efficacy perspective? And some of that, you know, especially for home use devices.

Nope. Lay people do all kinds of crazy things that you have to. And, they still have to be able to, you know, have a clinically, relevant product in the end. So, working very closely with clinical and medical affairs to understand, you know, how can, like, what's important for the users, like, how do you get this across to the users to make sure they're using it correctly? And then, yeah, regulatory, again, another, another close arm-in-arm function where you've got to make sure that you're meeting the quality, I mean, the regulatory requirements for in the very specific ways of going about structuring your studies to make sure you're not biasing, and you're not, you know, doing something wrong, because it can be very, very specific. You can do one little thing, and the FDA's like, nope, you did that wrong.

Try again. And that's an expensive mistake to make, especially in HF. So that was one of my favorite roles, and we touch on it here at ClareMed, working with our different clients. There's different functions that you have to interact with, and some of them come along more strongly at different levels of the project, or different periods of the project development process. But yeah, I, as a human factors engineer. we need every, part of the product to be running in synchrony before we can take the final commercialized product and validate it. So, you gotta know what everyone else is doing, and you gotta meet their needs, too. So, it's a really cool place to be in human factors engineering usability.

Touch them all. I think… what was the beginning of the question? Where did you first touch base? Yeah, that's really how it happens.

I know, it's…

Andros, you wanted to share something? I believe. Did you have your hand up? Yes? No? No?

I did… I did a while ago, but the point that I wanted to share was about engineers and their… The decisions that they make. I've seen engineers make decisions that are completely reasonable and rational, but because they don't understand the clinical context. It… The decision's wrong, and it's… To know the significance of a decision, you need to understand the context, and that's often why engineers make decisions that Don't work in medical device development, in my experience.

Context is everything, absolutely, and the clinical context in particular. Excellent point, thank you for sharing that. So, if everybody wants to drop in to the chat, for most teams, where does Human Factors enter the quality system first? Then I think we can move on to the next slide, maybe?

Yeah, I just want to, you know, kind of touch on, like, some of what Leah was saying. the way that I look at this, like, what we're calling structural spine, is Human Factors supports each of these segments, and it kind of, you know, strengthens, like, design decisions, risk files, training, etc. And I think understanding, like, the interconnectedness of all of, like, the pieces that go into device, right? Or, like, making something. Is kind of what helps the team, integrate the human factors pieces a little bit more proactively than, like, reactively. I saw someone said, like, in the chat, having it early on

is kind of ideal, and I could not agree more. I think the same way about quality system implementation. Alright, let's… Rock and roll. Alright, so now that we've kind of seen where human factors, very briefly, high level, fits along that structural spine. of the quality system. Let's take a practical… let's look at a practical tool. That kind of anchors all of these touchpoints, together, right? The URRA, I'm sure everyone here is super familiar with that. And one helpful way to think about the URRA, is that it actually represents the structure of human factors itself, right? Users.

Who they are, what they bring to the interaction, the related requirements, what we expect them to do successfully, the risk, what could go wrong and why. And then the analysis, the evidence and rationale of our decision. It gives us a very clean, intuitive way to kind of break down Human Factors activities, whether you're new to this or, like, a seasoned veteran. let's look for my prompt… I definitely, want to kind of touch on what you think is the most challenging part of your RA. I think… I'm gonna add, kind of, my own input or opinion here, and I think from what I've seen and my experience, right, I'm… I'm no real HF expert, but I think, like, user groups, like, defining

the different user groups. I think it's easy, maybe, to assess or figure out what that primary group is, but… you know, as you kind of go along through the process, different user groups maybe pop their heads up, and I think that might be a little bit more challenging. But I definitely want to hear from some of the folks on here that work in HF as, like, their day-to-day, What do you think is the most challenging part of the URRA? And we'll call in a couple of people. And we do have some examples listed here. For use, we didn't consider caregivers, risk. A step that we assumed was obvious turned out to be confusing. We've… I'm sure everyone has seen that a ton of times. We didn't define acceptable success criteria. I swear I can talk this morning. And then analysis. We didn't document the evidence behind our decisions, which…

I've also seen many times. But definitely want to call in a couple people. Sean, if you can help me…

I'll keep talking if you want.

Alright, go for it, Lee, I love it!

If they want. So, here at Clarimed, we see a lot of URAs from our clients, and we are tasked with overhauling them quite frequently, or at least providing additional guidance, so where there's gaps. Or we'll just do a gap analysis on URA. And I think one of the… a couple of things that I see quite frequently are… People not, having a clear… basically doing hazard analysis first. You know, what are the hazard situations that would cause a specific harm? And the kind of… having that base structure before even going into a URA really helps you just kind of pick and… pick and grab from your hazard analysis to say, alright, this use… this, potential use error has occurred, what, you know, what's the hazard and harm associated with that? You don't have to think about it every time you come to a new line item. You pick it from your hazard analysis. And that gets… and sometimes we have people who have a hazard,

That, you know, maybe the harm is a… it's a… it's a cut. Or it's a laceration, and it has a severity of maybe 2. And then down the line, they have another cut or a laceration, and they have a severity of 4, and that… the FDA really likes to see, like, maybe it's a minor cut, a major cut, kind of segmenting out what those harms are, so you don't have the same different severities of harm for the same harm. That's… that is a big one. We see it all the time. And then properly explaining the hazardous situation or the potential use error is a big one.

In addition to that, Leah, I've just noticed some really great comments in the chat, so yeah, thank you everyone for inputting into there. But I did notice the challenges, somebody's written, I think it's Kath written, the challenges, we guess is being able to understand the product enough and relying on those, who understand the product to help and drive the task analysis. And I absolutely, see that, for sure. There's two issues. One is getting access to the right people to speak to, to actually input into it, instead of people sitting in front of their Excel spreadsheets, guessing, in essence.

what the, outcomes could be. And then the other hand… on the other hand, it's also getting access to the product, would you believe it? And I have actually seen instances where people have written a URA, and I've spoken, so clients come to me, they've written a URA, And I've said, okay, great, I'm gonna check it. Can I have a look at the product, please? And they've said, oh, we've had to write it without the product, because we can't get… we can't get hold of it. It's normally large companies, large medical device companies, and they… it's literally been written blindly.

And that's one thing that I definitely find is a problem.

Agreed. And someone in the comments wrote, shouldn't the harm definitions come from risk management? Absolutely true. That hazard analysis is a cross-functional effort from quality, medical, clinical affairs, R&D. It should all… it's a group effort. It should not come from HF, actually. It can, part of it, but that's a tool for HF, I would say.

Yeah. Do we have anyone else that wants to speak in? Thank you, Louisa and Leah. Our HF experts on the call, saving the day.

David has to stand up.

Right now, I get a drop from my body.

No!

Sorry.

That was a good one, Leah.

Liz, I'll just say, when I'm in the middle of them, you get your… your guys in the middle of your, when you're in your actual.

Excuse me, one of the studies.

doing them. The stakeholders always like to say, well, I've always done it this way, why are we trying to…

Just kidding.

Do this new stuff.

To mute.

Separating the old habits from the new habits when we have a new device out there.

Yeah, I think… I don't know about everyone else, but I've seen that so much, not even just in, like, design or human factors. even in quality, it's like, people don't want to be challenged or have their, like, normal way of thought process challenged. It's interesting, and it is a difficult Hurdle to kind of… get over. What have you done in those… I don't wanna… I don't know if this is hijacking, but I'm just curious, Terry, like, in your experience, like, how have you, kind of. Dealt with those moments.

You have to… I mean… it becomes a fight, right? So you have to try to… it's conventional wisdom versus the evidence, so…

Right.

A lot of time, it's black and white, so you have to… depends who your audience is, right? So if it's engineers, it's bullet points, and so you have to… to demonstrate the evidence versus the, you know, validate it with human factors evidence, and so you have to go… in and pinpoint the user interactions that rise, basically, you know, perform those that are Have been performed that could cause harm, which requires evidence of judgment and defensible rationale. And so, you know, risk assessments are so… I mean, it's perception, right? Who's… who's all done… risk assessments here, right? It's…

Yeah, no, I appreciate you, Sharon.

the, 5.

Yeah. I think everybody… I think it's good to talk about that.

So, Liz.

Yeah, yeah?

Unless, David, before we move on, I just wanted to… Understand if you're going to talk about off-label use. Or… I'm gonna just… Expected off-label use, anticipated, and how are you controlling for that, or… Or others were… might… Some of us say, forget about it, it's not in the use indication. Or, oh my goodness, this is a… could be a potential. Which we may not see until complaints come up about how somebody uses our products, but I wonder, what are we doing up front, perhaps, to prevent or control?

I don't think we have that built into these slides. We do touch a little bit on, like. IFUs and things like that, but… You know, that's a really good question. And what I've seen companies do is they actually do, like, usability studies on the labeling or the instructions themselves. I don't know if this has answered your question the way you're hoping, but that was something that recently I had the opportunity to be… to kind of just take a little QA dip into some data for a recent study we did, and it was a client that did their validation with us, and then came back And decided to do a supplemental validation just on the IFU itself, or the user guide. I'm not sure, I can't remember exactly what they were calling it, but it was their way of trying to proactively

Make sure that the labeling, the instructions made sense to the actual end user. Because this was a consumer product, and… I thought it was really great that they were doing that, and they gave the participants about 3 different versions of their instructions for use, or whatever they were calling it. So I actually thought that was… I was really, really, like, kind of pumped on that, because to me, that just showed that the manufacturer actually cares that this device is going to be used as intended, and it's easy to use. And they hit all kinds of demographics there, so I thought it was really awesome. I don't know if that answers your question, but that…

in my head is kind of one way I've seen it kind of be proactively, prioritized.

No, that's fine, and I just… you know, Kelly just put a comment up. As I understand, the agency believes it is your responsibility to anticipate it can be used off-label, and it becomes your or our responsibility to control for that as best we can. Obviously, there are crazy people out there who stretch to the far extreme, but, Yeah, thanks. Let's go to Henrik.

Yeah, I actually wanted to react to your question. Because, with, usability engineering, according to, IEC 623661, Off-label use is most closely resembled by the defined abnormal use, and the 2016 guidance by the FDA concerning usability and human factors engineering for medical devices also specifies this as abnormal use. Abnormal use is not part of usability or human factors engineering. But in human factors or usability engineering, we can find indications for off-label use, or for abnormal use, and we have to forward it to the risk management, because risk management, according to ISO, what is it, 14971,

is, yeah, doesn't, doesn't exclude, this off-label use. So, we… Actually don't have to deal with it, but if it happens, then it becomes foreseeable, and if it's foreseeable, then we have to inform the ones who, yeah, do risk management on foreseeable use, which includes this off-label use.

Thank you for sharing. jumping in there.

Let's keep moving. Let's go to design controls, if we may. What human factors elements belong in user needs? Examples, use environments, critical tasks, user limitations. Liz helps us understand this slide.

Yeah, this is gonna be a totally interactive slide, as we all are aware, I'm sure. Design control, it's one of the biggest opportunities for human factors, to make an impact, but only if we capture the right things early. So let's kind of work together. I'm not sure how we're gonna input this, Sean. Maybe you can help us there, but… Let's gather what belongs in human factors. Human factors aware design controls, right? So let's… I guess, put in the chat, Sean, is that who we're gonna.

Yeah, let's use the chat vigorously. Let's… Let's let the chat build the document, as well as, you know, calling on people to… join in. Who wants to start? Express here.

I'd like to say something.

Please do.

In, in my experience.

Tells who you are.

I'm one of the engineers that people… Okay.

Poor engineers.

poor engineers. Now, in my experience, You like to do a lot of formative testing before design controls kick in, because when design controls kick in, it becomes harder to change things, and more expensive. And then again, usability testing, usability… acquiring usability information is quite expensive. So people like to, You don't want to spend a lot of money up front, and in my experience, you see that First, you have your formative testing, and you design something, and in the end, you have your summative testing to verify that you've done it right. And… the… the,

What I like to see from the summative testing is that your design was right, and not that there are new factors kicking in, because then you have to change it again. So, there's… there's… the problem with usability Testing is that it's so expensive to do. It's the same with, with, clinical evaluation studies. So, they are expensive, and… You don't want to do it too much, because then you don't make any money out of your product anymore. So, I'd like to see, say. I'd like to see your opinion of Clarimet on what the most efficient way of doing this is, on how to implement this in your design process.

Hmm. That's a tough question. I'd like to take a moment to do a commercial here. If you haven't requested your prep kit, from Claramed, please just write prep kit into the chat, and we will make sure that you get a copy of the prep kit. Similarly, they're offering a 7-point usability assessment if you would like a 7-point usability assessment with one of their team members, to talk with one of their team members about what you're working on. Please, you know, put, That in the chat that you would like, 7-point assessment, or just write the word assessment, and somebody will reach out to you. That's it for my interruption. Sorry.

Thanks, Sean. Are we getting… Kind of the fill-ins in the chat, I don't know that I'm seeing… So, what HF elements belong in user needs? Inputs must reflect, outputs should demonstrate.

Let's, turn it over to a member of the committee. Who would like to join in on this?

I know that design teams like to have the design controls carved in stone, so that they don't change anymore. Because, how do you call it? When requirements change over time, then it becomes expensive again? And then again, The world evolves around you, so there will always be changes when you design something. But at least the requirements should be formulated well, that you have a requirement that you can test Either with summative formative testing, or by analysis, or by whatever. So they must be really hard to test. Easy to test, hard in stone.

Thank you. There have been a number of comments. User needs should capture the needs of all the identified users, not the primary… not just the primary user. Similarly, different user groups. Let's talk about user groups for a moment. Who are they? You know, how do they change depending on the device, depending on the use environment? One of the examples that I love is emergency use devices. Because emergency use devices, are often, oftentimes used by, the least qualified users. With the fewest amount of instructions, and, usability needs to be pretty simple.

Versus, a complex surgical A tool that is only used by physicians in the operating room. So these, these things, heavily impact, how, how the training and… and detail. That's my two cents. Thoughts?

To add to that, actually, it's something that made me actually focus on human factors as a career. when I was looking at specific user groups for a product, and you would have assumed the user groups were very, very similar. It was working on the product Sumatriptan, which I'm sure many people have heard of, for the treatment of migraine. And, this particular product has two user groups, migraine and cluster headache. And, I was told by the engineering team that they were the same group, and just to treat them as such. But I started to investigate it a little bit, because I didn't feel quite right about that. And then I realized that cluster headache actually, is… predominantly occurs in men, and so 90% men, whilst migraine would be 80% women.

And cluster headaches come on at 4am in the morning, so typically in the dark, when you're trying to fumble around finding the device, whilst migraines come on at 10am in the morning. And cluster headaches is actually far more severe as a condition than migraine, and that… particular piece of research, and then speaking to those groups, and realizing that I actually had to design really quite different injection devices. really fascinated me, and from then on in, I've been, yeah, extremely fascinated by different user groups, and just making sure you do check each one, when you're, carrying out your research.

I would love to see me trying to read those tiny instructions at 4am.

I don't… I don't think they can turn on the light, because they're… they're… it's so severe as well, so they'd be fumbling around in the dark. Because it's… it's absolutely excruciating, this particular type of headache.

Should we move to risk management?

Let's do it. Alright, so we're gonna shift over to risk.

Who are risk people on the call? Raise your hand. There you go, Bailey. Hi.

I can't see, but I know you guys are there, so yay! Risk is where, human factors obviously becomes, at least in my opinion, super essential. Design controls capture what we expect users to do, and risk management forces us To ask ourselves, like, what could actually go wrong? This is another interactive slide. But I, you know, something that I've seen recently is just, Kind of during studies. There was a moment where there was, like, a safety cap that needed to be removed before, like, you can activate the device. I think in the engineering minds, right? No hate to the engineers, this was, like, a… this, I think, was thought of as, like, a very obvious, like, low-risk step. But…

The, it wasn't. And multiple users tried to activate the device with the cap still on, and so it kind of made them think the device wasn't working. They kept, like, pressing it harder, they even tried to, like, twist and unlock the device, and it really wasn't, like, something that they had captured. Beforehand of what could go wrong with the device. And so, it kind of helped us, you know, using the URA helped us break… break it down. But that's just, like, one example of something that I've seen where it seemed so obvious. It was a low-risk step, but it ended up causing, like, a lot of issues.

So, we definitely want to make this interactive again. What is a use-related hazard you've seen? catch a team off guard. So mine was just kind of like that cap not wanting to come off, and I'd love to hear from the group.

I can give an example.

Awesome, thank you.

Okay, yeah. One of the devices I used to work on many years ago was a peritoneal dialysis system, where the patient is supposed to connect a tube that goes inside of their belly to a device that's outside of their body. So while they're sleeping, they're getting dialyzed. And, Cleanliness and aseptic technique is incredibly important, because you have a tube that's open to the inside of your belly, so infections are very possible, and in fact, happen a lot. So we had planned all kinds of training and emphasizing the importance of proper action and cleaning and all that. So we did a formative test, and this was in Japan, it was in… and,

I was just observed, because I'm not a human factors person, I'm from risk management, so I was just looking, and I noticed how one of the users, as an elderly man, totally ignored all the instructions, and with an unclean hand touched the part that was going into his belly, and I was just amazed. And he was, he was totally, like, thinking, oh, yeah, is this right? Isn't this how I'm supposed to do it? That's more than one experience.

Thank you for sharing. I think… I mean, I've… obviously, I've never seen it to that extent, but I definitely think this is where, like, thinking of all user groups, I think we mentioned on the previous slide, is so important. Just… you have to kind of, you know, take into account the different people that'll be using the device, and…

I find… I find that as… I'm an engineer, but I find as an engineer, sometimes we just cannot possibly fathom the things that people do. And this is… I mean, it's sometimes mind-boggling, and this is why we really need human factors, people, because, you know, the engineer's mind comes from a different angle. as Luke was talking about earlier, we… we are thinking about how it should be done, and in our mind, it looks just reasonable and rational, but then when you put it in the hands of the user. It's from a totally different angle, and that's why we need human factors.

Yeah, totally agree. Could not agree more. Thank you for sharing, Dijon. Does anyone else want to jump in with an example?

A comment here. So, I would like to share my experience from combination product perspective. So, the risk management sometimes needs to also consider the inactive transfer. Depending on the user, there might be Auto-injectors transfer to multiple dose injectors, so there are risks related to that, too.

Thank you for sharing.

Cute.

Sean, do we want to call on anymore, or… Should we move on?

May I speak? Sure! Thanks, Peter. One of the earlier participants, I think it was Luke, made the comment that usability testing was very expensive, but I think it's absolutely essential, because I had an absolute revelation in terms of the benefits of software usability testing. by having the opportunity to see the software usability testing lab that Rabobank had built in the Netherlands, and that was just an absolute revelation, and it's what has convinced me allowed me to develop such an interest in human factors, the importance of design and anticipating or trying

To anticipate how users will use the software in their environment.

Yeah. Thank you for sharing. I think… I know that comment caught me, caught my attention as well. I'm not wanting to spend the money up front, but I know I have definitely seen where that unfortunately backfires on an organization. They didn't want to spend the money up front, right? But then… there was a labeling issue, I think is what it was, and they ended up having to do a recall, and… The amount of money, resources that go into that. you kind of have to weigh, like, well, should we have done the human factors usability testing? Something really good to think about. There are consequences, unfortunately.

And they litter and overwhelm your already overwhelmed quality team. All right, we're gonna move on to verification, validation, and IFUs, everybody's favorite, thing. This is where we find out if the design actually works for real people, right? It gets out of the mirrors, and can it be used the way that it was intended to use, with the particular user groups? I think… I'm sure everyone here has a funny IFU story. I've definitely been in scenarios where users are working with out-of-date IFUs and trying to make a button click. to follow the IFU, and there was never a click. That was just…

the IFU was, like, two inner behind. Yes, instructions for use. I actually saw a comment, yay! This is… we're talking about instructions for use. I definitely want… again, we're gonna open up the conversation. Like we said, this is going to be interactive and collaborative. you know, we all know that IFUs can make or break safe use, and I definitely want to know, in your experience, what do you think makes the IFUs clearer? I've just… I think I recently spoke about the, the, supplemental study where a client was just testing their instructions for use, which I loved. It was really cool to see, but it was interesting to see what the participants were saying, right? Like, they wanted to see

the difference in font color. If something is, like, danger zone, like, let's make that red. And so they loved to kind of see the symbols, and they wanted, I think. some of the feedback was like, hey, make the font bigger, right? You have to think about people that maybe don't have the best eyesight, things like that, myself included. So let's hear from the chat, for things that, something that you think makes an IFU actually clear, and that maybe, in your experience. the… like, we can do YFUs a little bit better, create these IFUs so they're actually user-friendly. We'll open the floor up for Convo.

Less wording. I kind of agree, because, like, I… I don't want to sit there and read a book, like, during COVID, having to kind of, like, pick up those, you know, and you're, like, head's foggy and trying to figure… figure out how to use the device. There's so many words. I think pictures definitely help. Does anybody want to jump on and kind of speak to their… I'm seeing a lot of images, couldn't agree more. I think a lot of people are visual learners, so, like, that definitely helps. It can help you, Liz. I've written a lot of them.

Yeah, so FDA likes Over the, you know, human, like, if it's going over the counter direct for use, they need to be in the 5th grade language. It's an FDA thing. If you're going for surgeons, it needs to be written for the 8th grader, because doctors read at an 8th grade level. So we gotta keep that in mind. If it's over the use, they like pictures, it needs to be clear, written in plain, direct terms that match vocabulary mental models for the intended user. So, no regulatory jargon, no engineering shorthand, so keep it simple. Make sure you highlight the steps, if performed incorrectly, it could cause harm, so you need to have it into your usability study, so usually your user inputs follow your IFU. It's a very simple

way to write your usability study. You just follow your IFU, and there's your user needs. There you go, right, Liz? And follow a logical flow. It's a very easy way to write your risk analysis and your usability study. Use your IFU. It can marry. Yeah.

I think a very useful addition as well, is the quick reference guide. I've seen that get people out of very, very tricky situations in human factors studies. So, that's when you've got the formal IFU, and then it's condensed into something that is a bit more… it's a bit more marketing-orientated, a small little booklet, and it's just got the key points.

I find people typically go to… go to that, because it looks more user-friendly, anyway.

A quick start guide, is that what you…

It's called a QRG, so quick, yeah, quick reference guide. Yeah, and it's normally hung on the machine, if it's with a medical device. I've also seen it done with auto-injectors, and I've found they've been… it's been really, really good having that.

Yeah, I am definitely, like, a skip the long-winded instructions person, and then find the quick, like, how to do it, and then I'll struggle, and then end up reading it.

Yeah, it's defensible, it has risk control, and it protects your patients and accelerates your regulatory review at the end of the day.

Yes, very important.

loves it. It's easy, and… has your critical tasks right there, it's naturally flowable, and it's a validated practice. You're done.

S.

Done and done!

Sean, I just realized we are out of time.

That means we have another seminar for next week, right?

finish. We did… should I… Sean, are you there? Hello?

Right, yes, I'm here. I've been talking.

Sorry.

Yeah, so we're at time. Anybody that would like the slide deck so they can continue, their learning, please just write slides in the chat, and we'll make sure that you get a copy of the slides. And I want to thank everybody for showing up. A reminder that the day after Christmas, we're not gonna have a Friday in Focus call, and I don't think we're gonna have one on the 2nd, because I don't think anybody really wants one on the 2nd, unless you disagree with me. If you disagree with me, then please let me know. I, I would like to remind you that, next week we're gonna have, Tino Chao, who's gonna be explaining to all of us, no matter what we do, how to become memorable within 2 minutes, how to, how to make your,

MedTech device memorable in 2 minutes, and so he's really focused on messaging and on, standing out in a crowded room. I think that's something everyone can benefit from.

Awesome.

two important MedTech Leading Voice webinars happening next week. One on, the 18th, two days after the supposed announcement from the EU of the proposed MDR revision. This is gonna be huge. We're going to have two speakers from BSI, one speaker from Scarlett, one speaker from Accra Team, reviewing the, proposed revisions, assuming they drop. if they do not drop, they're gonna be speculating on that. So, you know, this is kind of an iffy webinar. And the other webinar is on a masterclass with Rob Packard. I believe the day before, which is going to be on how to become a lead auditor for software as a medical device. If you have any interest, in augmenting your income in 2026, I suggest tuning in to that

important and informative discussion with Rob. Again, I'd like to say that if you're working on a, on, human factors or a device, and you would like guidance from Claramid, just write guidance in the, in the thing, and somebody will reach out to you. I'm sorry that we didn't get through everything today, but, you know, this is a work in progress. We're still trying to figure out how to get all of you to come off mute mode and to…

Oh, shit.

Share your, your, your knowledge with the rest of us. I'd like to thank everybody who participated today.

Absolutely.

Liz for her willingness, and Louisa, and Leah, and Kelly, and Victoria, and everyone from Claramed for their willingness to be guinea pigs in this In this live discussion, and everyone, of course, who contributed, or even showed up, because showing up is contributing. So, on that note, I want to wish everybody a very happy holiday. And give Liz a chance to say goodbye.

Thank you all for having me and going through my, rambling. I really appreciate all the participation. This is my first webinar, so I appreciate your guys' patience. Thank you all. Have a great rest of your Friday.

Thank you, everyone.

Thank you, Lynn.

is…

Bye.

Thank you, everybody.

Bye.