What You Need to Know About the New Cybersecurity Regulations for Medical Device

Written By Patrick Kothe
 
 
 
 

Milton Yarberry is Director of Project Management at Integrated Computer Solutions. Milton has developed or managed software development for Motorola, Lucent, Cognex, Inktomi, and FEI, before moving into the medical software sector in 2006 with Foliage, Ivenix and now ICS. In this episode he shares about the Protecting and Transforming Cyber Health Care, or Patch Act, which FDA implemented in October 2023, including what software is impacted, the key take-aways from this regulation, if this effects legacy devices, and how medical device companies will be impacted.

Links from this episode:

Connect with Mastering Medical Device:

Support the show for as little as $3/month: https://www.buzzsprout.com/1286645/support

Thanks for listening!

 

Episode Transcript

This transcript was generated using an automated transcription service and is minimally edited. Please forgive the mistakes contained within it.

[00:00:31] Pat Kothe: Welcome! Software has been and will continue to be important to delivering quality and efficient medical care. With our life saving and sustaining medical devices, safety has always been at the top of our list. But the software world is a little different. And the pace is typically much faster than a typical hardware product.

Regulatory bodies have recognized the issues with software in and as a medical device and are attempting to provide guidance and requirements that assure our software products meet the same safety standards as the hardware ones do. Today we're going to discuss one of those pieces of regulation.

Our guest is Milton Yarberry, Director of Project Management at Integrated Computer Solutions. Milton has developed or managed software development for Motorola, Lucent, Cognex, Inktomi, and FEI before moving into the medical software sector in 2006 with Foliage, IVENIX, and now ICS. In our conversation we discuss the Protecting and Transforming Cyber Health Care or PATCH Act which FDA implemented in October 2023, including what software is impacted, the key takeaways from this regulation, if this affects legacy devices as well as new devices, and how medical device companies will be impacted.

Here's our conversation. Milton, you've, uh, had a quite a career in software development and you've worked not only in medical device but also other industries. Many times we like to think in in medical device we like to think that we're unique and sometimes we are but how are we unique when it comes to software development?

[00:02:34] Milton Yarberry: Yeah, I feel like there are so many, ways in which that is true, and yet, um, one thing I can say, I, I, I think there are a few areas that it's notoriously different in terms of the paperwork, defining requirements, traceability, the sheer amount of sort of homework you have to do in addition to the software component.

But, I think what's interesting, what I find interesting, so I find complexity and challenging problems interesting and like to tease them apart and find a practical solution. And then in this regard, I think that commercial software, if you follow the process that makes sense, it's very close to what the FDA wants you to do, i. e. should you decide what you're going to develop before you develop it? And that's like the underlying premise maybe of like design controls. Should you test it, make sure, make sure it works before it goes to the field? Not crazy stuff. Although commercial and medical devices, they feel absolutely different in a variety of dimensions, they really should be more similar if you were doing rational commercial development. Not everything is heavy and not with part 11 compliance on signatures and that sort of thing. But in terms of the general process of define it, build it, test it, and frequently that doesn't happen in commercial software that way.

[00:03:48] Pat Kothe: And within software, you know, we, we hear so often, get an MVP out there, build it fast, break it, come back and iterate and just keep moving it. Don't put a perfect product out there. Put one that's good enough and then iterate off of it. Not quite what we want to do in medical device.

[00:04:05] Milton Yarberry: And the key piece is just the safety, right? Is that if there is a problem in the field, for most commercial products, there's no staggering consequence, nobody gets hurt per se. And of course, the FDA's charter, safe Safety and Efficacy, that's what that process addresses.

[00:04:22] Pat Kothe: Software is, you know a big term and within medical device we've got software as a medical device and software in a medical device. Can you explain a little bit about what the differences are?

[00:04:34] Milton Yarberry: Conceptually it's pretty simple. The software as a medical device is basically software that runs on, not customized or generic hardware, so laptops, tablets, phones. Where software in a medical device is something that is using some piece of customized hardware. And the reason that matters is because the performance of the hardware matters as you could say as much in terms of getting the process right as the software interpreting what's coming off of the hardware. It's a, hardware plus software versus just software domain.

[00:05:08] Pat Kothe: So the regulatory bodies have been iterating on their guidances for software over the past 5 10 years, but they just recently came out with something in 2023, the Patch Act, Protecting and Transforming Cyber Healthcare Act. Can you lead us through how the regulatory bodies have addressed software and what this particular act is all about?

[00:05:40] Milton Yarberry: Really this act is, the FDA's request to be able to regulate cybersecurity and medical devices. the Patch Act, which passed as part of an omnibus spending bill, I believe, earlier this year. what's interesting about it, or maybe the high points are, is that, so this is the FDA saying, you have to have cybersecurity, and this applies to all medical devices with software.

[00:06:02] Pat Kothe: Whether it's software in a medical device or software as a medical device.

[00:06:06] Milton Yarberry: Yeah. and if you take a look at say the patch act language versus the refuse to accept from the FDA, the language is a little bit different. The refuse to accept as little narrow patch act is a little broader. There's two conditions that are the patch act that has software, or if it can be connected to the internet, that's an or condition.

So what that means is that a lot of companies were using sort of, uh, the, an air gap solution. Meaning, okay, our device isn't going to talk to the internet. We're just going to wrap it up in the box. And we're going to say, we don't have to comply with any of that cybersecurity guidance and that that won't fly anymore.

So now merely having software, even if you have no ports going in. You still qualify and have to create these plans and

[00:06:47] Pat Kothe: What, why is that? Why would, why that change?

[00:06:51] Milton Yarberry: I can see a number of reasons. Basically maybe the largest is just in the things that they want you to have, that are requirements. The S bomb, they want you to have a software bill of materials. The vulnerability plan, they want you to have a response in case somehow your device does get hacked.

So envision, even if your thing has no ports in it. Somebody cracks it open, reprograms it, now what do you do? And if you have no plan, then you, as a company, you're, at that point, you're at the beginning of the scrambling stage.

[00:07:20] Pat Kothe: What other things are, are in this, this act? I mean, what, what are they asking companies to do?

[00:07:28] Milton Yarberry: It's really quite extensive because, if you go through the guidance refers to other standards. So when you're trying to figure out what to do at the end of the day, there isn't a definitive recipe, here's everything, there's no checklist. And there really can't be a checklist because you're looking at so many different, technical reports, standards, and, the FDA's guidance.

And these things somewhat overlap and they use somewhat different terms. So there's no one definitive way to say this is all you need. And on top of that, FDA is, said to kick in the refuse to accept criteria.

And what that means is that if you have a submission and you don't cover certain basic points, like a vulnerability plan, like an S bomb, then your submission won't even be considered.

[00:08:12] Pat Kothe: So let's talk about cybersecurity for a second. What does cybersecurity mean? And from a medical device standpoint, what are the stakes?

[00:08:21] Milton Yarberry: It's obvious, it's don't let your device get hacked, but you know, there's, there's sort of categories of solution that they expect to have in place, uh, authentication, authentication, uh, uh, encryption, um, they expect you to have a software update, they expect you to do the analysis upfront, in a threat model of your entire system, they expect you to follow certain practices to figure out where you're vulnerable, and that's maybe the newest stuff It'll take quite a bit of adapting to, because a lot of people haven't used threat modeling tools. You're not familiar with the concepts, figuring out where the boundaries are and what the vulnerabilities are across those boundaries. all I can say is, reach out and grab one of the tools like, Microsoft Threat Modeling Tool. It has a medical device template that you can use and it's a click and drag interface that allows you to say, here's my system. And then the heavy lifting starts when each thing that you click and drag has a list of vulnerabilities. And you need to basically go in and justify why this doesn't apply, or here's what we do to mitigate that.

[00:09:23] Pat Kothe: Hard question, but I'll ask it anyways. I'm sure everyone is different. But when you're, the old way of developing software without this extensive cybersecurity, emphasis on here. Is this... Doubling the work, is this, a small amount of work? How substantial is this cybersecurity, guidance?

[00:09:46] Milton Yarberry: So that is a great question because, um, In the actual guidance itself, I believe it's, appendix B or Appendix two B. B , um, uh, there is a step buried to the very end of the document that saysuh, any relationship between any two assets, even if it's through other assets in your system. And an asset could be something like a server, an asset could be like a key, an asset could be a password.

And so you can envision that like in your normal system, you might have dozens of assets. they're saying that in between any two assets that have a, a relationship, even if it's through something else, here's an 18 point list of things that you need to satisfy and describe. So if you have even just a slightly non trivial, network configuration, you're talking about dozens, of justifications multiplied by 18 points that you need to document for that.

Now that's at the very end. So this is almost like an afterthought. in an appendix, not dealing with everything that you're supposed to do upfront, but in terms of, the simple answer to the question, it feels to me, it feels if you did it full strength, you could double the amount of, let's say, regulatory overhead on a project.

So that says, yeah, you got to have a strategy to get through

[00:11:06] Pat Kothe: So you, you have to have a strategy when you're, when you're starting a project for cybersecurity. And then there's some... more or less verification validation work that needs to be done at the back end to assure that it's covered. You're living with this throughout the development.

[00:11:25] Milton Yarberry: Absolutely. And that's what they say, you know, as a total product life cycle, they mandate that you have an SPDF define, secure product development framework. if I'm remembering the acronym correctly and that mandates activities before you start development, during development, and once the device hits the market in terms of post market surveillance. But the activities they expect upfront is that you do things like, okay, write these plans, and then follow these in your development. And then after the thing is out there, watch your product and report vulnerabilities here. Check for vulnerabilities there. It's a full recipe. I picture a whole suite of companies coming in to provide services for each of these stages, just to shortcut this stuff because it's so much to absorb when this isn't your main thing that you do as a company.

[00:12:13] Pat Kothe: I refer to it as a guidance, but it really isn't a guidance. This is a patch act. This is a requirement, correct?

[00:12:20] Milton Yarberry: Yeah. I believe the term is in regulation. So

[00:12:25] Pat Kothe: is regulation and as of,

[00:12:26] Milton Yarberry: becomes law, it's a

[00:12:27] Pat Kothe: and is it law at this point?

[00:12:30] Milton Yarberry: It is

[00:12:31] Pat Kothe: And this, this includes a 510k device, a de novo device, a PMA device, any device that has software that's connected or not connected to the internet needs, needs to follow this, this regulation.

[00:12:47] Milton Yarberry: and the act itself calls out, yes, it just needs to have software. And then you've got to have a, B and C the FDA has a software interpretation on their RTA, but it doesn't mean that they're going to pass that. That just means that they're open to the.

[00:13:00] Pat Kothe: So when you look at this as an experienced person, what's the easiest devices to implement this? And then what, which are the more complex devices where you're really gonna have some, some extended amount of time to put into this?

[00:13:16] Milton Yarberry: Yeah, let's say the most complex would be the ones where you have multiple network entities or assets. Let's say that you have the actual medical device itself. Let's say that it has a, a portal that it, uses to communicate over, say, multiple, communication paths, not just Wi Fi and Ethernet, but maybe also an additional band as a backup.

Let's say that you have remote people on their iPad, observing a procedure. Let's say that you have, metrics going up to a server. at that point you have so much network, so many entities, and so many agents within that. And areas where you have to have a robustness against, like denial of service attacks, for example, and areas where you don't care about that.

And you need to have all that written up, justified and, implemented and tested. So, I mean, it's, it, it's a heavy lift. So really being aware of the overhead as you even scope your product.

[00:14:12] Pat Kothe: And on the simple end, it's the software in a medical device that's not connected to anything. that's the easiest one.

[00:14:20] Milton Yarberry: I actually haven't tried to apply it to that style. I've tried to apply it to the one that I just mentioned. So the more complex scenario, and when I think about how much can this be cut down for the lower end of the spectrum. Maybe I can't even comment on that right now. I need to think about it. So,

[00:14:37] Pat Kothe: So, um, this act didn't come from nowhere. Somebody decided that there was a problem here and then some people got together and wrote this. Were medical device professionals involved in the writing of this?

[00:14:54] Milton Yarberry: The actual guidance that the FDA put out, I believe it was 2014 was the first iteration, and then there was an iteration of believe in 2018. And so it gets feedback on each of these stages. the last or the previous guidance that was put out. typically what happens is they collect feedback from the, industry and then they apply it and they'd make it final.

They didn't even get to that stage. Things were changing so fastum, with the ransomware attacks through COVID that they just said, okay, you know what? We're not even going to make the next, we're not going to update and release that version. We're just going to move on to the next version. Here's a new set. I don't know if they're actually still pulling for comments on the current guidance from 2022.

[00:15:34] Pat Kothe: How is this, this act been embraced by people within industry? Has there been pushback? is it, readily adopted. What are you hearing from your peers?

[00:15:44] Milton Yarberry: I think it's too new for people to have gone through full cycle. The latest guidance, which I think it doubles in terms of length from the previous iterations, it's twice as long as the previous iteration. And that tells you about how much more substance they put in it. And I don't think that, yeah, I don't think there's, since 22, there isn't time to apply it, submit, have the feedback from the FDA.

So I sort of suspected that a lot of this is going to be, they're actually feeling their way through this. Like one of the examples I'll give is that, an SPDF that's called out in guidance, which is like at least 62, 443um, is. is not actually intended for medical devices. It's for commercial products. There's another standard, I believe it's 81001, intended for medical devices, but it wasn't positioned in the guidance. So, um, you know, one of the things I recommend doing is go with a, go with the one that, better fits. but that tells you how new things are.

And, that other thing I mentioned about the 18 points of compliance between every two assets that you're supposed to write up that's buried in an appendix. That, that feels kind of, there's more to come on this does that get cut down to size? Does it get adapted or qualified?

In terms of what you're supposed to apply it towards, because you could spend months creating documentation that really doesn't address the vulnerability of your system, and that's never good for anybody.

[00:17:16] Pat Kothe: So I'm sure that, you had projects that were in process before this hit. And, it probably affected timelines of your projects and maybe even design of your, of products. Tell me a little bit about how you approached that when this dropped.

[00:17:34] Milton Yarberry: We tried to get the word out, frankly, before it became law, before it became regulation. People were doing cybersecurity at the end. They were primarily in the cardiac business or the infusion pump business or the IBD business. And their mind was on this problem, which was groundbreaking, which was their product, which, required all of their concentration and they don't have time for those other issues until it's preventing them from moving forward. I don't think it's been encountered yet. People know a few things that they were supposed to do and they were intended to do that at the end. I think it's gonna be interesting. Either you will get a bunch, a wave of applications which don't get accepted and then people will start writing about that and then people will respond. It's all has to do with how it's being policed, frankly.

[00:18:23] Pat Kothe: This is similar, similar to what many startup companies do. They've got an idea, they start talking to customers, they start developing a product,they understand what user requirements are going to be, and they start building. And then at some point in time somebody says, Hey, we should probably get a quality system going here.

And then they have to go backwards, and then going backwards causes all kinds of time delays, and issues, and things going on. So this is a similar situation. The further down the road you get, the more painful it is to go backwards.

[00:19:00] Milton Yarberry: Absolutely. Absolutely. Well, and so I guess where I've seen that happen to both, new players in the market as well as experienced players. and I find that curious, I find it maybe even to the point of, to understand the dynamics in that, does that, does it make more sense to do it that way? I'll actually toy with that idea. is it easier to back into a solution than to manage a process? Because managing a process means, a decision chain, uh, and it's sort of an executive function. Um, managing the limited problem is a little more like firefighting. You know, it's the urgent response.

It's something you can deal with and conquer now. It's well understood, well bounded. I have a term, fires not cats. Like I can put out a fire. I know how to do that. I don't know how to manage cats. I don't know how to get everybody in the chain to agree ahead of time before we implement.

[00:19:51] Pat Kothe: It's a harder problem. and I think we are natively problem solvers more than we are consensus builders.Yeah, I find it, um, when, When there's a blur between research and development, that's kind of what, you know, where there becomes an issue. If you're still in the research phase and you're developing product while you're researching, uh, you run into those problems. if you've done the research and now you're able to do development from, this is the idea, this is the user requirements, this is the road roadmap we're taking, and you're pretty firm there. Then it goes like clockwork. But if you start ingest, injecting more research into that, it kind of messes, the development project.

[00:20:36] Milton Yarberry: Absolutely true. But I feel even those that, have done this before. And, um, have, have produced solutions and had them released. And, you know, it's, it's kind of a rinse and repeat. There still is that, fuzziness, a slight fuzziness around customer needs. How is this product different? What's the value add?

And, frankly, there's going to be less ambiguity after the thing is built about what needs to be in place. But I think there's, it's a confluence. I don't think it's any one, two, or even three reasons. There's many reasons, like for example, for those who don't, haven't, written requirements that go through, verification and validation before.

It's easy to confuse, requirement writing difficulty with product uncertainty. Writing requirements. It's hard, it's low, it's not exciting. And they don't know how to basically write a requirement that kind of just motivates a test. That's why you're writing a requirement.

Cause you're going to test it. You're going to prove it. So only write the important things. A lot of them don't understand

[00:21:35] Pat Kothe: Yeah, it's like saying, a requirement is a surgeon has to like it. Well, okay.

[00:21:40] Milton Yarberry: Or be easy to

[00:21:41] Pat Kothe: Ease of use. Ease of use is another one. Yeah, define ease of use. How am I gonna test against that? Yeah. So you brought up a really interesting point because many medical device companies,have focused on hardware product, and software is something that's different. And when it comes to user requirements and user needs, I'm sure that there's a learning curve for people when it comes to software.

So they may be a product manager who's got a hip or a knee or a shoulder or a catheter, and they're used to writing those physical product requirements. But software is different. how do people transition from writing those hardware to software requirements?

[00:22:30] Milton Yarberry: Yeah. mean, you know, I'm sorry to say, but kind of poorly, you know, they, uh, you know, it's, it's, it's, it's difficult. I would, and I would just say, simply find somebody who, whether you hire or go outside your organization, find somebody who's done it before. But even for the people who've done it before, if you get two of those people in a room, the likelihood for there to be. Different processes and expectations is, pretty close to a hundred

[00:22:56] Pat Kothe: what are the differences between writing for software versus hardware?

[00:22:59] Milton Yarberry: Software tends to be all functional, particularly when you're writing specifications around hardware, electrical systems. do you specify that it shall be a 19 watt transformer for the power supply? Or do you specify that the system shall not have brownouts under any conditions?

So there's a little bit of, hey, how do you write a requirement that doesn't overspecify your solution, specifies what you actually want to go after as a test. And that kind of abstract thinking, I find that, people from the systems end of the spectrum are less familiar with. And I think it's easier a little bit on the functional side, the behavior that you want the user to experience is all around the user, right?

So there's a clearer chain on that side. But I think, um, well, you also end up with two different design processes. Software, it's very much, what's a requirement, convert that to specifications, convert that to tasks. Let's test it at the end of the sprint. Hardware, you could, for example, under, board fabrication, have a whole, three months where there is, okay, we have the schematic, we converted it to a layout, we sent it out for fabrication, we populated, we did the burn in test, and you do all that to get to your first does anything work at all or are we in another hardware cycle spin?

So the time spans are just disproportionate to the software side. You can't really keep them in sync and you really need to have an overall design plan that says, here's how requirements are managed over here. Here's how requirements match over here. And here are the touch points.

[00:24:31] Pat Kothe: So when a company comes to you and, and says, we've got a, we're, we're primarily a hardware group. We, we've got a idea for a software, software product. How do you do that? I mean, do you help them through that process of doing requirements or are you expecting them to deliver that? How does that work?

[00:24:49] Milton Yarberry: I don't think I've ever, I have to think about this. Have I ever had customers actually deliver me? even requirements that were like 50 percent done, you know, I mean, it's, and, and, and on the other hand, on, in the beginning of the engagement, if you ask them, they'll say, do you have a PRD product requirements?

And, I'd say 80 percent say, yes, we have that. And then on the delivery side, it's okay, most of this doesn't apply is done yet. Let's just start over. and that's where most of our engagements, begin. Even when they're really close to finishing the implementation.

[00:25:24] Pat Kothe: Wow. So why do you think that is?

[00:25:28] Milton Yarberry: That's a really deep multifaceted, question. I think it's because, I think there are solutions that could be applied to it. Like right now, if you think about the process of how do I define my product? Okay, we know we have a product requirements document. We know we have some sketches.

We know we have conversations. There's no place where everything lives. And the formal documentation, the cycle time for that to get reviewed and checked into your doc control system and then re release to engineering. So now you know what to build is so lengthy that it never gets used. So it's kind of like there's no one source where all the inputs meet. And then chiefly when, let's jump forward to where you actually have completed product requirements and specifications. Ask somebody to read one of those. you get about half a page in of very carefully worded You know, factors that you have to keep in your mind before you're, you forget what the first one was that you read.

So they're very difficult to consume because they're all text. It's very dense. It's very technical. So what do you do about that? This is one of the, reasons why I'm at the company. I'm at ICS is one of the products that we're, in the process of creating is something that pulls threads together like that drives it through pictures, drives it through the user interface layout, drives it through, state machine diagrams, uh, swim lane diagrams, and then allows references to your requirements and specifications.

[00:26:59] Pat Kothe: Tell me a little bit about ICS, what you guys do, what types of projects that you're involved with.

[00:27:04] Milton Yarberry: We're a software services business, been around since, 1987. and basically, what I like is we try to solve axel wrapping problems with novel technologies. We have a couple of internal products, one called greenhouse, which is a low code solution.

So it allows you to basically draw pictures for your UI and then code comes out that gives you an architecture front end to back end. we're developing the product I mentioned around defining your product. But otherwise we're a full stack embedded development. chiefly we have a usability, dedicated usability group.

And we have a deep, you know, reserve of experience around Qt. But otherwise, I mean, we're front end and back end automated testing, V and V testing, cloud connectivity. You know, it's kind of everything you would have for a medical device.

[00:27:52] Pat Kothe: And you personally do the medical device side of things, but the company does other verticals as well, right?

[00:27:59] Milton Yarberry: Yes. Yes. Uh, More so it's, uh, medical devices sort of taken over. We're medical devices about probably about 70 percent of the business we do, in the past, maybe two years, three years. We also, have, I would say, roots and still ongoing work in commercial sectors as well for like automotive, industrial machines, that sort of thing.

[00:28:20] Pat Kothe: So I want to focus a little bit now on the user side of things. When you go under the hood, there's analysis that needs to be done, there's the hardcore functionality of the product, but then there's the user interface. And within medical device, it, It could be a little bit different than it is with, with your phone or with a simple device where it's all simple.

Sometimes our medical devices have multiple things that, you know, complex issues that people need to enter data in or manipulate the device, with a more, complexity to it. How do you guys approach. UX when it comes to medical device and balancing simplicity with the needs of the product.

[00:29:11] Milton Yarberry: great question. Um, so first of all, I would say that there is a usability standard out there, 62, 366, which is the core for us applying usability to medical devices, it gives you a process or a series of input that allows you to itemize and feel like you've done a comprehensive job of itemizing your use errors.

So not mistakes the user makes defects in your device that the user will step on. There's that aspect and that's how we approach, designing it and assuring that we're doing the risk analysis right around the user interface and that's, medical devices, safety and efficacy.

That's, the risk analysis is a pretty critical part of that, and a primary motivator, but usability more broadly, it gets used by many industries and it can kind of mean, in my mind, there's a dichotomy there. There's the, it's a pleasure to use. And then there's the does it maintain safety and do you make use errors. And those two have some overlap depending upon the device, a little overlap, or a lot.

But there are clearly places where they don't line up. A pleasure to use advice means that maybe it doesn't annoy you, uh, a medical device that's going through an alarm, you want to annoy you at the right time. There's also concepts of alarm fatigue and, mitigation to that, but there's a different, completely different set of logic driving those two things and, When we're doing medical devices, we tend to almost, 80 percent focus on the safety aspects over the, was it a pleasing experience because, you don't want that to ever trump, the former.

[00:30:54] Pat Kothe: My wife went to the dentist last week and she came back and she was a little upset. I said, what happened? She said, I'm laying in the chair, the hygienist is, doing whatever she's doing. And then she's turning back around and I hear something being entered into a computer.

And then she's coming back in my mouth and I'm thinking, did she just enter something with her finger and now she's, you know, on a keyboard, and now she's going to go back in my mouth. So when we think about, Software, sometimes it's entering things in with a mouse, with a keyboard, but it can also be voice, it can be gestures.

Tell me a little bit about where software as a medical device is when it comes to some of these other things so that somebody like, like a hygienist is not going to be entering things in on a keyboard.

[00:31:50] Milton Yarberry: Yeah, that's maybe,a confluence. so how would that come up? So first of all, what they're entering, is probably not even regulated software. That's been my experience is that hospitals and dentist office, most of what's on their computers is, it's not software, as a medical device, and it's because they can't tie it to an intended use and a clinical function, so therefore patient safety is never evaluated, which is interesting. I think, based upon what I've seen, uh, around hospitals and, the software used for the physicians and, the nursing staff. I imagined in, choose your number X number of years that's going to be regulated, it's just going to take a couple of bad events for that software to say that patient was treated with this and they weren't.

For that to be, become an issue. but, yeah, so basically I guess my answer is yeah, it's not regulated. So,

[00:32:44] Pat Kothe: But are you dealing with things, with things like gestures and, and, and, uh, voice, uh, voice activated things when it comes to software that you're involved with?

[00:32:53] Milton Yarberry: yeah, yeah, we've seen those, but I don't feel like it's really ever taken off. They've always been sort of more experiments, toys, things that go through formative study. and I don't know why they haven't gained traction in a more permanent way. I almost feel like I saw more of that, three, four years ago than today.

[00:33:16] Pat Kothe: Interesting.Once you get through the user requirements, and you have those down, there's other things that happen during that development phase.

So what are some, some areas where you see, after user requirements are locked in, and you're going through development, what slows things down? What makes, uh, you know, some, some sand in the gears??

[00:33:39] Milton Yarberry: Beyond the areas of, we didn't really define the product and that causes ripples of change throughout your system. and those ripples, they can start at, okay. We, we had a release candidate and we were testing it and now we have to do a formative study.

I've been in that scenario and informative study means there's a change and the change means you're going to go through V and V again and blah, blah, blah. So, um. Things like having to repeat summative, which typically ends up being a fairly expensive, often external effort, that those are big penalties, involved with that.

I think that a key area, as I mentioned, of course, is the, getting everybody in agreement and aligned around what the product is. is a key area where it hurts the product all through all phases, basically, including the test writing at the end, understanding, well, is that the way it's supposed to work?

Or, is it supposed to be a or B or hasn't this not been thought of yet? And not having a place to check that. So then that becomes meetings that becomes as opposed to, you can look up the answer in a very specific location. Another area is, yeah. Especially around medical devices where there's a hardware component is the hardware cycle, everybody knows, of course, things got killed in COVID backlogs, out the door, 18 month backlogs on some of our projects, waiting for hardware to become available.

so simulators is, a key answer to that. And,

[00:35:06] Pat Kothe: What do you mean, what do you mean by simulators?

[00:35:09] Milton Yarberry: Oh, something that, simulates, emulates, hardware on your system and allows you to progress with, development, testing, debugging,

[00:35:18] Pat Kothe: So even though the hardware isn't done yet, you're simulating the effect of the

[00:35:23] Milton Yarberry: Decoupling basically your software and your hardware programs with simulators and emulators, yeah.

[00:35:29] Pat Kothe: Okay. and then there's the old management injector, you know, one more thing, can we just add this in?

[00:35:38] Milton Yarberry: Yeah, now, now that, in fairness, I guess I have to treat that I, I try to balance all these, points because I'm interested in root cause. And if you have late information to the table and you're in charge of a business and a product and your job is to bring that product to market, are you doing something wrong by including that, no matter how late? It depends is the obvious answer. it depends on how much of that's going to hurt you and is it worth the cost and the risk. So to those sort of problems, particularly where there, where the information comes from outside the organization, I guess a fair critique would be, we should have done better research for that upfront. And sometimes you do that research and other times, I'd say most of the time our clients are so deep in their industry, that it's difficult to say you've spent 25 years in your industry, you've built four of these before you should do some research.

[00:36:33] Pat Kothe: Yeah. Yeah. And sometimes when we're developing a new product, we won't. There will be things that come up when you go and take it back out to the customer and say, this is where it is. And the customer will say, well, if you did that, we can do this. And, so there's, there is some late information that comes to the table that you may not have been able to anticipate.

[00:36:57] Milton Yarberry: Right. But I think a lot of that information, that type of scenario, a one off comment late in the game, that's really dangerous bait, to go after. You, you have to assume that, there are all these psychological factors around our customers. They didn't know they wanted an automobile because they only had a horse and carriage. Those sort of factors. So you have to figure out where you're leading the customer, and really what's a valid input. So that should be an entire process of vetting and justification.

[00:37:28] Pat Kothe: Let's talk a little bit about updates because, you can enter in with the product that you want, but if somebody comes in and says, there's some bait out there and it's actually strong bait that could be used, but you don't want to slow down or stop your development program or product launch, but you think that this is a valid idea.

Now you've got version two that, it could be implemented in. Let's talk a little bit about what regulatory bodies are saying about updates to software and how that should be built into the regulatory filing.

[00:38:06] Milton Yarberry: Happens in startups a lot. You work like crazy in order to get the product out the door and then you finally get it submitted.

And then there's a gap between the beginning of the submission process and then kind of a slow trickle based upon every time the FDA comes back to you with comments. Maybe you tweak something here or there and that gives your entire engineering team, which was killing itself, a month ago, now they have almost no work and that no work can go for several months. So there is sort of a fast follow release, that is,thought of, okay, we got our, our primary version out the door that we're going to submit with. We should consider which changes we want to fast follow with. We should consider what regulatory steps we have to go to because of those changes, and it could be something as simple as a letter to file, which is like no FDA interaction, at least immediately, and then, to a supplemental submission. There's a lot of leeway and a lot of flex in terms of what the right answer is.

It's very situation

[00:39:05] Pat Kothe: Yeah, and, and it's something, uh, say it's an algorithm and you've got machine learning or some AI in there and you're going to update that portion of that. You may not update the full piece of software, but it could be part of the analysis engine because you've got learning that's occurring real time.

That's another, another situation.

[00:39:27] Milton Yarberry: Yeah, the whole machine learning aspect. mean, there's a lot of pieces to that. there's even the notion that, you as a manufacturer now are responsible for, curation. You know, so the data you trained it on is now kind of, especially once you've released that, that's a golden fixed set and which examples you choose to include or remove, in a sense, need to be understood well and justified.

Why did you include these four samples and why do you remove those 200? But the FDA has, um, published expectations around this for people that want a shorter path to being able to update their, um, They're neural network or their machine learning, but most of that comes down to, uh, you have expectations for where you're going to see improvements.

And when you have expectations consistent with that, then you have a shortcut. Otherwise you're kind of in the same boat of needing to resubmit or evaluate the level of the change.

[00:40:21] Pat Kothe: So when you get um, these changes, um, in your, in your, uh, uh, development program, what is the best way to manage the change process? Do you have tools that you utilize or methodologies that you utilize that says, a change is coming in, now how do we evaluate the impact of that change?

[00:40:44] Milton Yarberry: Yeah, so there's kind of like two sides of that fence. There's a sense before you actually have a formal release. In which case, changes aren't as formal, aren't as, overhead burdened. until the design is quote complete, it's not actually a change. You are in the process of designing. As soon as you have a version that goes over to your V&V group or makes it out of your V&V group at that point, now you're talking about changing your design. And that requires a formal process, particularly where you take a look at any risk you're introducing with your changes.

[00:41:15] Pat Kothe: The PATCH Act deals with, um, with devices going forward, but we have a lot of devices that are out in the field right now. pacemakers that are out there, that, they're inpatients, they've been in for a while. We've got, other types of things that were, put out last month, that, that didn't, didn't, uh, uh, contemplate or weren't as robust when it comes to these, uh, issues with cybersecurity. What is the agency and what does, the industry have to do from a responsibility standpoint from these systems that are already out there?

[00:41:54] Milton Yarberry: I've seen nothing of like, uh, either the term grandfathering or the need for anything that's already deployed to change, at least not in the U S In the EU. It's a different story. But, anything that's been released in the past, what since 2018 those devices have probably taken a look at the guidance and I think we're past the days where hopefully, anybody is putting out something with, they didn't change the root password and they didn't, they didn't do all the obvious things, So there's doing the obvious good housekeeping, use passwords, use of, uh, sufficiently, uh, sophisticated encryption, have a software update process, uh, that, uh, is protected. Secure boot. You know, all these things are table stakes. But a lot of the threat modeling, for example, goes beyond the table stakes. It's looking at, did you really scrub your network to see where you were vulnerable and how, and tell us explicitly which things you were, you considered through your documentation. It's almost like a zero day attack, thinking, rather than lock the doors, lock the windows, turn on the burglar alarm.

[00:43:05] Pat Kothe: So we're fortunate that, uh, going forward, a lot of these things are being contemplated and built into systems. We still have some risk with some of the legacy systems that are out there. The further out we get, the better we're all going to be. But there's still some risk for products that were manufactured previously.

[00:43:23] Milton Yarberry: Yeah, fortunately, the really old stuff where, they probably didn't look at any of the guidance. is probably not very communication enabled. So pacemakers, for example, I know there are a few cases where, there have been some glaring problems, but, those problems have been identified.

Others, are addressing them if they had them. at this point, I don't see a big remediation wave, like sweeping through those products, or at least I don't see the motive for that yet.

[00:43:48] Pat Kothe: Yeah, and there's risk reward there too, because,if it's a, an, implanted product, there's risk in taking that out, so you have to balance the risk between what's a cyber security risk versus what's the medical risk for another procedure.

[00:44:02] Milton Yarberry: Absolutely. Absolutely. The rollout can, yeah, literally kill you.

[00:44:05] Pat Kothe: Yeah, yeah. Well, this has really been a fascinating discussion and dealing with a very timely issue and one that, that most medical device companies are wrestling with, that will be wrestling with because even, simple hardware products can, often be, augmented with, with a software, software product alongside it.

So thanks for leading us, uh, kind of, uh, on the discussion. As companies are becoming more software oriented, what do you see as some things that they should be considering as they make that transition from only hardware to having software as well?

[00:44:45] Milton Yarberry: well, well, I think the industry is taking care of that in a sense, you know, I'd say like the last few companies I've worked with, it's rare to meet, a mechanical engineer that's just, doesn't know scripting of some sort. As, uh, uh, the kids are coming out of school and going into industry, they have the multidiscipline, You find fewer purists these days and, uh, you know, that basically the system will just sort of age in that direction so that people are more system capable rather than just in a particular domain capable.

[00:45:17] Pat Kothe: When I think of project development or product development, the marketing people are also people that are interfacing with the customers and translating customer needs into user requirements. And, If they're used to being hardware people, even though the development people may be software people, the marketing people may not be.

And that, that, that's an area that I think should probably be beefed up as well.

[00:45:42] Milton Yarberry: Although as soon as you're going as far out as marketing, which, you know, from, uh, I used to be an engineer and, and, and, uh, you know, interested in engineering and the architecture, uh, heavily. Product marketing is about as far away in terms of expectation. So I think there's already a lot of, support structures , uh, you know, in people's heads and in people's processes to, Bob said, he wants it to be easy.

Okay. Now we know we got to break that down with a formative study. We know that we have to write a use case, get Bob into use cases. and then let's map requirements to the use case. We're used to when dealing with, you know, um, business owners, product owners, marketing, um, to assisting in the conversion to something concrete and testable.

[00:46:32] Pat Kothe: Software is here to stay, and software regulations are too. As we grow the types of products we offer, we need to keep our North Stars of safety and efficacy front and center. A few of my takeaways. First, stay on top of regulatory changes. Not just what is here now, but what's coming. Because it will impact your timeline. And it will impact your development plan. And it will impact the costs associated with your development plan. If you need to involve an expert, seek out someone like Milton. It's going to pay off. Secondly, user requirements. We had a nice discussion on user requirements, and we're familiar with that, uh, with hardware, requirements for, medical devices, but we may not have a clue what best practices are with software.

So, find an in house expert. If you have them and have them run it, if you don't have one, bring someone in from the outside. Again, your timeline and your costs are going to be at risk if you cut corners in this area. Finally, changes will occur. No project goes according to plan in what you did with your user requirements right up front.

So try and do the best you can to define the product up front, but then recognize that changes will come. And then you have to manage the project. You'll have to make decisions based on customer feedback, timing, launch windows, competitive products, regulatory issues, and management expectations.

So understand up front that changes are coming. And what you need to do is develop a management system to be able to handle those changes efficiently.

Thank you for listening. Make sure you get episodes downloaded to your device automatically by liking or subscribing to the Mastering Medical Device podcast wherever you get your podcasts.

Also, please spread the word and tell a friend or two to listen to the Mastering Medical Device podcast as interviews like today's can help you become a more effective medical device leader. Work hard, be kind.

 
Patrick Kothe
Previous

When to Use Contract Manufacturing, and How Life Prioritization and Self-Care Affects All Areas of Your Life
Next

Transitions - From Sales Leader to CEO, From COVID Ventilator to Full-Featured Product