Episode Transcript
How do I get FDA approval for a medical device? How do I get funding? How do I sell a medical device? How do I? How do I? How do I? I’m Kayleen Brown, managing editor for DeviceTalks. We are on a mission to unravel the complexities of the medical device product development cycle. In each episode, we take a deep dive into a specific stage of this journey, guided by the expertise of senior medtech leaders who have not only experienced it, but have mastered it. This is MedtechWOMEN Talks. Dr. Rieger. Welcome to MedtechWOMEN Talks, the newest series out of DeviceTalks. We are here today at DeviceTalks West, October 18 and 19th, 2023, in Santa Clara. Really appreciate you spending some time with us today. Thank you for having me. Do you go by Dr. Rieger or Kathryn? You can call me Kathryn. Oh, great. Okay, perfect. Well, thank you, Kathryn. So I always kind of like to get context and really understand how you chose medical devices. It’s not an easy field, so kind of walk us through that. What led you to medtech? Yeah, I think, in general, I come from a family of doctors and nurses, and medical was very much a part of that. We’re all sort of influenced by some of our upbringing and what we’re used to and what we see. So I think that played a small role. But after I came out of undergrad, I did go through and worked in military first. And then after the first grad school, after my master’s, I went into the automotive industry. And both of those are pretty highly regulated, high stakes type of engineering and human factors, which is my field. And I had dabbled in med device here or there, so it was a logical next step. And it was a mix of hardware, software, plus sort of that regulated risk, plus the family tie-in. So it all kind of came together, and I kind of stuck there. The last 20 years or so. You don’t commonly hear military tech, auto tech to medtech. I know we’re pivoting from the conversation. A little bit. But, I think it’s important to really understand maybe some lessons that you took with you from those industries to medical devices. Are there any that come to mind? Yeah, absolutely. I think military taught me a lot about very long product development lifecycles, often with changing goalposts and very strict procedures that you had to follow and very unique situations that we had to investigate. I remember going up in a Blackhawk helicopter and doing my field research there, and it started to get you pretty excited about what we could do and the impact that we could have on society. So it was kind of my first flavor of that. And working on military programs, we have unfettered access to users, and you can ask them anything and make them do anything, which we can’t do in medtech. So it was a very fun and educational kind of start to it all. And then when I moved into automotive, I feel like it became more of a crossover into consumer and really as expectations. When I was in automotive, it was when in-car navigation systems were just starting to kind of come out on the market. And there were questions like, is it the multi jog or is it the touch screen, which is less distracting to the driver? And thinking about those user interfaces. And those are the types of problems that we were investigating. And that was really new, and it was evolving and thinking about consumers. And I think medtech is on a similar journey and how we got there. So I think that our expectations, and I was just giving a talk here, and I said, hey, ten years ago, nobody would care if I said the question, does using your product make you happy for a med device? Ten years ago, people would laugh at you. And now it’s becoming a reality because we expect that, because everyone’s got an iPhone or an iPad, et cetera. So everyone’s expectations have changed. So I sort of followed that trajectory. Well, let’s kind of focus a little bit about the medical device product continuum and your role. So outside of your specific title and working with intuitive, how would you define your role within medical device product development? Sure. My role is really, again, I’m kind of this glue between people and products, and no matter what industry I’m in. But within medtech, it becomes even more important because you think of it as an entire ecosystem of users. Right? We’re making products now for surgical care teams, but it’s all about the patient and the families and empathy and creating better healthcare outcomes. And so thinking about things from that holistic viewpoint is really what makes it different for medtech. I think that really speaks to how the medical technology landscape has changed and how it’s continuing to evolve. And you had mentioned just a second ago how we were asking, how did the device make you happy? Would have been laughable. I mean, it couldn’t seem more accurate. So is that more the kind of human factors aspect of building a product in med device? It’s the experience that we’re all collectively creating. So, yes, human factors is a part of that, and the human factors team ultimately measures that and helps drive the team to get to that. But it’s a larger design and engineering team that builds and strives towards that. Of course, safety and effectiveness are a given. We have to have that, and we continue to ensure that and demonstrate that. But when we start talking in terms of does it make you happy? What does that really mean and why does it matter for a med device, I think is the more interesting kind of nuance is that we know that performance degrades if we are unhappy or if we are stressed. There is scientific evidence that shows that we will be more prone to make mistakes. And likewise, on the flip side of that, if we are ensuring delight as we are using so that we feel good, then we are more efficient and we make fewer mistakes. And so it really does tie very directly into safety and effectiveness. It’s just kind of a new way of looking at it that happens to also match consumer expectations. Sort of an integration of physical health, mental health, emotional health, behavioral health. So all tied in together. Exactly. Excellent. So you’re proposed as the engineer in the broader landscape of the medical device product development. So at what point do you feel your role is kind of brought in? Are you brought in at the beginning from ideation? Where do you fall? Yes, I think all stages. Right. Really what we’re after is answering two questions. Right. The first one is, are we designing the right thing? And the second question is, are we designing it? Right. And there are particular engineers that specialize in answering each of those questions at different stages. So I think for me, and in my particular role, I start really early because we absolutely have to answer, are we designing the right thing? Is it meeting a need? Are we going after? What outcomes do we need to go after? Where are the problems from other engineers who are also good at answering that first question might say, I’ve got this awesome new technology and more of a tech push, but I think it’s really healthy to have a tech push, tech pull situation to answer that first question. And then, of course, I think it’s a little bit more well known. Once you get into the actual product development lifecycle, you know what you’re going to build. You have kind of your blueprint, and now you’re just optimizing that until you get to market. And that sometimes is a different skill set and a different type of engineer. But for me, I’m lucky I get to work the whole way across the cycle. So it’s in some ways this iterative process, in some ways of sort of saying that maybe my skill set outside of yours, which crosses the entire, of course, but maybe my skill set would be better served later in the product development stage versus earlier in product development stage? I think so. I think it’s also interest and comfort level and what questions you’re trying to answer or problems you’re trying to solve with the technology. But iteration is definitely key throughout. I have a feeling we’re going to pivot to the feedback loop here, but before we do that, we had talked about team and where you fall within this cycle. You come in pretty much when you’re needed at the beginning and throughout the stages when appropriate. Where and when you interact with the other R&D clinical. That’s where it gets kind of confusing. Yes. One thing I forgot to mention is that often at the beginning, small teams are a lot better. And then as you get towards the end stages, you can sort of break off into those small teams and it becomes this large team when you integrate, but it’s made up of a bunch of small teams because you want to move fast and you want to be able to toss away your ideas, and it’s a little bit fuzzy and roles cross over a whole lot more. Titles matter a lot less in those early stages, and it kind of feels like a startup because it is right. That’s really what you’re doing, is generating ideas. So it’s a little bit different there as opposed to later stages. 100%. Every role needs to be represented. Every time we try to do small teams because we want fewer meetings and we go up to that, somebody’s missing from the conversation and it ends up being an inefficiency. And we go back and say, we got to bring that person in. We’ve got to get together. So there are lots of cross functional teams that come together, and the key is really parsing out and figuring out what those small teams as part of the big team to keep that efficiency going. It sounds to me, and please correct me if I’m wrong in understanding this. Would you say maybe the engineering role plays more of a collaborative role throughout the cycle than perhaps like other roles like commercialization or clinical affairs? Do you feel like they are pretty central throughout the entire process because it’s bedside. We’re creating technology we can’t create without the engineers. I do think there are highly specialized engineer and just kind of saying engineer. We’re definitely generalizing across the board, and I get that, and that’s fine. But yes, engineering is critical from early stage conceptual. You got to make sure the idea is feasible that we can actually develop this. And there are other folks that are also trying to answer the other questions of is it desirable or is it viable? Versus, obviously, in the end, engineering is driving the show, and we don’t necessarily need regulatory until somewhere mid cycle to come in and say, okay, now that you guys have this thing, now we need to figure out how to get it to market. And that’s a little bit different pathway. So I would say we collect people along the way. We collect more and more engineers, more and more cross functional partners throughout the cycle. And it definitely takes a village. I was just thinking that, like, you’re making your tiny village. Yes, bigger village, depending the impact that you’re trying to make. So you said creating a device, which leads me to think about the actual development of the device itself, not just the concept, but actually having a tangible something you can hold and use and make an impact. So how do you go from sort of the concept, the ideation, to a physical product in hand? And that’s a huge question, and we can spend a week on that question, definitely. But if you could high level it for us, how do you start? Where do you go? There’s always things. There’s always something, right? Whether it’s phone core or sketches or drawings or some whackadoodle, off the shelf, concocted idea, because it’s all about communication and crafting our story together. And everybody needs to sort of rally around a concept, an idea, to be able to respond and to be able to provide input. And so I don’t want you to think we wait until the end to finally build it. That’s an unhealthy product development lifecycle, right? We sort of iterate. And you could walk into our offices and see 15 different versions that we didn’t use. But if you line them all up, you could see the evolution of how we got from there to the end. And, of course, that’s what’s fun about the early stages, why you have fewer people, fewer resources. So you can toss that. And then as you move and get more and more sophisticated throughout, and we start real testing. We’ve done tests on puppets, where we’ve got people under a table moving arms, or we call it wizard of ozing, right? Where it’s just the man behind the curtain user pushes a button, and then we’re like, oh, here this happens. And we go from that to, obviously, once you engage more and more engineering resources, you can have an actual build with actual software instead of man behind the curtain pushing buttons. Blown away by that. Did you expect when you came from automotive and military that you’d be playing with puppets? I’ve done it, actually. I’ve been lucky to kind of do it all my career. Really? Yes. A long time ago, when I started, I worked on an ATM, and we literally was a box, and we literally pushed money out the front. But it looked like, felt like to the user that we were testing it with, felt like a real ATM. I don’t know why, but I think maybe it’s my theater background, but I find that thrilling. So thank you for sharing. We still do it. We put cardboard on the front or we’ll put an iPad, and then we can quickly iterate using prototype software or something, and we’ll just put a foam cut out and people think it’s real. It’s real enough to establish the objectives that we’re looking for. Would that be part of sort of the validating and testing process? We definitely aren’t validating the puppet concept, but definitely testing. And we use a concept and it’s kind of resource and it’s best practice called minimal viable prototype. So what questions do you need to answer? What kind of prototype do you need to answer that question? So, puppet is not always the best, but if you’re just looking for some conceptual type of information or directional or can this work? Do I have enough physical space around me for this concept to work in our world? Are there going to be arm collisions? Are people going to bump into it and things like that, versus late stage, obviously. And then when you get to validation, you got to be pretty close to your final product because you’re validating that you designed it. Right. That is really important consideration. So then let’s talk validation. So how do you ensure this device functions as intended and is safe to use? That goes through very rigorous v and v. So verification and validation. So, obviously, in medtech, we take document control very seriously. Documentation is a part of the development process that if engineers come in from other sectors and come into medtech, they are very annoyed by the amount of documentation and tracking that we do. But there’s a reason for that. So when you get to the end game, you can trace every decision, every change. And we have to go through very significant change management to match our regulatory quality processes. So by the time we get to VNV, we verify that all of our requirements are contained within the device, and then we validate and demonstrate that safety and effectiveness piece. Right. So that’s the piece where we bring in users and we put them through. We know what all of the critical use case scenarios are that determine whether or not that device is safe and effective. And we have full care teams, full simulated use on the clinical end. We’ll also do animal studies and cadaver studies, and we’ll run the gamut all the way up to and including clinical studies. And we’re bringing clinical affairs. You mentioned earlier, they come into play and we do all of that pre market validation. We were saying iterative, but I think. Another way of putting it would be that there’s a lot of checks and. Balances along the way, especially in med tech. And that leads me why do we do that? Regulation. So let’s talk about regulation for a bit. Why do we do that? Patient, patient people, family safety, but yes, regulation as well. I think it’s important to emphasize exactly what you emphasize. Did you have anything else that you’d like to elaborate on in terms of focusing on patient safety and the families experience? That’s core of why everyone gets into Medtech. And I think that it’s a core value that we all share and it actually brings those giant villages together because we’re all focused on that as our aim and we all have to have empathy for our end users and for our end. In this case, patients don’t actually use our device, but they are the recipients and the beneficiaries of the device. And I think that’s key and important in how we make decisions and how we make trade offs throughout the development process and regulatory should hopefully just be a check at the end, right? That says, yeah, we got it right. And we feel really good about it. So encouraging. And I want to circle back, even though it sort of divots a little bit away from the medical device product cycle. You talked about why medical technology, this industry is so special, and the commonality across everybody, as many people as I’ve met, certainly in 16 years, all the stakeholders, we have this shared vision, this shared goal, and I think of medtech as very familial. And once you’re in it, it’s impossible to leave because it’s infectious. The passion and this drive to move health forward and to do it responsibly and to do it in a very nurturing, considerate way. I’ve never experienced that elsewhere, and I’ve been here 16 years strong, and I’m never leaving, that’s for sure. Yes, I agree. When people ask me, what do you do for a living? And I answer, oh, I make things easy to use. And then I correct myself and I say, I make things that matter easy to use. And I think that’s really key to everything that you just said. And I feel that our entire team also echoes that sentiment. I’m going to go back through our transcript of this interview later because there’s so many beautiful sound bites and taglines and mottos that I feel like will resonate throughout the industry and the other collaborative teams because I hear this all the time. And we were talking at the kind of the beginning, the intersection of consumer tech and medtech being sort of a newer, novel idea, I think those kind of phrases. And this shared passion and this shared goal is what brings the consumers and every person, if you will, into the interest in medical devices. And a lot of our users are also because we all have that shared goal, I would say in medtech we do a lot of testing and we bring them in and we bring a lot of stuff out the field and we get a lot of opinions. And they’re our partners. They are our engineering partners as well. A lot of them come from an engineering background and have great ideas and understand where we’re coming from. But it really makes our job easier and it’s really cool and hard to find somewhere else. It is really cool. I’m such a fan girl, 16 years going strong. You had touched a little bit earlier, Kathryn, on the different types of engineers and how for this conversation we’re being very general with the term engineers, but I want to talk about the significance of human factors in particular, and user research and development near and dear to my heart. Well, then it’s laid on me. So what do we need to know? Yeah, so our job is to make things easy to use. We are the folks at the company who are ultimately responsible for demonstrating that safety and effectiveness. And so we start very early stage where all we’re doing is looking for those design opportunities, looking for the opportunities to better health care, to improve human performance, and to collect comments and feedback. And we’re constantly iterating to circle back on something we talked about before. So it can be as simple as watching cases, talking to people, observing. I think what’s key in med device for us. What we add is that, and I learned these phrases a long time ago in human factors, but know the user and the user is not you is an important one that I repeat often to our engineering team, because sometimes when you’re really in it and subject matter experts, and it’s hard to break them out of that, to remind them. And the other is an n of one is better than an n of none, meaning it’s better that I talk to one person and bounce this idea off than not. And so I collect a little bit of data to help back this up. We also can kind of moving on that data driven decision making or evidence generation. We can get a lot more sophisticated than just going out into the field. Obviously, we can run laboratory experiments, and we can talk about measuring cognitive load. We have all sorts of cool sensors and cameras and can collect all sorts of data about how your body is moving and ergonomic data and proficiency and workflow efficiency. And we do all that as we get deeper and deeper into that product development lifecycle. And we run usability studies and run people through. So we do large scale surveys to get directional information. So lots of different ways, but the common denominators are people and data, and that’s kind of what makes, that’s our contribution to the product development lifecycle. People and data. I like that. All right, so walk me through how crucial feedback is from clinicians and end users. And then in addition to that, how is it integrated during the development process? Sure, it is crucial, first of all. So I think that we are all very intelligent, very educated, and we can use existing sources, we can use our knowledge, we can collect all of that information and make pretty good educated guesses. And I think it could get us about 70% of the way there. But sometimes that extra 30% could derail that 1st, 70%. Right. So it’s always good to have these check ins. One we talked about early stage, make sure we’re solving a problem from our perspective, or there’s a need for this device. And so just checking in on that super early stage, you don’t even have to have a concept yet, you’re not even using it yet. Fast forward, kind of the mid stage, you’ve got some prototypes. You’re deciding between different input devices, like we talked about earlier. Is it a touch screen or is it here? Which one is faster, which one is better, which one will lead to better clinical efficiency, et cetera. And so we bring in people and we test that out versus all the way at the end stage where we’re ready to say, okay, we think we’ve done it, we’ve built the best thing we can, but we’ve got to validate this. And definitely for regulatory reasons circling back there, we have to demonstrate it with external users and put them in real life situations to pressure test all of the decisions and gut feel that we had and decisions that we made along the way. So it’s absolutely critical. I want to continue this discussion, but we have limited time, so I have to, unfortunately, pull us away. At the beginning, we kind of touched on how the landscape is changing and how generative AI machine learning has democratized AI for the mes of the world, if you will. So I think it’s important to really kind of talk about how that might shift your role, your responsibilities. So how do you see it shifting your role and your responsibilities now? And how do you see it shifting in the future? And when I say future, it could be next month. That is fair. Predictions keep changing. So first, we are data driven, right? We said that was one of our pillars. Essentially, AI is more data, and it’s better data, and it’s informed data. And so from our end, we kind of talked through that whole product development lifecycle. It can expedite it for us, because now we, and we are today collecting. I talked about some of these fancy sensors and all these data points that we can collect. We can start to build predictive models for how humans will behave and how they will interact with the devices, so that not to completely eliminate the need to bring in some of those external users. But in medtech, it’s a tough ask, right? We’re working on a lot of cool stuff, and I can’t bring in users every day. I’m pulling them out of hospitals now. I’m kind of going against that initial aim of ours, which was to better health care. I’m pulling full care teams out of hospitals to have them come play in my lab and help me build things, which is important. But if we can lessen that burden, then I think that our job will shift more towards solving the really hard problems that AI can’t solve. And AI can help us get to that end answer a lot faster. Giving us more room and more time to be more human? Yes, and humans will always be humans. So I have learned that through many, many years of usability testing devices where I think that we are 99% of the way there, and you put it in front of people and they do something that is totally not at all what you expected, and you’re like, oh, yeah, all right. And that is a different part of engineering, because most engineering tests, you’re testing reliability, you’re testing durability. Every time you drop it, you can count, you can quantify. Humans. Never. I think that might be the most accurate thing I’ve heard all year. Any last thoughts, Kathryn? No, just excited to be here, excited to share the journey. So thank you. Dr. Kathryn Rieger, thank you again for joining us on MedtechWOMEN Talks. It has been a thrill to spend time with you, and I hope that I can have a follow up conversation because every question that I asked led to three other questions that I want to ask. So thank you again for your time. Thank you very much. And that’s a wrap. Thank you so much for joining us on this episode of MedtechWOMEN Talks. Please share this episode on social media to your coworkers, to that new hire who’s overwhelmed by the nuances of Medtech, and to that seasoned executive who is looking for a way to educate and inspire, please like follow and subscribe to the DeviceTalks podcast network to never miss an episode. Our next will feature Dr. Vivian Golfin, Senior Associate at Intuitive Ventures, from the perspective of the Venture Capitalist. But before I let you go, I’d like to shout a big thank you from our figurative rooftop to our sponsors, Aptyx, Catalyze Healthcare, Confluent Medical, and Cretex. It is only with their support that We’ve been able to create this incredible series. Want to join the best sponsors in Medtech? There’s still time. Connect with me on LinkedIn, or reach out to our DeviceTalks editorial director Tom Salemi. Once again, I’m Kayleen Brown of DeviceTalks, and we’ll be back soon with Dr. Vivian Golfin of Intuitive Ventures.
