Medical Devices Speaker Series 2023: De-risking and Accelerating Physiological Closed-Loop Control (PCLC) Using Model-Based Design - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 24:26
Loaded: 0.68%
Stream Type LIVE
Remaining Time 24:26
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
    Video length is 24:26

    Medical Devices Speaker Series 2023: De-risking and Accelerating Physiological Closed-Loop Control (PCLC) Using Model-Based Design

    From the series: Medical Devices Speaker Series 2023

    Lane Desborough, Nudge BG

    Developing medical devices with physiological closed-loop control (PCLC) systems presents unique challenges. Ensuring safety and efficacy while navigating complex regulatory requirements can be a daunting task. This presentation by Lane Desborough from Nudge BG explores how model-based design can help you de-risk and accelerate your development process.

    Discover how MathWorks tools can empower you to:

    • Model and simulate your closed-loop control system: Gain valuable insights into system behavior before implementation, enabling early identification and mitigation of potential risks.
    • Generate production-ready code: Automatically generate code from your model, ensuring consistency and reducing the potential for errors.
    • Perform comprehensive verification and validation: Utilize powerful testing tools to ensure your system meets all necessary safety and performance requirements.
    • Streamline documentation and regulatory compliance: Generate comprehensive documentation automatically, facilitating regulatory submissions and audits.

    This presentation was given at the 2023 MathWorks Medical Devices Speaker Series, which is a forum for researchers and industry practitioners using MATLAB® and Simulink® to showcase and discuss their state-of-the-art innovations in the areas of medical device research, prototyping, and compliance with FDA/MDR regulations for device certification.

    About the presenter:

    Lane Desborough is the founder and CEO of Nudge BG, an engineering consulting services and algorithm development company focused on modeling, simulation, and the control of physiological systems for medical product development. Before founding Nudge BG, he was a chief engineer at Medtronic Diabetes and Bigfoot Biomedical. He has been using MATLAB® and Simulink® since grad school in the early 90s. His primary focus is on automated insulin delivery to reduce the burden for millions of people living with diabetes, including his son.

    Published: 18 May 2023

    Can everybody hear me OK? I apologize. I've been sick-- not COVID-- for a week and I can't hear properly. So if you have questions, make sure you speak up, so I hear.

    So it's my pleasure to be here today. Looking forward to an interactive discussion. Before we get into the panel, I thought I would give some priming thoughts on physiologic closed-loop control.

    So what is physiologic closed-loop control? Our bodies have many self-regulating systems. And sometimes when there's disease or injury, one or more of those closed-loop systems stops working and we have to compensate for that, either manually or through the use of a medical device. By the way, all of this can be shared. It's all going to be on video. So no need to take notes.

    So as an example, premature babies sometimes don't have fully-formed surfactant on their lungs. They don't breathe properly. I was on a project recently, looking at using inspired oxygen levels to adjust the oxygen saturation as measured by a pulse oximeter. So basically closed-loop neonatal oxygenation feedback control, so that the babies get enough oxygen, but then don't get too much oxygen that they go blind.

    So there's many different examples of these physiologic closed-loop systems. The things that are probably most common are heart rate, as controlled by a pacemaker, and blood glucose, as controlled by what we now call automated insulin delivery, or what we used to call artificial pancreas. You can see that the FDA is paying attention to physiologic closed-loop control. Here's a recent guidance document draft. So this tells you how new this concept is to even our regulators, that only about a year ago did the issue a draft guidance document on how you would go about developing one of these medical devices.

    So I'll be talking-- and by the way, part of the reason I got into this was, I used to be in industrial automation. That's where I spent most of my career. And in 2009, my son was diagnosed with Type 1 diabetes, which precipitated a change to medical device development in general, and automated insulin delivery in particular.

    So for somebody with a normal functioning endocrine system, this sense, decide, act loop takes place all by itself. You don't need to worry. You just eat what you want, exercise, and do all these things, and your blood glucose stays tightly regulated.

    For somebody with Type 1 diabetes, that's not the case. You have to sense your blood glucose by pricking your finger, getting a blood glucose measurement. You need to estimate the amount of carbs that you're about to eat at a meal. Then you need to do some complex decision calculations to figure out how much insulin to give, to maintain your blood glucose in a safe range. And then you need to perform the action of delivering the insulin, typically with a syringe or an insulin pen.

    So the human is very much in that loop. They're performing these tasks of sensing, deciding, and acting. And as a result, they're carrying a huge burden. I can tell you what a burden that is for the person with diabetes, for their care partners, and for their health care professionals.

    So the premise and promise of automation is to remove some of those task burdens. So this is something I was taught in grad school 30 years ago, that the purpose of automation is to safely transfer variation from a place where it hurts to a place where it doesn't hurt as much, in order to make a human's job easier. So if you think about something like a cars cruise control, you're transferring variation of speed.

    It doesn't matter whether you're going up or down a hill, or headwind or tailwind. You just want your speed to maintain a constant. And so you're transferring that variability of speed to variability in fuel consumption. Who cares if I use a little more or less gas? I just want to drive 65. It's the same with automated insulin delivery, transferring variation from a place where it hurts, which is blood glucose, to a place where it doesn't hurt as much, which is using a little more or less insulin at any given time, in order to make the human's job easier.

    One of the consequences of this is that the human's role changes from being in the loop to being on the loop. So that has some implications. One of the implications is, it's great these rogue tasks are gone. You're no longer sensing, deciding, and acting every five minutes every time new glucose value comes in from your continuous glucose monitor. That's the good news.

    The bad news is that you now have some new tasks, that you didn't have before. You now have to supervise the automation, and you have to troubleshoot what might be going wrong with that automation, and you need to perform maintenance on these new complex devices, like a continuous glucose monitor or insulin pump. All of those tasks are quite difficult to perform, with the consequence that we now introduce some new risks and challenges.

    And we just need to look at other heavily automated industries, like commercial aviation or oil refinery control, to see what's happening as we've moved and introduced more automation. So we get into things like acts of commission-- mode confusion, loss of situational awareness, automation brittleness, task saturation. Deskilling-- you forget how to do it manually if the automation has been doing it. Automation addiction, where you are actually afraid to turn it off because you don't know what will happen. These are all the kinds of things that we just need to watch for as we

    So if that's physiologic closed-loop control, what are some of the risks and why we want to derisk them? Well, the sense, decide, act set of tasks traditionally performed by a human manually-- when you now undertake an effort to develop a medical device to perform those tasks, you're transferring the tasks, but you're also transferring the risks.

    And the FDA honestly doesn't care if you're injecting yourself with insulin, overdosing or under dosing. They actually don't care. They do care if a medical device is now doing that in a way that's unsafe. So you're transferring the risk to the medical device company and to the regulator. That's why they start to care.

    We get into new contexts of use. We've got a device, like a continuous glucose monitor, that might have been used in open loop. Now, it's got a new context of use in a closed loop What are the implications of that? We might be introducing new risks.

    We've got devices talking to each other. What about cybersecurity? What about man in the middle attacks? New requirements, new component interactions-- excuse me, just getting some water. And we might not have any evidence for this stuff.

    OK, so here's a non-exhaustive list of some of the challenges and risks associated with automation. First, on the blood glucose side, for people with Type 1 diabetes, it's a non-self-regulating system. It's not open-loop stable. It's affected by dozens of unmeasured, and likely to be unmeasurable, disturbances, things like meals, illness, stress, exercise, hormones. It's a very asymmetric loss function, or penalty, so the harm from being below target is much greater than the harm for being above target. And there are different clinical implications. So being low will kill you quickly, being high will cause long-term complications-- amputation, retinopathy, peripheral neuropathy.

    And we get into the physiology behavior, it's something like two orders of magnitude difference in gains of the system, from person to person, or from a person over their life cycle. Going through pregnancy, our insulin sensitivity changes by a factor of three. Going on a course of steroids changes about a factor of six. So you have plenty of variability in the underlying plant or system that we're trying to control, which creates a challenge, and very, very wide use conditions.

    Diabetes is non-discriminatory. It affects everybody, which means it affects every human endeavor. Anything that people do, or any place that people go, we need to be prepared to deal with that set of use conditions. Little detail-- too much insulin will kill you, not enough in insulin will kill you. it is actually a pretty difficult hormone to titrate.

    The CGM sensor, which is the input to the controller, is not perfect. It's got lots of different things that can happen to it. And so you have to be mindful of that. And then the insulin itself-- the actuator-- is a terrible actuator. We call a rapid-acting insulin. It's not rapid-acting insulin. From the time that you inject the insulin, to the time that you start to see the effect of the change on blood glucose, is about half an hour. So imagine if your car, if you pressed on the brake, it took half an hour for the speed to start to go down. It gives you a sense of the challenge of that automation task.

    When it comes to building one of these systems, we need to think about at least five emergent properties, or system properties-- safety, security, usability, reliability, supportability. Every one of those has trade-offs. You can't achieve all of them simultaneously. Speaking of trade-offs, we've got various commercial constraints, intellectual property constraints, regulatory constraints, commercial constraints. All of those need to be managed, as well, during the design process.

    And then last but not least, as we're busy developing these algorithms, the hardware may not even be available yet because those often have very long life cycles. Just to get an insulin pump takes something like 10 years to develop. CGM is about the same.

    OK, so I've talked about some of those risks from the behaviors, and hardware, and algorithms, and physiology. Then there's another whole category of risks, which are the interactive risks between these different main components of the system. So if you think of something like a continuous glucose monitor that has got some error-- it's a drift. That goes into a notification system, to generate an alarm for a human.

    The human receives that alarm. The human doesn't always respond to the alarm in the same way. Maybe they're sleeping, maybe they're busy, maybe they're just so desensitized, because of cry wolf problems, that they're ignoring them. But those alarms might trigger an action, like a cart rescue or a correction bolus, which then feeds into the physiology. And so you can see this is a complexly interactive system, where the human is still very much in the loop.

    OK, so those are some of the risks. Now, let's talk about accelerating. Why would we want to accelerate? There's some pretty big time sinks in automated insulin delivery-- I'm sorry-- physiologic closed-loop control development. The first is the algorithm design itself. It can take years to develop these algorithms-- the combination of features and settings. And like I said, the hardware may not even be available for it.

    Clinical trial evidence generation-- this is where we're talking about doing human experimentation to gather evidence of the safety and effectiveness. This typically takes years and costs millions of dollars. Once you've assembled the system, once you've assembled the evidence, then you prepare your 510(k) or your PMA and submit it to a regulator for review, that can take years. And so only after all of those major hurdles and time sucks have taken place can you get to commercial launch and start providing value to the users.

    So how does model-based design fit into this? First, what is model-based design? And we'll go through the definition here. The way I think about it is, you gather a bunch of models, you compose them into a simulator, use that simulator to inform the development of an algorithm. Once you're satisfied with the algorithm, then you use automatic code generation to develop the on-target instantiation of it. And then you launch the device.

    I love this quote from George Box-- "All models are wrong, some are useful." It's always something to keep in mind. We don't model for fun, model for some utility. What is the utility that we're seeking with any of this modeling? In school, when we're being exposed to models, they're typically used for explanation or teaching-- to explain the phenomenon. In product development or engineering, we're using models to develop valuable artifacts under tight constraints.

    So the iron triangle-- scope, schedule, cost-- pick two. How do we use models to accelerate in that constrained environment? And specifically, we're using it to predict or anticipate the system before the system is available. So again, modeling is a means not an end. As fun as it is to do, we do it for a purpose.

    Now, when we talk about models of AID systems and their constituent components, there's all sorts of different models, even things like animal models, bench models, fixtures where you drop it from a specific height to see how robust it is. That's a model.

    So I'm looking at modeling in the broad sense of anything that can be used to characterize and predict or anticipate the upper right-hand corner of that plot, where when we go to market, we're going to have multiple systems, being used by multiple people, over many years. Even something like a human clinical, pivotal trial is a model trying to anticipate what's going to happen in the postmarket. So I'm not going to talk about all those models. I'm going to focus on just the ones in this green ellipse, which are the ones that are most relevant for automated insulin delivery.

    So this is whether it's in or IEEE, or the FDA's total product life cycle, TPLC, this concept of a product goes from conception through retirement as part of the life cycle. And how can we use model-based development to inform design decisions, use it to identify and characterize and pull risk forward? How can we use it to-- how can we use models to capture knowledge in each step of this design process, from an organizational learning perspective, or for eventual sharing with the regulator? And then how do we use them to shape or inform the desired emergent properties of the system?

    So this is a non-exhaustive list of some of the ways that model-based design can be used in these different phases of a product lifecycle. And I'll just go through a couple examples and we'll see if this works here. So the first is attracting capital or justifying development.

    So when you first start a project, you don't have anything to show. It's just a gleam in your eye. So imagine if you could use simulation to, months or years before the actual system appears, give people a sense of what it's going to look like. So this may work, we'll see.

    Want to get to show one backwards.

    OK.

    Ah, perfect.

    Perfect, looks clear.

    Thanks.

    Can you bring it back? I just wanted to show that was an interactive-- you can go watch the entire video on the MathWorks website.

    There? Nope, I want to go back to the other one.

    It never really saw it playing. We didn't see it playing.

    Oh, you didn't see it play?

    No.

    Oh, sorry.

    If you click the link on it, it's probably OK.

    OK, so click on that.

    Yeah.

    John's seen this video, so he wants to. So you can see, we even simulated what the user experience might be. We're showing something on the right-hand side of the physiology individualization that's taking place over time. OK, that's fine. You can go back to the--

    The point is, you can use this for showing to prospective investors, or to employees that you might be wanting to recruit, or partners, or analysts. OK, so next possible use model based design is the very challenging part of deciding what's in or out of the product scope.

    One of the-- oops. One of the challenges faced by anybody developing products is not adding too much, adding too much complexity. This is what I've got all these gray hairs. I've been trying to deal with complexity for 25 years. And what we can use-- we can use models to help reduce that complexity.

    One of the examples of this is, let's say that your therapy varies by time of day. It does something different at night than during the day. Well, if you have some data available from an appropriate cohort, where you can learn where they typically go to bed and where they wake up, rather than have those be two configurable parameters, you can just bake that rate into the system and reduce that complexity.

    Another example is trade-offs, if you're doing design trade-offs. So here's a notional example. Let's say that you designed a notification system with the best of intent. You think, I'm going to want to make this less burdensome. It's going to be great. We're going to set alarms this way. And then you go implement that. You

    Can use a simulator to go characterize what the behavior of that system might be, over many users, and many months of operations. So let's say the base case, from your original design, is represented by the blue cohort. Then you can engage in a set of trade studies, and analyses, and tweaking, to say, well, maybe I could develop a couple of options along the Pareto frontier, one that is a more usable system and one that is a safer system, that might be more appropriate for different people who have different choices in how they want to manage their disease.

    OK, almost done here. The next possible example of the application of model-based design is in the clinic trial evaluation. So wouldn't it be nice if, before you start the clinical trial, you had some sense of what was going to happen in that clinical trial? So you can use it to inform the protocol, the design, the outcomes, the endpoints.

    So this is another example from Bigfoot Biomedical, where we did a set of simulations, and then we went into a clinical trial. And as you can see, there is very high concordance between what we said was going to happen in the trial and what actually happened in the trial. Just imagine how powerful that is. And I look forward to the day where you don't even need to do the trial, where you just use the evidence generated by the model.

    OK, almost done. Once you're satisfied with the algorithm and you want to reduce it to code, what traditionally happens is, you develop a software requirement specification, as written by the algorithm engineers. And then you transfer that over to the firmware engineers to hand code. That takes a long time and that's fraught with peril and human error. So wouldn't it be nice if you could just automatically generate the code? That's what we did at Bigfoot.

    And one of the things you could do with this is, if you choose, you can retarget it. So if your target changes, if your processor changes, or your environment changes, you don't have to go back to the very beginning. We have an example of this with Bigfoot, where our first target was this insulin pump. But we did an exploration of what happens if it ran on an Android phone, instead, and talked to a different insulin pump. And we did that in a couple of days. We were able to retarget in just a couple of days.

    OK, so the elephant in the room is that we live in a regulated industry. All of this is nice, but we live in a regulated industry. What does the FDA have to say about this? The good news is that they actually promote model. We've got tons of papers and guidances out there saying insulin comodeling is great. It's coming.

    I'm actually on a new committee, that was just formed, looking at moving this forward. They reimagined, or imagined a different submission experience. I can't wait for this day, where they say that there will be a chance to reduce, or potentially replace, human experimentation with modeling and simulation. So I look forward to that day. Unfortunately, we're not there yet.

    This is a paper that we published last fall, with some pretty recent insights into what challenges remain. And basically, it comes down to risk transfer, and humans just aren't comfortable doing things in a new way. Precedence is a pretty powerful thing in a regulated environment. So we'll get there. But I would say that the FDA's endorsement of model-based design is more aspirational at this point, but we'll get there.

    OK so in summary, there's many uses for models over a system's life cycle. We can use it to inform the design decisions. We can use it to characterize and pull risk forward. We can use models as containers to capture knowledge through the design process, or organizational And then we can use it to shape and inform the emergent properties, so that we're not surprised when they emerge, and they're not the ones we want. And the FDA is getting on board with modeling, too. Thanks.

    Up Next:

    View full series (6 Videos)

    View more related videos