Testing Software to Prove It Works: How Fully Validated Devices Ended up in 2025 Class I Recalls

Hello and welcome, everybody. Chief Friday in Focus from MedTech Leading Ways Exchange. My name is Sean Smith. We're recording this, today's webinar. And the recording goes to everyone who registered, whether you stayed for the hour or not. Today, we're looking at software verification and validation, and how it goes very, very wrong. here's what made me want to run this one. So the FDA tells every discipline inside a device company to go hunting for its blind spots. Human Factors examines how real users get it wrong, cybersecurity models, how the device could be attacked, software addresses, foreseeable misuse, invalid inputs, recovery, interoperability, covers data exchange. Every one of those teams is doing careful and serious

work, inside of its own boundary. Nobody Owns the space between them. And this industry has never been… much good at working across silos. Show… Let's see… My guest today, Chris Kelly, CEO, founder of Keystone Medical Device Partners, has spent 10 years running software testing for medical device manufacturers. He founded and sold a testing company before that, and he ran 18-month program on enterprise systems with Class III infusion pumps that went live across 6 European hospital sites.

on that program, the clinicians found the problems the engineers never thought to look for. Chris, before we get into it, two quick notes. Well, first I want to cover upcoming events, and then we're going to hop into So hopefully I can share my screen, tell you about what's coming up, And… Hopefully this will… right. Oh, so this is what's coming up. Let's see, Tuesday, September 29th, Sex Bias and medical device usability testing. September 30th, Devices Innovation, to Commercialization Phase 1. This is focused on the very, very early stage, and should be an interesting presentation. Next week,

Coming at risk from a different angle, compliant and still wrong, the human side of risk. decisions. And then the following Friday, Active Medical Devices R&D, Uruguay is closer than you think. Really interesting company out of Uruguay. How many of you can locate Uruguaya on the map? It's pretty hard. And then this special announcement. So, as many of you know, I've been, like, working on this for years, trying to figure out how to showcase experts, how to, make visible what is not visible, which is… which is expertise. And part of this program is around that. So, what we're launching, is a sprint, and this is a,

gonna be limited to 50 places. It's not gonna start until November 20th, so we're gonna take advantage of the, holiday time slowdown to focus on you and how you can make your own expertise visible, verifiable. And recognizable to the outside world. And, it's gonna be really interesting. If you'd like information about the cohort, write cohort in the chat, and I will send you a, a document about it. We're gonna launch a website soon, but in the meantime. you know, let's… let's start there. Now, I am done sharing, with the exception of one final announcement, my…

husband, Mike Nixon, has written a book, that's being published in January about Marine Corps Boot Camp. If you know a Marine. Bright Marine in the, former Marine, current Marine, write Maureen in the chat, and I'm gonna send you a link to, the Amazon page. It's being published by a real publisher, it's not self-published. He worked for 10 years on this memoir. It is the only accurate, first-hand account of Marine Corps boot camp in 1968, Vietnam era. So, if you like Full Metal Jacket, check it out. Oh, that is it for me. Chris, I'm so happy to have you here, and we've worked real hard on this presentation, together, and

You know, this is a difficult issue to frame, but what I'd like you to start with is, what if you want to be when you grew up, you know? When a little child, where were you? What were you doing?

I got really interested in model railroading since I was a little kid. I think it was because of my older brother and some uncles, but after a while, I think you could say I became obsessed with it. And you build the whole system down in the basement, you do all the carpentry work, and then you recreate, like, mountains, tunnels, all that stuff, and it just intrigued the heck out of me. And so one day, I thought I would end up becoming a railroad engineer. And, just to kind of fuel that fire, when I was about 13, there was a gentleman I had never met that was a long-time friend of my dad, who had said, because your kid's so into trains, and he was a railroad engineer, on my last run before I retire, he can go with me. So when I was about 13, I was up in Spokane, Washington, and we went out on the outskirts of town where no one could see, and there was the guy, the railroad engineer in the traditional outfit, the whole nine yards, and there was his brakeman.

And I got to ride up in the cabin from Washington all the way over to Montana. And that was just the most exciting thing I ever did as a kid. And so that was where I thought I would end up.

And yet, here you are. And he is a long-time member of the MDG group, and then, you know, now MLBX. Many of you know him. One thing I love about Chris is that he's always enthusiastic and supportive. Of everybody, so please try to be equally enthusiastic and supportive of his new venture. Tell us where you learned this method, really quickly, that you're going to share with us today.

Absolutely. About 20 years ago. I was hired as a contract QA lead for this company up in, LA. It was Innovative Merchants. And what they were doing was, at the time, they told me about 70% of all credit card transactions in North America went through their system. And they're going to do a major upgrade to the back end so they could scale. So they're changing from Microsoft SQL VB over to Oracle Java. And, and so because I had been testing for about 10 years plus at the time, figured I pretty much knew what there was to know about system testing. But I had worked with enough junior testers who, when time got short, they would go ahead and test to prove it worked. Which made me crazy. So these guys let me hire my team, and so a week before the project, they brought KPMG in for risk.

And so they walked us into this room, literally 30 to 40 people, wall-to-wall, floor-to-ceiling whiteboards, and KPMG said, okay, we're gonna show you Because this is a limited-time project, we can't test everything, so wouldn't it be nice to know where to look? And we're going to identify all the risks, the things that are hidden in the systems that weird behavior are going to expose it, and could crash systems, cause issues for the clients, and so we're going to show you how to find those and mitigate them. And honestly, Sean, that was the day my standards changed, because I realized I was wrong. I didn't know everything there was about it, but thankfully for KPMG, I learned something extremely valuable that literally changed my career.

And that's really the basis of what we're going to be talking about today, so why don't you go ahead and bring up your slides, and We have a bunch of stuff to go through, so unless it's a really urgent question, then I suggest holding questions to the end, but if you have something that you're absolutely dying to say, then, you know. Please, you know, you know how this works. Right. Shh, so let's, Let's skip to the next slide, because I want to…

Are you ready?

First poll. Okay, so…

Because we changed the order, and boy, are we… are… last one week, also climbing. This was kind of shocking. A woman, Anne Reed, was giving a presentation at a recent conference, and she's a program director at the FDA, and she produced all this information. I mean, look at that. As Anne said, I don't like these numbers, and I never will. And because I want to level set, because we're talking about Class 1 Recalls, a Class 1 recall is the most severe. It's an emergency situation where there's a reasonable probability that using or being exposed to a defective product will cause serious health consequences or death. So look at that, 232% increase from 2020 to 2025. I mean, 111 of them across the board just last year.

And so I thought it would be interesting to ask those that are watching, put in the chat, what do you think contributed to all those recalls increasing? What do you think was some of the causes?

Yeah, we were really curious about this, because we're like, so why? Why are they going up so much? Why are they going up so much? You know? Yeah, software, absolutely. That was my first guess, was like. you know, all of the unknowns around that. Why don't you move to the next slide while people, you know. Type in their opinions about whatever, you know, what it is, So, it's interesting, that the, Class 1 Recall is not a Class 1 device, you know, it's sort of the opposite order. I don't know how many of you knew this, but for me, it's kind of a revelation.

Go ahead, Chris, sorry.

Well, no, it's interesting, because when I first got into testing in the medical device world, that confused the heck out of me, because I heard class phone recall, but then you had all these different classes of the device, and it seemed like the severity was in opposition. So a Class 1 device is not a high-risk device, whereas Class 2 and Class 3, higher risk to patients, potentially. Same with the Class 1 is the highest risk, Class 3 is not. So, yeah, that threw me quite a bit when I first got involved in this, because most Class 1 recalls are in Class 2 devices. And, the recalls in this session are Class 1, which means the FDA judged that somebody could have been seriously hurt or killed.

So smooth.

Interesting responses. We're seeing software, clinical failure, WRT function. Scope creep, existing software being repurposed for new devices, applications, FDA layout, software written for on uncontrolled operating systems being disabled. Software as a medical device. Yeah, crazy. But a lot of it is, is software-related, A lot of response. Thank you for participating. Before we start, okay, so I'm gonna launch… I'm actually launching a poll this week. We're gonna try this. Poll 1, launch.

should work the same way as the chat, but, you know, just go ahead and put this in. And while you're doing that, Chris, you can move to the next slide, and if this is on your screen, you can just minimize it.

You bet. Okay, this is a fun one. Which team in your company, medical device manufacturer, is expected to sit down, invent specific failure scenarios, and then document them for the submission? And, please put your answers in the chat. Okay, let's see what people are saying. Whereas… I see a lot of carryover from the last one. Okay, I see C… Human factors, oh, a lot of A, software V and V. Software BNV… Wow, a lot of A's. D, quality group. Let's see, A… oh, a lot of A's.

All of them. Okay, A, C… A… Wow. I love it when everybody participates. A, C, A… There's your poll result.

Yeah, so why don't you read the poll result from the first poll?

So where is the product you are thinking about right now? Pre-VNV still building, 23%. NVNV right now, 18%. Already on the market, 21%. I advise companies who build them 28%, and not applicable 11%. So it seemed like the majority is either, consultants or pre-VNV Still building it. Or on the market. It seems almost equivalent.

Yeah, yeah, everybody… so we got people from the whole range. Okay. Well, thank you all for participating. There'll be one more actual poll, and then a couple more unofficial ones. But, we really wanted to take this opportunity to get as much audience feedback as possible. Because, you know, you know, full disclosure, you know, Chris is launching this new company, and we want to make sure that, you know, he's hitting the right notes. So, you know, if you have feedback for him, please feel free to share it, reach out to him, connect with him. Chris, you want to move on?

I sure do. Okay, here's your, get to talk about the cybersecurity team example. And Sean, I gotta tell you, when I went through the FDA requirements for cyber testing, I was just blown away, because they provided so many examples for them to use, like threat modeling, fuzz testing, what you see on the screen, and there's a bunch more. And the point was, they want the cyber team, and the focus has been there for years now. They want them to create scenarios to make sure that they unearth any vulnerabilities in the pump, so it doesn't get hacked, or in the system, so there's no cyber breach. But then when you,

when you look at the software BNV side, it wasn't as expansive of recommendations of what they wanted to do, so… it kind of surprised me. And here's what's interesting. We, We had a system that I'm going to describe later that went out, and we didn't have any problems with it. It ran fine, it did what it's supposed to do, but the only feedback that we got was, some of the docking stations and pumps could be vulnerable to cyber testing, to cyber hacking. And at the time, everybody… the thinking was, why would somebody want to hack a pump in a hospital? What's the point? I mean, are you going to get money out of it? I just… we weren't thinking bad actors.

So, about a month after the system was released that I was working on, they, asked me to support these guys, so I set up an area in the lab and set out all the pumps, the docking stations, and I watched these guys doing penetration testing and other stuff that I'd never even heard of. But… So, those were the only two issues that came out after that release, was cybersecurity vulnerability, some of it, and then it found out that the cleaning agents that they were using on all the pumps, because people are touching them, to sterilize it, over time, it was degrading the material on the front of the pump.

But otherwise, that was it, but the cybersecurity part was a big surprise to me. Now, as I get into these recalls, what I want to do is make sure that we understand the definitions and kind of what meets what. So, we talked earlier about Class 1 Recalls, and so you can see Class 1 and Class 2, so I'm going to read out real quick what FDA defines a Class 2 recall. It's something that a Class II Recall may cause temporary or medically reversible adverse health consequences, or the probability of serious harm is remote. Because what follows when I go through these recalls, these are illustrations of a category, not the category itself.

And I picked these because they're recent, they're public, and simple enough to walk through in 10 minutes. Oops, sorry about that. Okay, my bad. Okay, here we go. Here's the first one. A nitric oxide delivery system stops mid-therapy. What triggered it? Please put your answers in the chat. So you have a choice between power supply fault load… under load, sensor calibration, maybe someone pushing buttons. Okay, I'm seeing C… Another C, another C, B… B… A… a lot of A's. Any of those, B…

Not sure what the root cause is. A, A, B, C, C, C, A, all A. and say, boy, what a… I love it when people participate. A… B… C… A boy. Now it's all over the map. A or C? Okay, do we want to see who was right? A nurse in a hurry. I'm going to read you what the FDA stated. If users press two or more on-screen buttons in a rapid succession, it may trigger a software interruption and unexpected restart. Now, here's the kicker. Nobody did anything wrong. Because this test wasn't part of… this wasn't part of the requirements, nobody tested it.

And, also, for those that are doing the self-assessment, this recall matches question 2, the one about a clinician doing something reasonable that nobody specified. Here we go. Hey, Sean.

Okay, so, chris has prepared a 7-question self-assessment. Chris, that's on your website, isn't it?

Yes, sir.

Yeah, okay, so what is your website?

I had to think. KeystoneMedicalDevicePartners.com.

Great. So, we can drop that in the chat, but the, show… he's created the 7-question self-assessment, and if you want to book 30 minutes just to talk with him about what you're working on, please do so. And if you're in a position of advising companies, a consultant on this call. And, you're interested in talking to him about partnering opportunities, you know, him referring work to you, you referring work to him, please, put that in there as well. And we will… we will follow up with you about opportunities in… in that regard, if that makes any sense. So, yeah, that's… those are the choices, 1, 2, or 3. And…

Obviously, no responses, no response. So let's move on.

Okay, here's another recall. Fusion pump stops an active infusion What stopped the infusion? Please put your answers in the chat. Oh, wow, these guys are quick. Hospital's network settings… Network settings, A, defect in the pump firmware. A, B, or C, C, A… I think I see another A. Okay, A, A, C, C, A, and B. Yeah, this one was kind of an interesting one.

And I think it's… it surprised a few people, A or C. Okay, let's see who was right. Boom. Here's… here's the deal. Your device lives inside somebody else's network, run by people you will never meet, who change things on a Tuesday without telling you. If that is not in your test plan, it's in your recall. And by the way, if you're following the… if you've taken the self-assessment, this recall matches question 3, The one about what happens on the way back from a failure. Here's another example. If you think of, like, Cerner, where all the companies… like, if you have infusion systems running in your hospital, and I believe the Cerner data is where they do some of the billing and the EHR and other stuff, well, Cerner's had several public rollouts where they did an implementation in a hospital, and somehow Cerner's system

took the hospital down. I think one of them, it was down for 5 days, so clearly they weren't doing out-of-the-box scenario testing. But one of the things that we were focusing on on the system that I'm going to walk you through the project, where we used this process, a lot of the scenarios that we were given from the clinicians were around this. Like, okay, what happens if somebody changes this, changes that, things that we weren't thinking about when we were designing and testing the system. So a lot of the scenarios where the environment could have been a problem. the folks that work, you know, in the hospital, use these systems, gave us a lot of feedback, including some of the IT guys, so this was very helpful.

Yeah, one of… one of my clients likes to say, you know, it's not your device, it's the system around your device. That… that is… that is causing the problems, that includes the training, that includes the IFU, that includes all sorts of other things that are not the device itself. Including the users and the use environment.

Amen. Okay, so, of the scenarios in the system that we worked on, of the scenarios that later uncovered real defects, how many came from the engineers who built it? Please put them in the chat. Okay, I'm seeing A, C, C… See… get some… Okay, here we go, A, B, B, B, B, A, C… A lot of A's and B's. Wow. A lot of A's, a lot of B's.

Engineers never make mistakes. I actually worked on a project once, years ago, where the engineer that came in that I was leading the testing on, and he came in and told me to my face, well, I don't write bad code, I don't make mistakes. And so I proceeded to blow up his system over the next few days. B, B, C, A, B, C, C. Okay, now it's getting a nice blend. Well, the answer is C. Very few. And the reason being is the people who used the device in the hospital produced the scenarios that mattered. engineers know how it's supposed to work, but I'll give you an example. On the system that I worked on, it was being deployed to 6 sites in the EU, and what kind of surprised me was, they said, you have to understand, these are really old hospitals, some of them have walls made of stone, so at the time, Wi-Fi just wasn't reliable, so it was a local area network. It was all wired.

And so, when we had our scenario session, a lot of the nurses and clinical staff said, okay. How do we deal with this lack of connectivity? So they said, okay, for example, a patient comes into the ER, they get them all set up, okay, they need some help, so they have them on a gurney, they've got the pump, they're getting infusions going, there's a docking station, the doctor, everybody checks them out and says, okay, obviously I'm not a nurse or doctor, time to move them into the ICU. So we… they wheel him out to go around the corner, oop, no open beds. So now you have a patient sitting in the hallway with his docking station, his pump is infusing, and he's not connected to the network. In fact, right now, and this is what the nurses were concerned with, because we built a system that had a UI so that it…

If you were a nurse or a doctor or a clinician, and you wanted to know the status of all the pumps across all the wards in the hospitals, you could look at this dashboard. So, you want to look at this ward, you see all the pumps are running, the infusion rate, everything that's happening with the pump is being reflected. So you could quickly check all the wards to see if there's any problems or not. So the nurses wanted to know, how are we able to check that pump when it's not connected? And then, what happens if the pump goes into alarm? Because maybe it runs out of saline, or there's just some kind of an issue with it, or maybe,

they move the pump off the docking station, for whatever reason, to take it off to do something with it, and then the docking station goes an alarm. They had all these scenarios around their world that we hadn't even thought of, really, until they came in with all these scenarios. Another example is The way this system was designed, and the way it was, because of the complexity, you were allowed… the doctor could log into the, into the dashboard, and he could send a data set to the pump, which was the prescription for that patient. Maybe he wanted to change it, maybe he wanted to alter it. Well, what happens when they're off the network? Because when that patient's sitting in the hallway on that… on that gurney, and they're not connected, they don't even know where that patient is in the hospital.

Honestly, at that time. So, that was their concern. How do we track this? What happens if there's an alarm? What if the docking station has an issue? Because let's say they're sitting in the hallway longer than expected. Well, the battery backups for these docking stations and the pumps, they only last so long, so what happens if one of those runs out of a charge? I mean, we had endless scenarios from the clinicians that really helped us Solidify that system so that all of these unexpected activities didn't generate a scenario that was a risk to the patient. So, again, kudos to the clinicians, they really contributed to that project.

Okay. There we go. Now, here's where it gets fun, and this was what I faced when I, I took on this project at this major medical device company. As you can see, all these different disciplines are asked to go through, like Sean was saying, and create their own scenarios. But here is the problem I faced at this medical device company. Med tech companies are not historically good at cross-functional work, and you can see that list on the left. People work in silos, and each silo has now been told to hunt for its own blind spots. And where I was… where I was always concerned was the space between them, because it belongs to nobody.

And so here's how I looked at it. And this is the answer to the question probably everyone is privately asking, which is, why would they pay for this rather than do it themselves? And there's really 3 important reasons. One, it's a proven workflow rather than a meeting. KPMG built it for cross-functional risk identification, and it's industry agnostic. Two, an outsider running it keeps it departmentally agnostic. Nobody in the room is defending their own department's work, because the person holding the pen doesn't have one. Three, excuse me, it produces ranked, documented output that ends up as test cases, not a list of concerns.

So now let's go ahead and see how this works. Now, here's where it gets fun. Check this out. Five different guidance documents, five different, you know, isolated, pockets of people, you know, silos, and everyone is asked a single discipline, every one of these guidance documents asks a single discipline to go looking for its own blind spots, and every one of them is public, public, and current. So my question is, who's… who's bringing them all together so that nothing gets lost? And now, here's how it runs. When I was… when I started working at this medical device company, I came in… Because the company that Sean talked about that I had… I was running, I had started it the same year, because I wanted to run it on the… on the side, and eventually ended up doing it full-time. But…

I realized when they asked me to be the system test lead for this project, because of the size of it, so you have this dashboard that was built in one country, and it's supposed to interact with all these systems, so here's this dashboard for hospitals in Europe that could have up to 5,000 pumps across the hospital. sitting on approximately 500 docking stations, and that all has to connect. You need to be able to go through that entire dashboard. and look at the status of every ward, and not have any connectivity issues. And so, because this was complex and high risk, I went and sat down with the director.

And, told him I wanted to show him something. So on his whiteboard, I walked him through this entire process, and asked what he thought. And he said, you're doing that. Because he said, I haven't seen that in this industry, and it's gonna make all the difference in the world. So… what I had asked him for was, I said, the only way this is going to work is everybody in the company that's working on this project, I need all of them in the room at the same time to do these scenarios, because if you miss anybody, say a tech writer who knows what the IFUs are supposed to look like. or tech support. They know all the issues that have come in. Or you have the hardware testers, or you have the folks in clinical, usability, etc. And then you have the marketing team, program management, software engineers, everybody that's in the company that's going to touch this system, either while we're building it or afterwards, they need to be in that room.

So… And he totally agreed, so that was kind of nice. That was a big boost for me. So to start this out, the way this process works, and again, this is not me being a genius, this is KPMGMG's genius, and God bless them for doing this. You have to do your homework. You can't just walk in sight unseen and start doing this because you don't know what you're doing. So you have to do your homework. So you start with the recall database, and you look at all the systems that are similar to what you're going to test. What did they miss? What are the critical defects? How did they slip through? What was the weird environment that caused it? You need to know all that, right? Then you have the company's defect management system.

That way, you can see, and you've got to do your homework, all the defects that they've experienced on products that they've built. What was the trend? What did they keep missing? What wasn't tested enough? And did they not end up… were they… was there a lack of skill sets, lack of tools? There's got to be reasons for it. Then you're going to want to, for me, I want to talk to the clinicians, the folks that are actually going to use this system in the hospital setting, because they're the ones that are going to know what happens that the folks, you know. over at the company building these things aren't quite privy to. And then, of course, the IT staff at the hospital who run it, because you want to know what they might do that you hadn't thought of. Like, maybe they're going to do a backup at night, and it might mess up their system. You need to be ready to test for all that.

So… When we had all of that mapped out. Then I was allowed to have that entire team, there's about 40 people, and we had a room set up, a giant room, wall-to-wall, floor-to-ceiling whiteboards, just like KPMG did. So I've got all these people sitting in this room, there's about 40 of them, wondering why they're there. And it was tech support, tech writers, everybody was there. And so… I walked them through the path, the process, and I told them, the way this works is, first, we have to go through the PRD for the system that you're going to build and eventually implement, all the critical paths.

So, what are the workflows that absolutely have to work? Which, interfaces have to work, and all the dependencies that support them? Everything in the system that cannot fail, those are the critical paths. like, for example, the font color in the help section. Who cares, right? We didn't want to waste time on things that didn't produce the ROI we were looking for. So, as we started going through the PRD and working out the critical paths. What was interesting was, we started getting push… we were getting comments. I could hear back and forth, because I was at the whiteboard going through my part, and I could hear the folks on the clinical talking to the engineers, and they were talking to marketing.

And at one point, as we mapped the critical paths for not only the system, but also the medical devices, and how they're supposed to operate, I remember writing, and I heard somebody, one of the developers go, oh my god. And everybody stopped and looked at him, and he was talking to marketing, and they were going back and forth, and he said, I had no idea. When I read that requirement, I thought you meant A, right? And now I'm hearing from the nurses and the clinical staff, you meant C. Right there. Do you know how many defects we killed right there, just from that information they just shared? That alone made that meeting important, right?

So, once all the workflows, interfaces, all that's mapped out, now you're going to have to show them how they're going to break it, right? So now we go through each section, and you generate scenarios. Now, because I had done my homework, I put several trial scenarios up there to get them started. And, if any of you remember. being in grade school, and the teacher said, you know, I'm dating myself, who wants to come up and write on the chalkboard? You had 3 or 4 kids that always wanted to go up and be this… either the attention, or they wanted to show how much they knew. scenario sessions are not much different. People tend to compete. So, as somebody from the engineering team started giving more scenarios, and I'm writing as fast as I can, somebody from usability would go, oh, what about that? And then we had tech support, and it went around the room, and the rule was, everybody has to contribute 20 scenarios.

And about halfway through, we had far exceeded that, because as you… it's like a relational kind of thing. You see something, and it reminds you of something else. So we had follow-on and follow-on sub-scenarios and sub-scenarios. And it was a 6-hour session, and we divided it 3 hours break, 3 hours, because we have two phases. So once we went through and exhausted everybody's patience and got as many scenarios as we could, I sent them on a break, and then on the far right wall, we had written… we had a table sitting there. It was a 4-quadrant table. And for those of you that have an FMEA background, this will seem very familiar.

Upper left quadrant. High impact, high probability, Below that, high impact, low probability. Upper right. low impact, high probability, and then, of course, below that, low impact, low probability. And while I had been writing up all the scenarios, and eventually everybody was writing scenarios, I had asked somebody to do me a favor and follow through, and just go through and number all the scenarios where we're going. Because this is where it's going to come into play. So they all came back from the break, and they're looking at all the scenarios on this board, and I remember somebody saying, there's no way we have time to test all that. That's insane.

And I said. Thank you for the segue, and that's when we went into the prioritization. So then we started going through the scenarios, and I gave some examples. Okay, I want to ask the nurses, if somebody does this with the pump, what are the chances that a nurse is going to do that, right? Because they're trying to force a bolus to save someone's life. And they're like, all the time, okay, if they do that, and it causes this, what's the impact? Oh, I think it would kill the pump. And those were the types of scenarios we went through. And that's how we prioritized it. So as And of course, took a picture of the whiteboard, but as the scenarios were being prioritized, they were taken off the board, so everybody could see progress. So by the time the board was empty, we had all the high-risk items that we cared about.

And then they asked me, okay, so now what do we do? So I told them, we're gonna take myself and the test team, and there were other people, like, from usability, tech writers, tech support, that wanted to contribute to writing the test cases, which was great, because I didn't expect that. I told them, we're going to do only the high impact, high and low probability, because again, we don't have that much time. Everything else that's low impact, for the most part, is covered by requirements-based testing and some of the risk testing, and some of the ad hoc. And if it isn't, we'll bring it over. And so that allowed me and the test team and everybody that wanted to contribute to go off and write these test cases for the next several weeks. Now, here's where it gets fun.

about week one, and then week two, and then week three, I was getting emails from mostly usability, some from tech support, some from the engineers, saying, by the way, I thought of this, and I thought of this, and I thought of this, and we continued to get scenarios for about a month and a half, and I can't tell you how much that helped. One of the biggest yields that we received was the performance testing. Because… We were… there was a side of the company that went ahead and built this simulation system that was simulating 5,000 docking pumps. you know, sending, you know, infusion data to the system, and then the system sending in data sets back, and more. And because I didn't want to rely just on simulation, I worked a deal with the rest of the company, because they had docking stations and pumps throughout the company already from other projects, and so I had available on any given Saturday about 30 to 50 docking stations filled with pumps.

And so, for about 3 months, about every Saturday, we would get there at 7 in the morning, and we'd be there till about 7 or 8 at night, and then I'd spend a couple hours writing the reports. And we were going through all the tests that were all about the performance testing. So, for example, if there's a whole series of pumps and docking stations in a ward, and the alarms go off, and then you have to move someone from one to another, and there's these connect-disconnect issues, and on and on, and most of those scenarios came from from clinical, we spent months running those tests on the weekends, because you'd have the docking station running out of power, or you'd have pumps,

having a little power surge, because you took it off one docking station to another, and you wanted to make sure that that data was following where the pump was. And so, all of that performance testing, a good majority of that came from the clinical staff. And so from there, we were able to build the negative tests, and that was what allowed us to To basically deliver a clean system. And the beauty is, you only have to do this once. After that, you know where to look. Somebody in the room asked me afterwards, they said, well, what happens if we have a system out there on market, it's running, it's working, everything's fine, and now they got the customers that, you know, they want the bells and whistles. What about this feature? What about that feature? How do we re-verify and validate the system

after we make changes. And so, KPMG was way ahead on that, and they gave me some tips on how to minimize the amount of work you have to do around changes to make sure nothing escapes to the system, and I'll be happy to share that with folks that want to reach out to me afterwards, one-on-one. Boom. this is the fun part, and this is something that Sean and I talked about. We wanted to make sure it was clear to everybody. Here's what my process, KPMG's process, does not replace. Hazard analysis, FMEA, human factors validation, cybersecurity threat modeling, every one of those stays exactly where it is, and everyone is a discipline that I am not replacing. I take their outputs as my inputs.

And here's… here's a couple other scenarios that I… I saw. because I did a lot of research looking at a lot of recalls, here's a couple more. Because when we were doing all our scenarios in the test cases, I kept seeing these recalls where they're being bit by the very things that we tested to prevent. One was a nurse, I thought it was an infusion pump, I can't remember, but she had fat-fingered the input to this device, and somehow it entered an invalid character. And it crashed the device. And that turned into a Class 1 recall. And I… I just remember reading that, going, you can't tell me that they missed that. But because it wasn't a requirement, no one tested for it. And I remember

all through the scenarios, making sure that data going back and forth from the system to every docking station, and then from there to every pump, and back and forth, we put in all kinds of invalid characters, we did everything we could possibly think of. A lot of it was because of the nurses, because the biomeds would say what they were doing in the hospital to get the data sets ready, so the doctor could send the prescription to the right pump, the right patient, meet all those rules. And so we had a lot of stringent testing while doing performance testing to make sure no matter what happened to the… to the docking station or to the environment around it, that that pump would never stop infusing to the patient. We… we were… our goal was patient safety, and so making sure that the system around them was safe was our target, and because of all the input from everybody on that team.

At that company, when we're making those scenarios. That was what made the difference. It was a pretty amazing process.

As you said, so what… when Kris was telling me about this, it reminded me of the NASA Moon Survival Exercise Tests in collaborative problem solving. People rank, people are asked to first rank 15 survival items individually after a hypothetical moon crash. then the group agrees on one ranking. Both are compared with NASA experts' ranking. Usually, the group score improves, showing how discussion, diverse perspective, and shared reasoning can outperform individuals. And so, yeah, if you want to do some interesting reading, look up the NASA Moon Survival Exercise, because I think that's somewhat analogous to this, and

Yeah, sorry, side note.

No, it's… I used to be a big freak about NASA. And I remember reading books about, you know, what happens when they're out. off the ground, and there's no one there to help you. So, yeah, that's impressive what they were able to do, and brought everybody back. And like you were talking about earlier with me about submarines, same thing. When you're out at sea in a sub, no one's coming to your help. And so you have to make sure that all the systems that you rely on for air, water, to live. work 24-7, no matter what. And that if any emergency happens, people on the boat can fix it, and the mission can continue.

And, so I think that is kind of like the KPMG model as well. Let's see, as you can see. Okay, Sean, you've got this, right? You're waiting for me to click it, I'm sorry, you're waiting for that.

Right, this is poll number 2, correct?

Yes. Last one.

No, this is… this is the one in the chat. Wait.

I think you're right. Yeah.

This is a chat one. Right, okay, so again, for those of you who are still here, and now that you've learned about this, I'd like you to know, that we come up with 3 different ways for you to engage. Just get the self-assessment, 30 minutes, on the phone with Chris or, you know, partnering. And then I think I had another poll… launch… I don't know, maybe I missed the cue on this one, but here is the… Testing poll…

Oh, that's a good question.

I guess this is two questions. Okay, so the first question is, where do your tests come from? And two, has anyone outside engineering ever generated failure scenarios for your device? Awesome. So, while we're running this poll, I would like to sort of open up the microphone to anybody who feels compelled to speak. Please raise your hand or hop in. I think this has been an interesting exercise, and…

Sean, if you don't mind me bragging, we had several clients that I was able to use that process for. that products went out no problem. One was a company in the UK that had a TB testing system. They wanted an entire dashboard built for them, and it was a Class 2 system, and it couldn't have any problems. So we used this process, built a system, and it went out to their very discriminating clients in Japan. And they loved it. And they said, in fact, the bulk of the TB testing done in Japan is with this system. So, this KPM… this process works.

Okay, so I'm gonna go ahead and end the poll and share the results on the screen. So it looks like… For question number one, where do test cases come from? Those, plus scenario… Plus scenario sessions with clinical users. That's awesome. And then number two, has anyone outside, engineering ever generated failure scenarios for your device? Yes. Clinical users? Cybersecurity only? No. Don't know. So… 40% either don't know, or the answer is no. Cybersecurity only is 4, and yes, it's 56%. So…

For clinical users. I'm gonna stop sharing the poll, and… again, you know, now's… now… now is your time, people. Let us have it.

Okay, shall I start? Hi, Chris.

Okay.

Luke, how you doing, man?

I love the way you presented enthusiastically. You're a great presenter. I typed in the chat that… I think the process is great, but is it a little bit late in the design stage, just before VMV? But just after I typed it, the reason I typed it was before… because… I mean, every discipline that's everywhere on this call says you have to be in the process from day one. And especially risk management. I think Bijan would agree, like, risk management is a little bit scenario thinking, so you come up with all kinds of ways to look at your product. But then again, I think your method would be nice to have it as a formal step before, just before VMV, just… just, like, to check that you haven't, missed anything. So…

I think, yes, as a formal step, it's great, but it… It shouldn't be necessary, it should be done all the way from day one. But just in case, I think it's a good way to, to approach this.

Thank you, sir. It's funny, because I… I had somebody, I showed this to years ago, and they were giving me a lot of grief about it, and I said, okay, so why do we keep seeing these recalls? Class 1, the most severe, why do they keep happening? And then you see things like a nurse pushed buttons too fast. I read that, and I was like, are you kidding me? Really? That was one of… that's like Testing 101, or the Wi-Fi in the hospital had just an interruption, and it caused a device to shut down. I mean, really? And so, it's clear to me that people are not listening to other siloed teams in their organization. There could have been somebody in IT telling the engineers, hey, by the way, this site's got some issues with their Wi-Fi, and maybe he wasn't listened to, or maybe they were… you know, a lot of it's just time crunch, time to market, so they set that aside.

We'll worry about it later. How bad can it be? Bang. And so, getting everybody in the same room, to me, was the secret sauce.

Well, I don't have much experience with silos, because we're a small team, so you see everybody all the time. But I'm hardware, so whenever there's a problem, I blame software, and the guys from software, there's a problem, they say, it's a lousy hardware, you know how it goes. But in general, you're there from day one, and you just, I don't think you miss much if you're… if everybody is involved from day one.

And thank you for your questions. Let's see… Very common for smaller orgs to simply not have that bench depth, too. I know that the smaller teams that we worked with in the past. as Travis put, didn't have that bend step, so we would kind of bulk up when we'd do some of these scenario sessions to bring in some clinical or what have you, to give that insight, because sometimes The engineers just didn't see what they were talking about, and like you were saying, hardware, software, sometimes the clinicians didn't see what the engineers were talking about as far as risk, but when they're all in the same room talking, boy, it's a revelation.

It was for me, that's for sure.

I think… I think for me, one of the most important things working with a lot of organizations is, the authority and impartiality that an outside person brings into the group when organizing a cross-functional team. I think that if, even in a small team, that when you try to have one personality that has, you know, all the baggage attached to it. Trying… trying to run that exercise with the group. You're… you're gonna have bias built in. to the group from the very beginning, and I think that that, you know, understanding group dynamics, understanding collaboration, understanding how, people work best together, you know, structuring the environment where people don't feel judged for their comments, you know, and I've been…

part of, you know, exercises with this on company retreats at places where I've worked that were run by outside organizers. And that's really what we're talking about here. It's, you know, a final step. It's a final check to make sure that, the product that you're bringing to market is as good as it can be. And I see that Stephanie has raised her hand. Hello? Ms. Stephanie.

Hi, hi, Sean, in the group, and Kris, great presentation. Just a question.

I do.

Did you use your mythology, actually, also to increase or improve the usability along the way? Did you use it throughout the whole life cycle of the medical device? Because I…

I'm gu.

try this out with a startup, and we came up with really good ideas, actually, when we ran through different scenarios, so…

Well, here's my confession, because when I went to that medical device company, it was my first time working in the medical device world. And I mentioned earlier, I had launched a business that I wanted to just do on the side, right? And so… when I was working at that medical device company, I had no idea about, like, usability. All of that side of the company I knew nothing about, because I'd never worked in companies that were highly regulated like that, where you had usability and human… all of that. So I didn't know that that's what I was taking on. I was simply just taking their input on the scenario sessions, so I wasn't doing a usability study. They actually ran one separately.

For the dashboard, but I was just going through and just stressing a system. I wanted to find out where all the failure points were that are caused by unexpected behavior, right? And so, at the end, I realized, okay, I did a little usability. I was doing some of those steps, because that was part of the process of validating the entire system. And so, in hindsight, that's why Sean and I talked about it, we're not replacing any of those silos or any of those roles, we're just taking their outputs to aid in vetting the system. So I hope that makes sense.

Yeah, that makes sense. So you didn't do any design changes along the way, you basically more or less looked at what could be the potential problems then.

Actually.

That we didn't have the… yeah.

Actually, they did. Because I was lucky. that project had been kicked around, I guess, for a couple years, and they just didn't have the team or the, you know, the bandwidth to do it. So when they took it on, that dashboard was a system that had been designed by somebody in Jordan, like, 3 years before, and they gave it to the R&D team and said, make it work. And so they're… they were marrying these systems that had never been connected before. And so as we went through that scenario session, and I heard that developer say, oh my god, I had no idea, when the requirement said this, you meant that.

and I would have written all it wrong, he actually went back and made quite a few changes based upon that scenario session, and then he worked with us really closely afterwards to make sure what they were coding was what the end users really wanted. And so, yeah, that made a big impact. And thanks to the clinicians for the input, because that was what drove it. Because I got the feeling that a lot of these people that were in this room together for literally, I couldn't believe it the first time, a lot of them didn't feel like they had a voice. So a lot of the clinicians felt like they'd been ignored, nobody in RD would listen to them. It's like Loek was saying, you know, hardware versus software, right? So…

when they're all in the same room, they can't point fingers anymore, right? They all have to support each other. And I remember a couple of the tech writers saying, well, I've been reading your instructions for use, programmers, and you're off the mark. You're, like, 3 versions behind. And I just kind of started laughing, like, aren't you glad they're here? Because that would have gone out bad, right? Or it would have had to have some rework, but because we caught it at the beginning of the project, a lot of the surprises that would have happened later, we prevented. Because the… But no one knows the company, but the US side of the company had been going through recalls.

Because they weren't doing this. And they even made fun of me for doing it afterwards. And then when the system went out, no problem. Week 2, no problem. Week 3, no problem. They all got really quiet. And I said, it's not me, I'm not a genius, it's everybody in the room that was the genius. KPMG just said, here, use this approach, but it's the people, if they're willing to work together and contribute. That's the secret sauce. That was the magic. And so, I think everybody that worked on that team had a whole new outlook, at least as far as their team working together, because the European product team got closer and closer. In fact.

That project, it went out, and that team still meets on about a quarterly basis for lunch, just to see how everybody's doing, because, you know, people move around the industry, because it was such a successful project. And, so it was fun. It wasn't one of those, oh God, that recall, you know, it was, yay!

Excellent, I fully agree with you. Thanks, Chris.

Thank you.

John, I'd love to hear your view on this.

Yeah, this is, I think, really excellent. Of course, I work in medical device safety risk management, and our goal is to reduce risk, if possible, eliminate it, but what Kris is talking about is a good avenue to reduce risk, which in our world we call it P1. a contributor to risk, and really, the… I think fundamentally, medical device companies want to make safer devices. It's just not easy, and what Kris is talking about is ways of finding these defects ahead of time and removing them, and that reduces P1. There are, you know, other techniques, but I think I wholeheartedly subscribe to the same idea. Do it from the beginning.

and design the system better from the ground up, instead of trying to patch the risks later and try to patch them up. So I think this is really great, Kris. I appreciate your work.

Thank you, Bijan. Appreciate it.

I'd like to add, you know, what I love about this is that in the age of artificial intelligence, this is really human intelligence-based and collaborate… collaboration-based, and I think that when human beings work together to solve problems, it turns out much better than, well. I'm not going to denigrate artificial intelligence, I'm just going to say that this is how Humans work best. Together.

I never saw anybody in a scenario session hallucinate.

Very funny. Okay, it's noon. I want to thank everybody for their time and attention. I want to remind everybody, of next week's session is, specifically on risk, and, but the human side of risk. And so, we're gonna have, Two wonderful speakers who Bijan recognizes from, the session in, in June at the, IMSC26 conference. Do we know where the 27 conference is going to be yet?

Yes, of course, we are going to be in Dublin, Ireland, and I have actually visited the site twice already, it's just a beautiful Trinity College in Dublin, if anybody has visited it.

God.

And, yeah, please come. It's going to be an amazing experience. We're already building the program.

Okay, looking forward…

for it. temple bar.

No, no, actually, it's a 5-minute walk.

Jealous. Thank you. Sounds well.

I want to talk about… Kris, I want to talk to you about that, so after this call, let's talk. I wanted to… yeah.

Well, please do.

Great. Thank you, everybody. See you soon. Take care.

Thank you, everyone.

weekend.

Bye-bye.