Building Safe and Usable Medical Device Software: A Conversation with Neeraj Mainkar

Transcript

Shane Hastie: Good day folks, this is Shane Hastie for the InfoQ Engineering Culture podcast. Today I'm sitting down with Neeraj Mainkar. Neeraj, thanks for taking the time to talk to us today.

Neeraj Mainkar: Absolutely, my pleasure.

Shane Hastie: My normal starting point on these is who's Neeraj?

Introductions [00:50]

Neeraj Mainkar: Sure, great question. I'm currently the VP of software engineering, and advanced technology for a company called Proprio. We are a medical device slash AI company that's working on coming out with a navigational device that helps orthopedic surgeons ensure better outcomes in their surgery. My background, I'm actually a physicist by training. I have a PhD in computational condensed matter physics. And my last 28 years, you could probably divide that up into two broad pieces.

First 14 years of my career we're in a small defense contracting forum. We did contract work for the army and the DHS, where I was doing a lot of physics-based simulations for a branch of the US army. After that, around I would say 2010, 2011 is when I got into medical devices. And I've done a lot of different range of medical devices, starting with neurological devices, infusion devices, did a stint at BD doing informatics for a big microbiology lab software. And then doing a surgical robot, and then now of course doing navigational devices.

But early in my career, I guess you'd say, I became as I was building these tools, and products, and software, and I became quite passionate about not just advanced technology that comes with the territory of being a physicist. But also how it can help to make lives better, but also importantly that whole process of how do you create software, especially software that is safety critical, mission-critical, especially in the healthcare space.

And how do we ensure that the technology that we bring to surgeons or other people in healthcare is safe and is effective, which is obviously not only required by the FDA and all other notified bodies, but also high quality and most importantly is intuitive to use with as little cognitive load on the user as possible. As you can imagine, that has been an ongoing challenge, and that's what I'd love to talk about today.

Shane Hastie: In the realm that you're in a software bug can kill people, how do you ensure the technical quality of the product? Let's dig into that first.

Guidelines and regulations intended to ensure that software is safe [03:20]

Neeraj Mainkar: Yes, but this falls into the category of how do you make sure that the software is absolutely safe? So that's where the design controls piece of the FDA guidelines and regulations comes in. Because those regulations are put out there to ensure that medical device companies like us follow certain very, very strict practices in our method of product and software development, so that we ensure that the device that we ultimately produce is safe and effective. Now, what does that actually mean? That means following a documented process.

It's a very famous line amongst medical device workers is that if you don't document it, it didn't happen. So you document everything. It has to be a repeatable process so that you can ensure that you can work your way back to finding out where issues may have happened. So the process has to be documented, it has to be repeatable. And then you have to apply all of the tools in your trade to ensure that you are testing your device as widely as possible, as much in detail as possible.

And making sure that you cover as many different types of workflows that your device is going to be involved in as possible. And this is where some of the surgeon-related testing that I want to talk about comes into play. Again, to make sure that the device is safe, you got to have a very well-defined process that's repeatable. You have to document everything that you do. And then you have to use all the tools in your trade to ensure that you're developing your software in a way that actually prevents having bugs in them to start with. So basically making sure that by design your software is as free of bugs as possible. And then there's a big stress on verification and validation, making sure that you verify the requirements of your device.

And then validation in our world is extremely important, and has a very special meaning, which means you have to make sure that a user group actually tells you that the device that you built actually serves the purpose for which it was built. And so those are basically some of the methodologies that we use to make sure that the software does not contain any bugs that might, as you said, kill people.

Shane Hastie: This is the antithesis of the “move fast and break things” that we hear in a lot of our industry today. How do you instill this culture equality in your teams, and in the people that you work with?

Instilling a culture of quality [06:02]

Neeraj Mainkar: Yes, that's a great question. So one of the main things that we always tell people is that medical device is really a very, very unique field in software to be in. You have to feel that responsibility, and the seriousness that goes with creating something that's absolutely safety critical. So training becomes a big part of a new engineer's life in a medical device company. So as soon as they come in, you have to first make sure that they're trained on all of the regulations, and what is expected of them in terms of documentation, in terms of attention to detail, in terms of unit testing, in terms of integration testing, and in terms of overall testing. You cannot test enough. It's kind of like the adage that we always use. You have to make sure that you are using best practices when you're developing code to ensure that you have not let a bug creep in.

Second, it's basically making sure that the people that you hire are obviously good at their craft. Now, you would say that, "Well, that applies to everybody". But as you can imagine, that applies especially on people that are working in something like medical devices, because you absolutely want to make sure that the people that are working on your systems are absolutely the best of the best, that are very, very good at what they do. And so quite frankly, the hiring process can be pretty long and arduous. So we want to make sure we have the right people, and when the right people come in, we want to train them.

And then periodically always keeping this north star in everybody's mind about what we're doing this for. One of the sort of informal example that I always give to people is what I call the mom test, which is you have to be yourself confident about the fact that this device that you're working on may someday be used on a person, right?

The whole point. No, would you be okay with your mother, or replace your mother with anybody else, with some loved one in your family? Would you be okay having this device at the other end of your loved one? If the answer to that is no, then you know what you have to do. You have to continue to work hard to make sure that the device is safe, and it's not likely to be misused, and it's not likely to throw up any kind of errors. So those are the key features of how you make sure that people understand the seriousness of developing a medical device.

Shane Hastie: So focusing on the skills, giving people that clear understanding, the training. If you were to profile your engineers, who are they?

The attitudes and skills needed for medical device software engineering [08:55]

Neeraj Mainkar: They come from all varied backgrounds. Typically, you don't just hire 10, 15 year experienced people in every single one of your slots. What you try to do is take a diverse demographic. You want people that obviously you want in key positions, people that are experienced having done medical devices before, and have seen the circus, and seen the challenges, and can foresee what to do and what not to do. And then they also serve as excellent mentors because me personally, I can't train every single person that we hire. So what I normally do is I will always hire in key positions like principal architects, test managers, and development managers, people that actually have had prior medical device experience. And then when we go about hiring engineers that are actually going to develop the software and testers that are going to actually test the software, that's when we try to cover the full spectrum of types.

Obviously, they all have to pass a certain level of technical knowledge, so we always have tests for people. We sometimes give people small little projects to do, nothing super burdensome, but absolutely making sure that they can do a trial problem for us, and then convince us that they're actually good at what they do. Then the other part of course is the attitude. What is your approach to software development? One of the things that, and this is going to be sort of, I'm going to get on my high horse a little bit here, is where software often because of the young age of software engineering as a field really, has suffered somewhat from this issue that a lot of people can pick up software development. You know what I mean? You can pick up software development if you're reasonably smart. You don't have to go to school to be... Unlike a mechanical engineer, for instance, right?

To be hired as a mechanical engineer, you actually have to have a degree in mechanical engineering. In software, you will notice that that's not always necessarily true. People come into software through many, many different fields, many of them being self-taught. So what you have to quiz on them is how methodical and how "engineering" is your approach to software engineering.

Are you laissez-faire? Are you the cowboy programmer who wants to just rush off and start building stuff, and start coding or are you methodical? And that is also one of the things that we try to inculcate in our employees, in our engineers is that medical device software is not like gaming software. You just don't go start building stuff. You have to follow a process. You have to, surprise, surprise, wait and make sure that your architecture is actually well-defined, and actually been vetted before you start coding something.

Those kinds of really rigorous disciplined approach to engineering is something that we quiz people on, try to find their attitudes. And then something that's obviously common to any profession is how well you work well with others. Yes, software sometimes engineering suffers from their misconception that people and programmers tend to be loners, and they just want to work by themselves. It couldn't be farther from the truth, especially not in medical devices.

Because you have to work cross-functionally, not only with other software engineers and testers frankly, but with people from quality, people from regulatory, people, from hardware, people from systems. You have to work together. And so having that cross-functional approach to things, understanding that this medical device, the software that I'm building is part of a bigger system. And understanding your role and how you're related to systems engineering is very, very key. Some of it you can't always tell from interviewing people, but some of it you can engage by just asking people their prior experience and stuff like that.

Shane Hastie: So that's the safe side of the equation. You said that there's safe and there's usable, and that there's a tension between them.

Neeraj Mainkar: Absolutely.

Shane Hastie: What does usable mean in the realm of medical device software?

Usability in medical device software [13:11]

Neeraj Mainkar: Well, one simple definition of course is how intuitive it is. We use the word intuitive a lot. In fact, one of the most famous companies in our field is something called Intuitive Surgical, as you all know, the Da Vinci, robot makers. So intuitive is very key. It should be as natural, especially if you think about a workflow, where I go for when I click a button here to the next step that I need to do, should come in fairly naturally with as little training as possible. That to me is the pedestrian definition of usable.

The more technical definition might be, and again, I'm not an expert on 62366, which is the standard for usability in medical devices. But the idea is how big is the so-called cognitive load. Now how do you measure a cognitive load? Now this is done by doing, and we can get into the details of that, but when you do usability testing, you do what's called formative testing.

Ideally what you do is to make sure that you let the user in a separate room, use your device with as little help as possible from anybody that knows. And then just see how quickly by either reading a user manual or by just simply playing with the software, how quickly does that person pick up on what needs to be done next. And how quickly do they feel comfortable using the device.

So there may not be an objective measure of that, but you can tell how somebody can be... Actually, there are objective measures in the sense that you can find out in these formative studies, how many errors did the user make? Did they get how to use this device with as little guidance as possible? So these are some of the ways we define what usability is to your question.

Shane Hastie: So designing for that low cognitive load for that high usability or intuitive usability, how do you go about that?

Designing for low cognitive load and intuitive usability [15:13]

Neeraj Mainkar: That's the part that I recently discussed in an article that I wrote. To say that we want to make the design user-centric, you absolutely have to then by default involve the user. So if I'm going to make a navigational device that I'm hoping a surgeon would use, I need to absolutely involve surgeons in the design of the device. And what that means is that they can't be an afterthought at the very end, they have to be involved from day one.

As soon as you're ready to start designing your front end, you have to involve them, do a lot of mock-ups and get feedback. And this continuous feedback loop has to be set up, and we've been doing that now even at Proprio. We always bring in surgeons periodically to come and play with our device, use it, and then give us honest feedback as to how well they think that the usability of the device works.

Obviously, some of the challenges here are engineering, as anybody who does this knows even usability is a multi-legged stool. If you try to make one leg too long, and not make sure that the other legs are also competing in kind, you might end up sacrificing a lot of the other equally important features of software just for the sake of usability. So while usability is obviously front and center, but we also need to make sure that other aspects of that software design are also taken care of, such as things that people like users may not think about, but performance. This is something people realize when they start using it. But if for the sake of making things usable, if we make the work go way too long or way too slow, I'm sure that'll become a problem for users as well, and they'll complain about the fact that, "Well, Yes, it's easy to understand, but why is the performance so bad?"

One other aspect of it is maintainability. If for the sake of usability, if we make the user interface so complex and so distributed, then maintaining it can also become a challenge. So you have to strike all these different factors just with the right amount of balance. Obviously at the end, user experience and usability is trump, but these other factors matter as well, and that's where the push and pull in the design happens. But again, keeping surgeons in the loop, keeping users in the loop and having them test your device, use your device, give you continuous feedback while you're still developing is key in making sure that what you end up producing at the end is actually something that the surgeons want, and can use.

Shane Hastie: Given what you're describing there, both in terms of the safe side of it and the usable side of it, the other thing that we're used to in the software we deal with on a daily basis, those of us who are not in the medical device space, is that this software can be updated and enhanced and improved sometimes on a daily basis, sometimes more frequently. How do you in this environment handle the upgrades and the enhancements to products that are already out there in the marketplace?

Upgrades and enhancements [18:37]

Neeraj Mainkar: That's a very, very good question, and this is something thankfully over the years, regulating agencies such as the FDA, and the world over have started to recognize the malleable nature of software, if you will, and knowing that software can improve over time. So the FDA has an actual name for it, which is called post-market surveillance, right?

So this post-market surveillance is a responsibility that the FDA puts very seriously on medical device makers like us to say, "Okay, your job doesn't end when you just finished your device, and then you put it out in the market. No, there is a big, big responsibility for you guys to keep doing post-market surveillance, monitoring how your device is being used, keeping a well-defined catalog of issues, bugs of course.

But also getting some feedback from users saying, 'Hey, how would you like this device to be improved? What are some of your pain points that this device is not going to be solved, some pain points by making this device for you, but obviously may have created some new ones. So what are those? How could we continually improve your user experience?'" Because the good news is in software that's actually entirely possible, you can continually refactor design.

In some cases it's easier said than done, but certainly it is well within the realm of reality that you could continually improve on design, and put out maybe not as fast as some of the non-medical, and non-safety critical softwares out there. Sometimes even do updates every day. Certainly we don't do it that frequently, but certainly within a frequency of three to six months, there is no reason why a medical device company like ours can't keep putting out its software improvements. And how that happens is obviously through a feedback loop even after release. So we have a channel for everybody to be able to reach out to us, and tell us what the issues are with the device that they're using.

Shane Hastie: We're in the era of AI.

Neeraj Mainkar: Yes.

Shane Hastie: What's happening with AI in your space?

Applications of AI in medical device software [20:49]

Neeraj Mainkar: So AI has, apart from just the buzz that's been going around in making actual products that are AI based, and we are also one of them, we do have a large part of our device actually is very much governed by AI. But in the realm of what we're talking about here right now with usability and safety, AI is already making a huge difference. There is not a single developer right now, even in the medical device space that doesn't use some form of AI, whether it's ChatGPT or some other competing tool out there to actually even create code for devices. That's actually happening.

We are starting to use AI now for automated unit testing, because you can actually ask some tool like ChatGPT to even create unit tests for your code. It can do that faster and with more accuracy than a human being can. One of the things that we recognize, and this may sound counter to the idea, oh, that we need more and more software engineers, that when you recognize that bugs in software are created because of the human element in software development.

It is because a human is developing and because humans are prone to making errors is why we end up having so many bugs in software. That's just the nature of things. But the more you use automated tools such as AI and all that to create unit tests, the more you will ensure the fact that these things work better. Because again, it takes that human error element out of the process.

We haven't done it yet so far, but it is in our roadmap to start using AI to do VR in the virtual reality-based, simulation-based testing. If you use AI correctly and usability testing, you could analyze user interactions using AI tools. You can identify usability issues using AI tools. You can even have suggested design improvements using AI tools, and that's actually being done. Those tools are being built as we speak.

You can even have AI predict potential user challenges. You could even have AI create certain user workflow alternatives that you may not have thought about that help you in making sure that, "Hey, you didn't think about this particular alteration to the workflow that you thought". And it just expand your universe of system-level usability testing of the device.

So frankly, the one sentence answer to that question would be the sky's the limit. We're just getting started with using AI all across the board, all across every layer of software engineering.

Shane Hastie: What's the question I haven't asked you that I should have done?

Other aspects that need to be considered [23:37]

Neeraj Mainkar: I guess talking more in terms of what the challenges are. We touched on complexity versus usability, but there are many other factors too that we haven't talked about, right? Usability goes head-to-head with also a diversity of user base, right? The world will be so much simpler if you only always just had one kind of a user, especially in medical devices. What you have to sometimes worry about, often worry about is, okay, so I have different user profiles if you will. I've got the surgeon that's going to be using my device, but it also could be a med tech that's sitting there basically doing some pre-op planning that is a different user. There could be somebody like an OR nurse that could be using the same device that's a different user". And each user has to have a similar good and easy experience using our device.

So that can be pretty challenging because sometimes you create workflows that are catering to this side of the audience versus that side of the audience, and it's striking that perfect balance where you cover every type of user equally well is always an ongoing effort.

Another challenge that we don't always talk about but is right there is that you can try to make your systems as usable as possible, but sometimes if your systems are supposed to be integrated with other older legacy systems, it can limit your ability to some extent. I'm not saying a lot, but it can sometimes govern how much flexibility you have on your device, especially if your device is part of a pretty complex workflow where there are other devices, and other software systems that are being used to do other parts of pretty complex workflow. You know what I mean? And so that can be a challenge.

Another challenge of course is this is more of an internal challenge for people like me, which is our world as you mentioned earlier today. There's just so much technology and new tools and tricks that keep coming into our view, and in our field of view so to speak. And sometimes being smart about all this is also making sure that we don't keep following the new shiniest tool that's available out there, trying to focus more on user needs rather than leveraging all these exciting new technologies.

As engineers we all want to play with whatever's out there, and want to include that in our device because we just want to play with it. And having to control that urge, and making sure that the user need is the prime thing. And whatever else you do should be in service of that, and not the other way around where, "Oh, there's this great new technology that exists out there, and I want to figure a way out to use it".

Kind of like that how a hammer everything looks like a nail situation. You want to wire pick that, and that's more on the engineering side. And then one thing that's recent I would say is sometimes these AI-based tools can also come with their own challenges. Specifically, what I mean by that is there's just so much data overload now because modern software often in the interest of trying to give surgeons or any other users as much information as possible. Because now data is available everywhere and databases are cheap, and so easy to just store so much data.

But sometimes happen that there's just an overload of data that users are now having to look at. And while on the face of it, that may seem like a great problem to have, it can also be overwhelming and can be confusing if it's not arranged, and is not presented properly. So information architecture, data visualization, and contextualizing what you're seeing in any a software interface has become much more upper responsibility for people in my place, or engineers in developing medical device software because that is very much a thing.

There's so much data. As an example here in Proprio, we collect literally a terabyte of data every time we do a surgery. And now that's a lot of data. It's on us to now use that and present that in a way that's not overwhelming to the surgeon and other users and also useful. We don't want to go the other way and either where we suppress any kind of data, that's not what we want to do either. We also want to be striking the right balance between giving them the right type of data that they can then use to do decision-making and hide the rest. So those are some of the other challenges that I think people may not be thinking about when you're trying to develop something that's very usable.

Shane Hastie: Neeraj, wonderful insight into the world of software engineering in spaces where a bug can kill, and where you are truly making a difference in people's lives. If people want to continue the conversation, where can they find you?

Neeraj Mainkar: You can reach me [on LinkedIn] at nmainkar, that's basically my first initial N of my first name and my last name, which is Mainkar. You can write to me, and happy to answer any questions anybody might have.

Shane Hastie: Thank you so much.

Neeraj Mainkar: Thank you.

Mentioned:

• Neeraj Mainkar on LinkedIn
• Proprio