How Risk Underpins Drug Delivery Development With Suttons Creek's Alex Spivak

Videocast host Tom von Gunden and Suttons Creek Principal Consultant Alex Spivak discuss the foundational importance of risk management in the development of a device-delivered drug product. Tracing the product development lifecycle, they illuminate key inflection points, such as user requirements, hazards analysis, design inputs, design freeze, and design verification testing. They also discuss key regulatory guidance, including 21 CFR Part 4 for combination products.

Episode Transcript

Tom von Gunden, Chief Editor, Drug Delivery Leader:

Welcome to another episode of Sit and Deliver. My name is Tom von Gunden, Chief Editor at Drug Delivery Leader and your host for the series. Today, I'm pleased to be joined by Alex Spivak, who is Principal Consultant at combination product and drug delivery consultancy Suttons Creek.

Welcome, Alex.

Alex Spivak, Principal Consultant, Suttons Creek:

Thanks for having me. I appreciate it.

Well, it's my pleasure to have you here. So, let's go ahead and dive in.

Alex, as you know, when we prepared for this conversation, we thought that a good focus area would be risk and patient safety, and where those considerations come

into play in drug product development, and, of course, the alignment with drug delivery methods. So that's what we're going to talk about.

Something that you said in that exploratory call we had has intrigued me, and I wanted to start there. I'm going to quote you, actually, or nearly quote you. You said, very close to this, or exactly this: “Risk is like the beating heart of the entire development process.”

Interesting. Would you want to flesh that out a bit?

Sure. So, the way I look at development of combination products, or even medical devices, which is a little bit of my background as well: All of this ties back to, how are we going to help a patient? And that, in turn, means, what are the risks involved with what we're doing here? That can be something like how you're using a particular product or what user is going to use it.

Unfortunately, if you're in the world of engineering, you'll know sometimes things may not work. We try to do everything in our power to make sure it does work as well as we possibly can. But in the event that something doesn't work, what is the risk of what's going to happen in the end, whether it be to the user, or the person maybe manufacturing the device, or anything like that?

So, the way you understand risk for this entire process is going to be present throughout the entire thing, from the very first early concept all the way to commercial manufacturing.

Gotcha. Let's go ahead and dive in then. And by the way, you can use as examples, if you need to use example, any kind of delivery device or method or route of administration that comes to mind. But for our audience, I wanted to set the context that we're most likely going to be thinking of things like injection-  or infusion-based devices:  autoinjectors, prefilled syringes, combination products, which you mentioned, perhaps implants or pumps — things like that. We're not likely going to be thinking about oral formulations or biologics-based platforms. So, “true,” so to speak, delivery devices. Would you say that's likely what people should be envisioning as they hear us talk?

Yes, absolutely, and especially when it comes to the 21 CFR Part 4 compliance, which kind of governs a lot of this. Risk management is definitely a huge part of that.

Yes, that sets the frame a little bit more. So, we are thinking about the entire product development lifecycle. But I'm going to start you off where I think of drug delivery picking up for our coverage here on Drug Delivery Leader. And that is post drug discovery, so to speak. The stage where a lead molecule has been identified, and now we're either in or moving into considerations around formulation and dosing. And then soon enough, if not already, the alignment with decisions around which route of administration or delivery method might get this thing into a patient's body, effectively and, as we're talking about today, safely.

So, folks in the audience, and then for you, Alex: If we can think about those early moments of formulation and delivery alignment, what are the considerations around risk and patient safety that, if they're not front of mind, should begin to become front of mind, even that early?

Yeah, totally. So, when it comes to the traditional development process of the device constituent of this combination product of device and drug, there is a typical design controls process from, once again, the early start all the way until the end, whether that be clinical or commercial.

And that early phase of planning is usually when a drug company will start reaching out to a place like Suttons Creek, for example. So, to your point, they'll have the drug mostly there, or they're getting ready for clinical trials. So, they have that, I'm going to say, fairly locked down.

Obviously, all kinds of things can happen in between. But they're starting to [say], okay, we now want to get this into a patient, so what do we need to do?

And so, right off the bat [there] can be multiple different pathways you can take. To your point, you have prefilled syringes, autoinjectors, on-body injectors. And even within that, there are probably dozens and dozens of companies that the people listening here have seen. If you go to a conference, for example, you'll see a lot of those types of vendors saying they have a particular injector, or whatever.

The thing is, as nice as it would be to say, give me the sleekest, coolest, nicest thing you have, does that even make sense for what your situation is?

You could, of course, talk about the economics of it. If you're a startup, do you have all the money in the world to do something super expensive, like a really fancy autoinjector? Or are you going to be okay with something that's a little bit simpler, in terms of either a prefilled syringe or — for people who don't know —a combination product can literally just be a vial and syringe separately that happen to be co-packaged together. Maybe for your financial situation, it could make sense.

But then, if you flip to the actual patient thing aspect of this, which is the risk and what is going to be used with a patient, that ideally should be what you should be focusing on more, hopefully, over just the pure financial aspect.

But when you're planning for that in that early phase, you have to understand, well, what is your patient population? How are they going to use it? Are the users themselves going to do it? Or are they going to have a healthcare provider do it for them? All of those kinds of questions need to be, at least, preliminarily answered for what you want to select because you could take this in about a dozen different ways.

So, I'll stop there for just a second. Hopefully, that gives you a rough idea of my personal process.

Yes, and we're going to come back to some of those things you talked about in terms of user populations and settings and that sort of thing in more detail later.

Tell me if you think this is appropriate to put this out there as part of the frame, too.

And I'll invite you to make these distinctions if you feel they need to be made along the way. But I'm also thinking about the difference between the choices you might make to get something into the clinic versus what you might ultimately attempt to take into a commercialized product.

You mentioned, for example, something could be as — quote unquote  — ‘simple’ as a vial and syringe. Maybe that's something you take to get through the clinical and early regulatory processes. But maybe you eventually, ultimately try to do something else with it, like get it into an autoinjector.

I don't know if you're going to make those distinctions, and it's not an obligation, Alex. But that comes to my mind, too — that these decisions we're talking about in terms of risk and patient safety could evolve, even in terms of the administration method or device.

One hundred percent. One of the most common things that we have actually helped people with is something called a bridging study, which is essentially taking — and it doesn't have to be purely for a financial reason, either, to be clear. It could be for a whole host of reasons. But you might want to start with something relatively simple, just so you can really get to the core of, is the drug doing what it needs to do early on?

And assuming you're good; your clinical trials are solid; and you're very comfortable with it: yes you might say, okay, let's now get to the more ease-of-use aspect of the usability and human factors of putting it in an autoinjector or something like that later on.

The caveat there is, if you're wanting to do something like that, you really have to have strong rationale for why the mechanism of delivery, even though that's changing, are you still going to have the same intended therapeutic and clinical effect? That’s not going to change just because you're changing the mechanism.

And that's a whole fun rabbit hole you can go down to right there. But, yes, one hundred percent that's a very valid thing we consider, too.

Okay, great, yep.

So, back to where you paused a few moments ago: Let's home in on the risk and safety components of the decisions around formulation and dosing as they might relate to the device that it's going to go into. Even around just the drug product itself, what needs to start to come to mind?

Yes, so one of the things you do early on in the planning phase —but it can also be a little bit after that in what's called the design inputs phase — is understanding the different failure modes and what can happen. One of the very first processes and risks that you're going to be working on is something called a hazards analysis. Or sometimes it could be a preliminary hazard analysis, something to that effect, where you're trying to understand what are the hazardous situations that could occur if something were to go wrong.

And it's quite literally a list of everything that can go wrong. And I've been a part of teams where that exercise alone could take days, if not weeks, not because we're slow, but because we're trying to plan for all these different eventualities of what could theoretically happen.

And then the downstream effect of that is, okay, if they happen, how do you mitigate that to where it's still going to be potentially okay, or there's a fail-safe kind of state in a particular device where it's not going to harm the patient?

Or, in certain cases, if we're getting into things like overdoses of drugs and things like that, that's not so much a device issue, per se, that's just the drug. If there's too much of it in the body, what could happen?

And then you have to start getting into things like warnings that you place in the IFU, or contraindications, or all these different downstream controls and mitigations and warnings that come as a result of that. But if you are coming back to my comment earlier of where things start in that planning phase, it all comes back to that very first analysis of what could happen.

And that conversation is a very cross-functional conversation. So, even though, like me, for example, as the engineer, I might be quote unquote, ‘leading’ that effort just to get everything written down, that meeting, or series of meetings, will be attended by people in regulatory, clinical, manufacturing — everybody who is involved — because risks happen in different ways across the development and design and manufacturing of a product.

Risks can unfortunately come from anywhere. So, it's all about understanding, are you capturing them early on? And that sets that foundation for all these further tasks that happen after that.

Gotcha. And so then as the product development process continues through its trajectory and evolution, moving out of the early formulation and dosing alignment with a device, or at least the initial device thinking: You mentioned design and manufacture and so forth.

What are some of the additional key inflection points where, to borrow your initial analogy, that beating heart of risk —  if it isn't heard very loudly, it probably should be heard loudly? What are some of the key places where we're at an inflection point or a decision point [about] risk and safety , let's take another look? What are some of those places that you could illustrate?

Yes. So, one of the pivotal moments that happens in any development program is something called design freeze. And as the name implies, the design of whatever you're making is frozen, in theory, where you're not making different changes to the mechanism of the injection or how much drug you're putting in or anything relating to the design. Manufacturing does come a little bit later, in parallel, but the design freeze is critical because if anything were to change after that, that then affects how you're going to be testing it and what conclusions you're drawing.

So, think about, if you had an iPhone today versus another iPhone tomorrow, well, there are probably some feature changes. In theory, it's still an iPhone, but what has changed in between those different versions? Anytime you make one of those changes, it becomes a little bit more challenging to say, oh, it's the same as it always was.

So, in theory, if you have a design freeze and you're good, that's when you start something called design verification testing. And that testing is, once again, heavily based off of those risk decisions. So, something that's a little bit more near and dear to my beating heart is statistics, along with risk management. And statistics and risk go hand in hand a lot, especially when it comes to design verification because you're basing all your sampling plans off of what the risks are that you set early on.

And so, if you look at things like your FMEAs or URRAs, for example, you'll see a lot of that information. Typically, you have severity scales [such as] 1 to 5. Every company does it a little bit differently. But just for sake of conversation, let's say 1 to 5. And each of those severity levels that are tied to risks means you're going to be testing things to

either higher or lower severity, depending on the situation of whatever the tests are. And each of those risks has its own statistical probabilities and thresholds and confidence levels as well.

So, to roll it back again: If your risks from the very beginning weren't set correctly, or you didn't put them on the correct side of the scale, if you will, that means when you test them … let's say you should have tested it to some higher probability, but, oh no, you missed something and accidentally tested it to a lower probability. Maybe it's not as quality or quote unquote as ‘safe’ as you maybe should have made it. And so that's a very big thing when it comes to regulatory submissions — what gets looked at in terms of testing reports. Okay, you said your risk was X. Did you test it to that risk level? And if not, why not?

I'm going to spin back to a couple of concepts that you mentioned there and broaden this into the next question. It’s something you mentioned before, and that's the user population and setting out there. So, whether it's pre-freeze or post-freeze changes or at any point along the design and verification and testing process, where do considerations [come into play] around things like who is actually going to use the device, whether that's a trained caregiver, whether it's an at-home support person, or the patient at home?

Or perhaps emergency use somewhere else? Whether it's a clinical setting or, as I said, a home setting?

[Or] the device type, whether it's an injector or a syringe, or an inhaler?

Anything around patient population characteristics related to things like age or dexterity or behavioral health? Or physical challenges, things like that?

Those very specific considerations about who the user is, where, and what characteristics they might demonstrate: Where does that come into everything you have been outlining ?

So, in theory, if this is done perfectly well from a well-structured program, it's going to be all the way back at the beginning. There's  a series of documents [with] a couple of heavy hitters in the design and development world. One of them is user requirements specification. And that's literally, what does the user require?

These are, I'll say, semi-high-level requirements of [what] the user should be wanting to do: X thing, or in X conditions, roughly X amount of time. They're not meant to be super specific engineering specifications just yet. It's literally what should the user be doing? And to be clear, a user can mean the end user, as in the patient or the caregiver or professional, whoever's giving it.

And that needs to be specified very explicitly because, once again, depending on how you write these user requirements, that changes what the next step is, which is something called design input requirements. This is where you are taking those semi-loose user needs and actually translating them into more specific engineering language that is going to be executed effectively.

So, it's partially that, but then if we get into the human factors, design validation aspects,  you have something like a task analysis that's early on. So how does a user — once again, regardless of who the user is — how do they literally, from start to finish, open the package, put the drug at room temperature for X amount of time, clean it with an alcohol swab? Things like that, all the way up to disposal [and] everything in between. That needs to be set pretty clearly early on, and that could be done over many discussions with clinicians or patient users.

When we're getting into situations like certain disease states and conditions that have been around for a while, those things are a little bit more standardized, so you don't have to reinvent the wheel every time. You still need the document, just to be clear, but you don't have to reinvent it.

But if you're dealing with a very new drug and a wildly new condition that's never been dealt with before, that can be a very challenging task to understand. What does the user actually need? Because this has never been done before.

So those early planning overview documents are, once again, critical because later in the project, you start getting into things like design validation, which is saying, is the user getting what they thought they would from the very beginning? It comes full circle at the end.

Gotcha. In this next thread, I'm not going to ask you or even invite you  to take an exhaustive run at this because we would need to do probably a seven-part series on it. It’s an obvious one, and that's the throttling all the way along as they're thinking about the regulatory pathways and considerations. You mentioned the URRA, the use-related risk analysis  you know, you mentioned the URRA, the use-related risk analysis component.

And so, not necessarily that particular guidance, but what might you point to as two or three key regulatory highlights or aspects that you'd want to put at the forefront when you're thinking about risk and patient safety as it means getting product designs through those pathways?

The ones that come to mind: I mentioned one of them earlier, which is 21 Code of Federal Regulations Part 4 — 21 CFR Part 4. That is the combination product governance. It's an interesting one because it fills the gap between the drug regulations as well as the device regulations, which historically have been very separate. They're related, but they are still separate series of guidances and regulations.

Part 4 is, I should say, the FDA, U.S.-centric lens, because this is not an outside of U.S. thing. But, within the U.S, that's the thing that bridges those two sides together, that makes sure you have everything to have both combined together. So, that's one regulation.

And then you have an update/transition to something called QMSR, or Quality Management System Regulation. And, to be clear, that goes beyond purely just

risk management in an engineering sense. That is your quality management system appropriate for all the different procedures, whether it's risk, quality assurance, your auditing — all that kind of stuff.

So those are probably two big ones for sure because prior to that, it was a little out of line with the international ISO standards. [ISO] 14971, I should mention, is another big one. But this QMSR update, at least for the FDA U.S., is a more updated compared to what it used to be. Those are some key ones that come to mind.

Good. And by the way, a bit of self-promotion here for Drug Delivery Leader: We have some Live event on-demand recordings out there that folks might want to go back and look at. Alex, you mentioned the QMSR. Well, we did a Live event on that. We also did one around the URRA, the Use-Related Risk Analysis. I'll include links so folks have additional resources for some of these concepts that we're referencing today but not going into a deep dive on.

So, back to the conversation at hand: As we're moving toward the finale of our conversation today, I have a couple things I'd like to hear from you. One would be any sort of distilled list of ‘words to the wise’ — particular things you would say if you're going to be attending to risk and patient safety along the way of drug product development and particularly the delivery aspect. What words to the wise, tips and tricks, pitfalls to avoid, that sort of thing?

So, the ones that come to mind immediately, some of which we partially touched on. First and foremost: Do you truly understand the patient population / disease state condition that you're dealing with? Because one of the things I've seen a couple of times is, especially if a company has released something before and they're now doing their next molecule, they may think, oh, we've done this a bunch of times before or one time before. So, we're just going to copy and paste what we did before.

From a certain standardization perspective of certain documents and templates and things like that, sure, I can understand that. But if your risk profile … let's say your first drug was something for, say, wet AMD, and then your next drug is muscular dystrophy? Completely different things, right? You can't copy and paste your risk management one-to-one. There are going to be clear differences there. You might use the same autoinjector, it might be the literal same device, but the risk profile could be completely different, meaning you need to have potential additional mitigations or risk controls, as an example.

So, once again, do you truly understand your patient population?

When you are then getting into the weeds of all the work you're doing, do you have the right people in the room to contribute to those risk discussions? As I mentioned before, I'm not a doctor, I'm not a clinician. I've been in plenty of operating rooms and things like that. I've talked to these people, but I'm not a medical professional. So, if I'm talking about risks, I want to make sure the right clinical development person, which a lot of companies, like drug companies, should hopefully have: Are they in the room? Are they truly contributing their expertise?

And if they  aren't sure of something, they then have to go out and find more knowledge, whether it be literature reviews or something like that. So, do you have the right people?

And then the third piece, which I guess, technically, I touched upon with the QMSR discussion, that we haven't touched too much yet is: Do you have the appropriate quality management system in place? It might be great that you have all of this technical work understood, but if your procedures aren't in place to support that work, that's a problem.

And I don't mean that just purely from a regulatory perspective, which is still needed, to be clear. Definitely make sure you're following your regulations. If you don't have somewhat of a standardized process — common aspects of how risk works, and the most important part is how that risk ties to all the other processes in your company — that can be a big pitfall as well.

So, I would say, ideally, you would have your quality management system [QMS] in place before you start your development work. But at the latest, it would be in parallel to your development work. You definitely don’t want to wait until you’re partway through design verification, and you don’t have a risk management process. That would be a bad idea. So, I highly recommend putting one in place.

Gotcha. Yes, and that recommendation about the QMS may turn out to be the answer to what I'm about to ask you as a final question. If it is, you can feel free to say, ‘What I just said.’

But if it's not, then this is the question. (And feel free to make distinctions, if there are distinctions, between large pharma that, as you referenced earlier, may have already been down some of these paths before with a particular device, perhaps they're just picking up a new indication — between those kinds of organizations and true, emerging or startup-oriented organizations. There could be a difference, perhaps there's not.

But anyway, the question is: If folks are leaving this episode thinking, that's a lot of interesting stuff, where should I start? Do you have a recommended starting point in any of the above?

Yes. So, ideally, in a perfect world, it would be to start getting your quality management system up and running, basically. I want to elaborate a bit: The development of a quality management system can be a continuous process. There are certain minimums you have to have, for sure, in a literal sense of certain procedures or processes. But it's expected that you're going to keep improving upon them over time, especially as you learn things.

Every organization has its own little quirks and differences and titles of people who are involved with things. It's totally fine to have multiple revisions of a procedure as you're going through your process. That is not a problem whatsoever. If anything, I would argue that regulators and auditors like to see that because it shows you're thinking about it, and you want to keep improving it.

So ideally, you would have that quality management system in place first. But that, in itself, obviously takes a whole load of effort. I think sometimes there can be an underestimation of just how much effort. It's not just, oh, here's a procedure, and then set it and forget it. You really have to think about what's going to make sense for your particular organization.

And so, ideally, if you have that in place: yes, you're going to have to do all your technical engineering work and molecule development, of course. But, if you knock out this first part first, the rest of that then becomes, okay, let's just focus on the technical stuff. You don't have to go back and always constantly think about setting that good foundation again.

So, ideally, quality management system first. And then, if you're past that into the technical work, it's what I was saying before: Make sure your risk discussions are happening early, and everybody is aligned.

Gotcha. Well, listen, I wasn't anticipating asking a follow-up, but I'm going to, and I hope it doesn't put you on the spot. I don't believe that it will. But I'm going to riff a bit here on your recommendation about the starting point [being] make sure you've got the quality management system in place.

Even with one in place, or one in the process of being put in place, can you point to any aspects of that process, either implementation and or execution using the system … Are there any common misstep places or blind spots or gaps, so to speak, where you [the company] may think you're doing this correctly, but you actually are very likely to miss this if you're not careful? Does anything like that come to mind?

That's a great question. I would say one — and this is such a hard one to give you a direct solution for — but it is something I see, which is, [quality management] systems will be made way too convoluted early. What I mean by that is, let's say you have a startup. It's their first molecule. They're just trying to get it out there. As much as I would love to say, hey, set this foundation that will last you for the next 100 years, that doesn't make sense. The company isn't thinking about what's happening in 100 years. They're thinking, are we going to be in business next year?

So, to be clear, what I'm not saying is ‘shortcut things.’ Definitely don't do that. But right-size your approach for what you need to do in the coming few years.

And that extends to risk management. You don't have to boil the ocean here. Make sure you hit the highlights of what's needed from a regulation standpoint but make it so it gets you what you need to do compared to some companies where, whether it's large pharma or not, I've seen situations where they made it too convoluted too early on. And now they're advanced 5, 10, 15 years, or even longer in some cases, and they have

what I'm going to call a ‘spider's web’ of procedures in every direction — that's on revision Z, that points to things that don't make sense anymore.

And it's because — coming back to actually what I was saying earlier — there wasn’t that continuous checking in on the procedures and updating and simplifying and things like that.

So, eventually, ideally, if a company is successful, they're going to get bigger. They're going to have more processes, more products, which is great. But, you always have to make sure, [you] don't start off right from the beginning making this the most convoluted, crazy process. Just right-size it for your approach. And once again, I recognize that's hard for me to say, well, you could do that by [only] doing X, Y, and Z? It's not that simple, obviously. But  it comes back to a philosophical conversation more than anything of what do we need to do for the immediate future?

Gotcha. Well, good advice on that, as you have offered all the way along. For joining me and sharing that advice and those perspectives and insights, Alex, I want to thank you. I also want to thank our audience at Drug Delivery Leader for joining for another episode of Sit and Deliver. And we'll see you next time.

About The Featured Guest

Alex Spivak, Principal Consultant at Suttons Creek, is a strategic biomedical engineer with 13 years of MedTech industry experience, specializing in solving complex R&D challenges and ensuring strict quality assurance and Compliance. Alex transforms product development through rigorous statistical analysis and process optimization, consistently delivering substantial quality enhancements and guaranteeing minimal Post Market Surveillance complaints. As the lead Quality Engineer for numerous global commercial product launches, he has successfully operated in diverse environments, from large corporations to small startups, and across multiple domestic and international locations.