MPR: Getting medical device development back on track

In this podcast, experts from MPR discuss what medical device companies can do if things go sideways during the product development process. Drawing from their own experiences, engineers from the firm spoke with MassDevice.com editor Sarah Faulkner about how they tackle device development challenges when they are called into action.

Sarah Faulkner: Hey, everyone. Thanks for downloading this podcast. I’m really excited to bring you this conversation about what to do when things go sideways during the product development process.

Faulkner: I spoke with a group of experts from MPR. They’re a product development firm that specializes in this kind of crisis management technique. They have a history of tackling really hard problems. In fact, their founders, they were at the forefront of the nuclear power movement, helping to guide the successful development and implementation of nuclear power for submarines.

Faulkner: Anyway, I spoke to them about how to navigate some of the challenges that can crop up when you’re designing and developing a product. So without further delay, let’s jump right in.

Faulkner: Let’s start with a story. Based in Harrisburg, Pennsylvania, MacuLogix developed the first and only diagnostic aid that can detect subclinical age-related macular degeneration. Early detection is critical so the doctors can step in and provide treatment early enough to stop blindness from creeping into the patient’s eyes. But the company had a problem. Its devices were experiencing unusual, intermittent instrument failures in the field. The instrument is a complex mix of hardware and software, and the MacuLogix team couldn’t untangle the two to determine a root cause.

Faulkner: After CEO Bill McPhee put a request out to people within his network, he was eventually connected to MPR. And within one day, MPR was in touch with MacuLogix to solve the problem. In a letter to MPR, the company CTO, Greg Jackson, is quoted as saying, “From the outset, MPR treated our problem as if it were their own, as if MPR’s reputation was on the line.” He went on to say, quote, “What was probably most impressive was the speed with which they integrated into our team. Within a day, it’s as though they had worked with us for years. Their extraordinary test facilities and state-of-the-art tools provided us with the level of diagnostic intensity that simply doesn’t exist in-house in most early stage medical device companies.”

Faulkner: Needless to say, MPR got to the root of MacuLogix’s problem, and this is just one example of the countless fire-fighting missions that MPR is hired to tackle. The process that the MPR team follows when they’re called in by a friend to help reroute product development, that process is both methodical and analytical. According to MPR’s Director of Product Testing, Lynessa Erler, the first thing MPR has to do when they’re called in is to identify and wrap their brains around the problem.

Lynessa Erler: Understanding the problem has already been done. Just try to solve it. Try to get all the data. Get the data, not just the opinions as to what conclusions they’ve drawn from the data, but get to the actual data.

Erler: A lot of times, what you find is either they’ve drawn a faulty conclusion on the data, or the data itself was flawed. And that can be very difficult to piece apart if you’re not digging into the details. So that’s where I start, you probably …

Eric Claude: Yeah, no, you’re absolutely right. Here’s the way I think about it, an analogy is, it’s like walking into a crime scene.

Faulkner: That’s Eric Claude, by the way, VP of Product Development at MPR.

Claude: So we start with the forensics. Let’s collect all the data that can be collected, and see if we can find the murder weapon and the fingerprints. And all of the data that surrounds whatever the incident might be, and then start with that.

Erler: But see, with really complicated medical devices, if it’s an intermittent problem, that is half the battle, is finding what conditions lead to the issue, in a repeatable manner. Because that may be your first challenge, is trying to repeat the failure. And until you can do that in a reliable way, you’re just stabbing in the dark. And you’re saying, “Okay, something like that, what might it be?” And then you’re looking around. But until you can recreate it, it’s very difficult.

Faulkner: And it isn’t just the technical challenges that MPR faces when it’s called in to help fix a problem. It also comes down to navigating a company’s culture and working through the tendencies that are brought about by human nature. That’s according to Craig Mauch. He’s MPR’s Director of Product Design.

Craig Mauch: It always goes something like this, is that you’re in a root-cause mode, and invariably, there are people who are engaged in the problem, trying to solve it, sometimes not that happy to see us. Sometimes they’re happy to see us. But there’s usually a lot of preconceived notion of what the problem is, and the notion of doing this root-causes and getting to the bottom of things is to setting up a good framework of, “Let’s identify everything that could cause the problem, and then let’s, in a methodical way, do some kind of test or analysis or thought experiment, or look at the data for each and every one of those conceivable possibilities to prove or disprove whether or not it could contribute.”

Mauch: And sometimes, your hardest problems can be two or three things all at once, massed together, so that’s why a methodical approach is really important. And then because invariably there’s always one person saying, “No, no! It’s this! It’s this, it’s this, it’s this, it’s this! It’s really this!” And there’s usually a more reserved person over in the corner who’s got all the answers but is not necessarily as boisterous.

Erler: I think everybody has hunches, as to … Everybody has their best guess as to what’s wrong when you go in, yes. How strongly they advocate for their theory I think depends on the person. But yes, you get some personalities involved, you get people who feel like you’re blaming them, and it’s really important to come in and make it clear that you really aren’t. The only thing you’re trying to do is solve the problem. You’re not trying to point blame, you’re not trying to get somebody fired, but at the same time, recognize that you’re dealing with human beings and so these anxieties and fears are gonna be there, and you just have to stick to the facts. You just focus on that and try not to bring the emotional component into the root cause.

Claude: To your point about constraints and attitudes, that’s one of the hardest things. It’s human nature to follow your hunches, and it’s often the case in a rescue operation when things go sideways that you have to listen to the customer as they describe, “Well we think it might be this, we think it might be that”, which are largely hunches. But then you have to put all that aside, and you have to say, “Okay, let’s really take an impartial look at what’s happening here, and try to understand what’s going on, and develop facts, the set of facts that either prove something could be the problem, or disprove, and make those fact-based decisions”, which can be hard when the human nature aspect of it is to say, “Well, I have a hunch,” and that can be challenging.

Claude: And as you described with regard to communication, that’s an important aspect of managing those preconceived notions that people often start with on these things.

Claude: We had- so to that point, I’ll share another example of a situation when things go sideways. We had a customer that had launched a new product with a battery-powered surgical tool. And this particular tool had some very strange behavior. After it was used, it would start to heat up unexpectedly. It’s not even being used, it’s starting to heat up. And so the notion there was, “Well clearly there must be a hardware fault happening with this device. It just randomly fails, there must be some electrical component in there that’s causing trouble.” Well it turned out, at the end of the day, the hardware was fine, it was actually a software issue which was the problem, which was completely unexpected. No one expected that to be the challenge. In that case, it was fortunate in a way, because it’s a little bit easier to make a software change and upgrade all the software than to recall a bunch of devices and redo the hardware inside of them.

Claude: So it’s often the case, again, that’s an example of, “It’s easy to have preconceived notions about why we’re having a problem, but often it’s not that. It can be something very unexpected.”

Erler: Or to have preconceived notions as to what’s possible without challenging the why. “Why do you think that this can’t work this way?” And really getting to the bottom of that, because maybe you’re falsely constraining the solutions.

Faulkner: So how can companies avoid these kinds of pitfalls in product development? According to Craig Mauch, it’s all about the basic tenets of engineering.

Mauch: One of the things that’s really big at MPR is about the first principles of engineering, so we like to design the products, and then build the products, and then test the products. And it sounds very rational when you say it that way, but you’d be surprised how many people skip a step or get going too fast and don’t do enough fundamental design work.

Faulkner: Like Mauch said, it sounds obvious: design, build, and then test. But Mauch sees it all the time. People skip steps and they end up paying for it down the line.

Faulkner: I asked Mauch why it is that people are prone to missing these steps that seem like the fundamentals of creating a product.

Mauch: Because they’re not used to development, I think. They come at it from different perspectives. Sometimes they’re researchers, and researchers are never done researching, so the other part of that is you have to tear that away from them and say, “Stop changing it. Stop making it better. You can always make it better, but if you keep changing it, then we’ll never finish.” So that’s on the researcher spectrum on the business perspective, people are excited about what they’re doing and they want to get it to market, and they’re in a great big hurry. And often, it’s either, for the start-ups, it’s they have limited funds and they gotta get to market. With large companies, they’ve got mandates for revenue coming out of new products and so, “I need a new product to make those goals.”

Mauch: And so big and small, you see the same pressures for slightly different reasons. And so well-intended people get themselves in situations that can maybe wanna go forward, sometimes too quickly.

Mauch: The other part of that, too, is design is a really difficult thing. You start, in a lot of cases, with the proverbial clean sheet of paper, and you start putting some building blocks down of things you think are ready to go and some unknowns. And most people can get to what I call the 95% Solution, and they’ve figured 95% of it out, and they keep pushing off that nagging 5% into the corner, and they’re like, “Oh, well, that’ll come together, we’ll figure that out.” And if you’re not careful, that 5% can be your undoing, and be the thing that comes back to bite you in the end. So it really does take a lot of discipline, I think, to have the approach to not just assume that 5% will get better later. And for that reason, I’ve coined a term, which I think I’ve coined, maybe somebody else said it, but the Vertical Slice. I’m a big believer in the Vertical Slice.

Mauch: A lot of people will do A and solve that problem, and then B comes next, and they’ll work on that and solve that. Then there’s a C and a D and an E, and they just magically assume that as they progress, a solution comes and they move on to the next thing and life is great. But life never works out that way. A lot of times, you get to D or E and there’s some great big disconnect that causes you to go back and change the stuff you did before. So what I like to do with the Vertical Slice is think about A, B, C and D all at once, and in a very fast path through there, prototype or work with each one of those elements, so that they all work together and they don’t do everything that you need to do, but you touch on enough of them such that when you need to rely on them, you’ve kicked the tires already, and you know whether it is promising or not. And that helps to avoid big disconnects.

Faulkner: Mauch said that fundamental engineering, it’s just a part of the culture at MPR. And that attitude has its roots in the company’s heritage.

Mauch: We do some pretty fundamental engineering here, and it’s baked into the culture. The founders of MPR designed the first nuclear submarine, the USS Nautilus. So they had to … you can’t really prototype a nuclear submarine so well, you have to really design it right and then build it because it’s a pretty expensive thing to go tinker around with. And so I think that’s baked into our culture. First, we design it, and we know why it’s designed the way it is, and then we build it.

Mauch: And I remember specifically, we were working on an infusion pump project years ago, where we were in our design phase and going through other requirements, and figuring out pumps and tubing and sensors and size of bubbles and all the things that you do for that kind of thing. And we’d been probably on the job for a couple of months, and the client said, “I know you guys are working hard, but I haven’t seen anything go together in the lab yet.” And I’m really nervous because they were used to tinkering and prototyping and iterating, right? And I turned to the client and said, “First, we’re going to design it, and then we’re gonna build it.”

Mauch: And then the first prototype that came together on the bench worked quite well because we had all the fundamentals behind us. “Why are the pumps sized the way they are? Why is the tubing this kind of tubing?” And so on and so forth. And so it goes together better the first time when you do that way, and we used that early prototype to validate those models that we put together in the design phase. So not just cut, try, and repeat kind of thing. Believe it or not, a lot of development goes on that way.

Erler: We don’t just have a book, “Oh let’s open the book and figure out how.” These are all, almost all, first-of-a-kind problems where you really have to pick the problem apart and understand the basics, the first principles of the system that you’re working with, to understand how it could go wrong, and then think, “Okay, if that were going wrong, what would that look like? What would the evidence be?” And then you can see if it fits what’s been seen. So if there’s evidence that matches that, then you know you’ve got a theory.

Faulkner: Despite their analytical methods, Claude and Erler told me that there’s always a bit of nervousness when they first present a solution to a client. Especially when there’s a lot at stake.

Erler: I think you’re always nervous, yeah. You’re always questioning yourself. I think, to some level, it’s the fact that you’re always questioning yourself that leads you to question every piece of data that you come across, that makes it that much more rigorous a process.

Claude: I would say, we’re always a little bit anxious when we get into solving, trying to solve a problem that’s not been solved before, and you don’t know what the answer’s gonna be. But I think a big part of both managing that and ultimately being successful is the team. That you can always go and consult with another expert, subject matter expert, or just talk it out with somebody. You get enough really smart people in the room, combine intelligence and analytical capabilities with creativity, and you’ll always find a way.

Mauch: Yeah, the cool thing about working here is that there’s usually, we’ve been in business for 50 years, and there’s usually somebody down the hall who’s done something similar or has been exposed to something, and it can even be across industries. Whether it’s medical, power, or ships and so on. So the neat thing here, we did a thing for a medical device that was a cell expansion chamber. You seed it with cells, and then you put it an incubator and then you come back and you have many more cells than when you started with. But we had people that normally do fluid dynamics and nuclear power plants helping us design this cell chamber because we were trying to move fluid through there in a very uniform and distributed fashion. And so by us not necessarily doing that every day in medical, we were able to tie into our power business, who we have experts that’s all they do, is thermal hydraulics and fluid design, things like that, so it was really neat to tie the two sides of that expertise together and solve a problem.

Faulkner: The team at MPR is pretty clear. When it comes to rerouting a product development effort that’s gone sideways, it takes more than just following that solid foundation of basic engineering. At the end of the day, it’s really all about the team.

Faulkner: Thanks to the folks at MPR for speaking with me, and thanks to you for listening. For more on this and other newsworthy items in the medical device space, visit massdevice.com. Until next time, I’m Sarah Faulkner.

The post MPR: Getting medical device development back on track appeared first on MassDevice.

from MassDevice https://ift.tt/2HOE1ut