Considering Human Factors In Combination Product Design And Use

In this episode of The Combination Products Handbook: The Series, host Tom von Gunden discusses Chapter 7 on human factors engineering (HFE) from The Combination Products Handbook: A Practical Guide for Combination Products and Other Combined Use Systems (CRC Press) with the chapter’s co-authors. Handbook editor Susan Neadle and human factors experts Shannon Hoste and Stephanie Canfield share with Tom their perspectives on device usability, design validation, risk analysis, patient safety, regulatory considerations, and post-market change control.

Purchase your copy today!

The Combination Products Handbook: A Practical Guide for Combination Products and Other Combined Use Systems Edited by Susan W.B. Neadle, CRC Press, 2023

Episode Transcript

Tom von Gunden, Chief Editor, Drug Delivery Leader:

Welcome to another episode of The Combination Products Handbook: The Series, a chapter-by-chapter walkthrough of The Combination Products Handbook: A Practical Guide. My name is Tom von Gunden, Chief Editor of Drug Delivery Leader and your host for this series. Today we're going to discuss Chapter 7, entitled, “Human Factors Engineering in the Design, Development, and Lifecycle of Combination Products.” For that discussion of Chapter 7, I am joined by chapter coauthors Stephanie Canfield, Shannon Hoste, and the handbook’s editor, Susan Neadle.

Welcome, Stephanie. Welcome, Shannon. Welcome, Susan.

Let’s start where we often do in this series by talking about why this topic is positioned where it is in this book. Chapter 7 on human factors engineering follows Chapter 6 about combination products risk management. Why that sequence at this particular moment in the emergence of and trajectory of the book?

Susan Neadle:

I'll add that Chapter 5 is about integrated product development. Chapters 5, 6, and 7 are very tightly interrelated because everything that you do when it comes to building your combination products and designing them is tied to managing risk. One of those core concepts in risk is, if there's harm that could happen to somebody, what do I do to prevent that harm or to, hopefully, minimize the possibility or the severity of that harm? Throughout the integrated development chapter, you're talking about how you're robustly developing your product design to be able to manage through that. The risk management chapter is going through some of the key terminology associated with that risk and how to manage it and the control strategies.

One of those core things that comes into play for combination products is that everybody is focused on making sure that the drug works the way it’s supposed to. Everybody is focused on making sure that the device is going to administer the product the way it's supposed to. From there, you want to make sure that the drug and device work together effectively. That's most of what your risk management is focused on. But then if the user who is intended to use that product can't use it, it doesn't matter if the drug works, it doesn't matter if the device works, it doesn't matter if they work together, if the user can't use the interface, interpret it properly, and be able to apply that in delivering their drug. The product itself could be safe and effective, and you could have predictable misuses associated with it. That sequence of development, risk management, and human factors was quite intentional in the book because risk management and human factors are foundational when it comes to combination products.

Thank you, Susan. Stephanie or Shannon, anything you want to add to the high-level overview about the significance of human factors in the context of combination product development?

Shannon Hoste: It’s integrated with risk management. We could add a few more commas to the title of this chapter because human factors is also referred to as usability. Human factors engineering and usability engineering. In Europe, it's more often called ergonomics. All of it is the study of how humans and technology interface and work together. In our industry -- combination products, pharmaceuticals  -- it’s a safety lens. When we're talking about human factors usability, we're talking about the safety aspect of the use of that product -- what can go wrong and what harms that can cause -- whether that harm is a missed dose, overdose, or some other physical type of harm. It is focused on that. Usability can be thought about as a broader term, talking about patent preference and other things. When we're talking about it in this space, especially when we're talking about the regulatory perspective, we're talking about that safety piece. It is a thread in the risk management process. It's not separate. It's part of it.

Neadle: It’s also a core part of the design validation activities when it comes to your combination products. It's not all the design validation activities, but it's a core part of it.

Stephanie Canfield: Exactly. It is commonly misstated that they are equivalent, that human factors validation is design validation. I look at it as the square and rectangle. Not all rectangles are squares, but all squares are rectangles. All of your human factors validation is design validation, but not all of your design validation is done by human factors.

Thank you all for that. I'm going to walk our audience through what they can expect to see in the chapter. Next up, there's a series of sections, starting with risk management and moving into human factors data, and then a commentary about the regulatory process. Thinking of that stretch where we touch on risk management, data, and regulatory, anything that you want to add about the significance of those pieces and what readers should pay attention to as they dive in and go through those sections?

Hoste: From the regulatory perspective, we're talking about combination products. If we're talking strictly FDA, from the device constituent part, there are expectations for human factors. From the drug or biologic constituent, there are expectations for human factors. There are slightly different perspectives between the CDRH [Center for Devices and Radiological Health] and the FDA. What they're looking for in that data can vary a little bit. In CDRH, the core of human factors is identifying those critical tasks of use and then evaluating and making sure that you're supporting the user effectively for all of those tasks. A critical task is a task that, from a device standpoint, could lead to serious harm. Serious harm would be a reportable adverse event. When you move over into the drug and biologics side in combination products, you're looking at a critical task being a harm. That harm could be compromised medical care. It could be medication error. It’s a little bit broader of a spectrum, away from the serious harm that comes from the device side. From a regulatory perspective, when you're looking at your product, you need to understand what level of information you need to generate.

Now, you should be generating all of this because you'll need it for your product development and to develop a robust product that you know your users can use. What you need to compile to submit to a regulatory agency is what can vary a little bit. When you're planning your strategies, you want to make sure that you're accounting for that, and that you have all the information you need for the pathway that you're going through.

Canfield: That’s where your risk management program so closely aligns with your human factors program because you're using your risk management program and your risk process to define what those critical tasks are that you then need to create the data to use in your submission.

Neadle: Another aspect of that is the Use-Related Risk Analysis [URRA], which I have a problem with the name because it's technically a hazard harm analysis, but they [FDA] call it a use-related risk analysis. The hazard harm analysis that you're doing for the potential harms that could occur because of the user interacting with that device/combination product, labeling and packaging, those are all really critical. The fact that they call it use-related risk analysis, regardless of whether it's a hazard harm analysis or not, risk is a core part of it. The same way that you're putting control strategies in place to address temperature or vibration issues impacting the quality of the product as you're designing the production process, designing the device, and preventing interactions between the drug and the device, you're having to do the exact same level of thinking and thoroughness to put appropriate controls into that user interface. That becomes a bigger challenge; many companies use “platform approaches,” where they're trying to use the “same” device constituent part for multiple drug delivery options. Because they're trying to use the same device, what does that mean about that user interface? Depending on who the intended users are, the intended uses, and the intended use environment, will the labeling, packaging, and configuration be acceptable? Shannon, I know that we've had lots of great conversations and built that into the book to help people understand that even with a platform concept, you cannot ignore the fact that you've got unique considerations associated with that intended use population.

Hoste: I'll head down a little bit of a rabbit hole here, so bear with me. When I started working in medical device/combination product development – it was before the combination product was defined – I was working in device development and mechanical engineering, so I had a very specific lens into device development. I could do a DFMEA [design failure mode and effect analysis]. I could work with my process folks and do a PFMEA [process failure mode and effects analysis] on how it was going to be manufactured. I could understand what could go wrong with the product itself.

When I started seeing field failures, I started running into a wall because the field failures were happening because of use errors. They were happening because of the user trying to use the product and making adaptations to the product so that they could use it effectively, which caused problems. First, I was a bit paralyzed by that because I was thinking, how do I understand risk and how do I understand design when I don't know what people are going to do with my product once it's out there? People could do anything with it. But human factors gives you a systematic way to think about your product and your users so that you can go through and systematically break down the use steps and understand what each of those are and how users might perform in that moment given the environment they're in.

From a systems engineering perspective, rather than just looking at my system of the product itself, I'm stretching those boundaries and including the users in that. I'm looking at that interaction flow between the two. Where that's powerful is that, one, it's not insurmountable. There's a lot of scientific research and study of how people and technology work together. Two, you have a framework of understanding and breaking it down, just like if you were breaking down how to make a recipe. That framework, that scientific practice, is true regardless of if you're making an autoinjector or if you're making software as a medical device or if you're making robotic surgery. It's the same idea, which is that you're going in and systematically breaking down and understanding those interactions and taking into account what could go wrong.

That’s what we get into in some of the case studies. They may be different products and different from what people are specifically doing. They may be working with autoinjectors, prefilled syringes, or software as a medical device. But the idea behind those case studies was to bring up different considerations in cases where, at the end of the day, you come back to the risk, you come back to understanding those users and breaking that down, and then systematically walking through the process to understand potential harms and design to support the users. Regardless of the condition or the application, it's always coming back to that same foundation.

I'm glad you mentioned the case studies. I should point out to our audience, and hopefully readers of the book, that the latter part of the chapter is taken up with a series of in-depth case studies. I'd like to stay on that for a little bit. What I noticed is that when you have a series of 5 or 7 case studies, it's clearly not a one-size-fits-all illustration where Case Study #3 just elaborates on the same thing that Case Study #1 does. Each is a different take on human factors as it plays out in the real world. Does anybody want to comment on that range, the differences, and why one-size-fits-all can't work?

Canfield: When we were putting together these case studies, we were trying to think of common examples that we have seen or heard about in the industry and come up with different devices or scenarios where you might see them. We didn't talk about always going from a prefilled syringe to an autoinjector, which is a common jump that a lot of pharmaceutical companies will make. We tried to present different scenarios where people might not think about human factors when they are making some of these changes and really encouraging and writing them up so that people can try and pull whatever information they can based on what their product is and any changes they're making. Any time you make any changes to the user interface, whether it's the device itself, the labeling, or the packaging, you need to look into how that impacts the user and take that back to the risk profile. That’s how we came up with these case studies by trying to get a broad scope of products that could be applied to multiple products at the same time.

Neadle: That was also us trying to help people understand that human factors is tied into your change control, post-market. It’s something that you're thinking about pre-market. It's integral to all the product development activities that you're doing, but it's also something that plays a key role post-market where, to that point about going from a prefilled syringe configuration to an autoinjector, or deciding to use connected health on that combination product that wasn’t used in the beginning because of speed to market -- but now, that product is out there and I want to make this change. What do I need to take into account? Human factors can be something that gets pulled in as a result of customer complaints. It can be a solution to CAPAs [Corrective and Preventive Actions] or because of a post-market configuration change. There are a lot of things that will trigger you to have to revisit that human factors process over the product's lifecycle. It's part of why, when we looked at the book’s order, I placed it just before the lifecycle management chapter because it ties to that as well.

Hoste: I'm going back to my engineering examples because that’s the way I’m wired. When you're developing a product, specifically on the device side, you're developing a physical product. You're going to have materials scientists involved or mechanical engineers. You're going to have your process engineers working on the manufacturing equipment and process for developing and creating that product. You're going to have those experts in the room as you're designing it. You're going to have those experts in the room when any issues come up and when you're making changes. You're not going to make a material change without figuring out what that impacts. Your human factors team supporting your product are basically representing the user in that situation.

Your mechanical engineers are representing how you're designing your product. Your process engineers are representing how you're manufacturing your product. And your medical officers are evaluating the clinical effect of that product. Human factors folks are representing how that user is using that product and what could be causing them trouble and confusion, whether it's in the design or when a change is being made and the product is being adapted. Changes like, if an autoinjector dials up and the torque changes on the dial-up, is that going to affect users? Do they have arthritis? Could that be too hard for them now? It depends. I need to understand all of that. That’s what the human factors folks bring in. They bring in that lens of, what are the users facing and how does what those users are doing impact what is okay and what needs to be evaluated on your product?

Thank you for that. I'll move into the final stretch of the conversation. If viewers of this conversation, who ultimately become readers of the chapter if they haven't already, come away with some foundational concepts presented there, what would you hope that they are better prepared to do as they move into the future of whatever human factors considerations will enter their worlds, whether it's near term or further out? What kind of preparedness would you hope this chapter provides for those folks?

Canfield: I personally would hope people would see that human factors is not that final checkbox before you're doing your regulatory submission. It is something that is supposed to be done alongside product development and started early on. It is not just hoping that the product that was designed works for the users, which is unfortunately something that is commonly seen in the industry. With a lot of drug delivery devices already existing, many companies will just go with the popular one or one that works for their product and hope it works for their users. That’s not quite the way that it should be done. I hope that is something that readers get out of this.

Hoste: I agree, Stephanie, and I'll add on something different. I'll think about the changes and understanding, when you are making changes to a product, how to systematically step back and think about whether there is an impact on human factors. If so, do I need more data or do I have enough data already? Use human factors as an input into changes that are being made.

Neadle: I'll iterate everything that you all said. I agree. That chapter was written in a way that it wouldn't go stale, even with changes that have come about. The FDA has come out with their URRA [use-related risk analysis] guidance for drugs and for combination products. They've also come out with an update on the Combination Product Q&A for Human Factors. The reality is that the information in the chapter still holds. What's unique is this concept of combination product critical tasks, which just reinforces what we said. Combination product critical tasks are not solely based on the severity of harm and the harm that occurs, but rather the hazards that could happen, or potential sources of harm or hazards. What are those potential sources of harm that could come from interacting with that product? How do I prevent somebody from being exposed to those?

I always refer to this as puzzle pieces, and I can't complete my puzzle if I haven't got the human being taken care of in that puzzle. This whole product has to be used by somebody, and by making sure that you're doing a robust job with your human factors considerations for combination products, it makes that puzzle fit together really well, hopefully giving a robust outcome at the back end for the people that are using that product.

Hoste: One more thing I want to add is the way that human factors data augments your clinical. You have your clinical data showing that, in this case, your drug performed as you intended it to and you’re defining all of your parameters around that product profile. In that clinical situation, if I'm going out and it's now lay users using my product, the human factors data bridges to that. It tells you how that user is going to use that product and where they might have challenges. You can then evaluate how that ties back into the clinical data. If the clinical data is evaluating the angle in which you're injecting, are users able to inject at that specific angle? It’s providing you that extra information to know whether people can use your product effectively.

Stephanie, Shannon, and Susan, I want to thank you for joining me for this conversation about Chapter 7. I want to thank our audience for joining us here. We'll see you here again for the next episode of The Combination Products Handbook: The Series.