β€Š πŸ“ Introduction and Host Background Have you ever had an idea for a physical product that you just knew had the potential to change the world? Maybe it was something you dreamt up in your garage or a solution to a problem you encountered in your daily life. Whatever it was, you knew it was a winner. If only you can turn that idea into something... You are not πŸ“ alone! Countless entrepreneurs and innovators have stood exactly where you stand filled with passion and drive, but unsure of where to begin, and that's where "The Builder Circle" comes in. My name is Sera Evcimen and I'm a mechanical engineer by trade. I spend my time helping hardware, founders, and teams through my startup consulting company, Prateek. I've had the privilege of working with numerous hardware companies that are passionate about solving some of the biggest challenges in the world. And I will be your host as we explore the exciting and complex world of hardware development. β€ŠWelcome to the builder circle today. Guest Introduction: Alan Cohen I have a very exciting guest. His name is Alan Cohen and he is the author of prototype to product a practical guide for getting to market. He is. Very much a master in my mind on medical device development, and I'm so excited to talk to him about I, I have him on right now, so I'm very excited to talk to you, Alan, about med device design and the entire product development process that's associated with it. So welcome to welcome to the podcast. Thank you, Sarah. Thanks for the kind introduction, and I'm very excited to be here. Excellent. Alan Cohen's Background and Experience So that the listeners know who you are and what your background is and what you focus on nowadays could you do a little bit of a rundown on that and introduce yourself? Sure. I am a systems engineering manager who specializes in medical devices. My background originally is in electrical engineering and software. These days, I I've worked on quite a few different types of medical devices over the last bunch of years, too many years. Most recently for the last 10 years or so, I've been specializing in radiation therapy devices, and in particular what are called proton therapy systems and leading, various types of projects for new product development, adding features, things like that. Excellent. And I was looking at your background and we've talked before. Have you also started your own company and done your own product at some point? Yes, I've been involved in, let's see, how many startups? So I started one startup with a couple of doctors and another couple of. Efforts that I've been involved with early on, but wasn't, the prime instigator. That makes sense. Challenges in Medical Device Development The reason I like to point that out is because I feel like a medical device specifically because it's highly regulated. There's a lot of compliance and it's a complex really field and application to get into. It's sometimes giving advice on that too. people who are trying to build a startup from it. It some advice doesn't transfer if you're advising like bigger companies, but if you've been in the really like hard part of starting a company and starting a product or working in teams that are doing that it's just like very relevant. So I, I like to poke at my poke at my guests to say you've done this and you've seen the pitfalls and you've seen the kind of difficulties associated with that. Oh, yeah it's very different. Development in a large device companies versus startups is a very different thing. So it's good to point that out. Absolutely. Okay let's start with the, main question that I'm very curious to know about because I've personally never worked in med, med device. I'm not trained in it at all. So I, this is this is a podcast episode that definitely is a little bit outside of my personal comfort zone because I want to make sure that I'm asking the right questions and I'm also learning. So we're going to learn together me and the listeners. In, when looking into how how to develop medical devices, how is, how does it differ from just plain old hardware development? What should builders of medical devices do or think differently than any other hardware application? How should the approach be different? In, in a large sense it's not so much different. Basically. The big difference, as everybody knows, is there's this thing called the FDA, or in the EU, you've got regulatory bodies over there. In any country, you've got regulatory bodies of some sort and those people are important stakeholders that you have to keep happy. So it's, you've got this new stakeholder and. I guess a couple of things come out of that. One is that they want to make sure that you're following good engineering practices. And in fact, that's the thing that they're most interested in for most types of development is they want to make sure that you do what you're supposed to be doing anyway, in terms of the development process. And in addition, they will have their own requirements around things that you need to do to prove safety and efficacy. But, day to day, it's not so much different than doing any other, developing any other sort of device where it's really important that it works properly. Yeah, I guess the application itself has, higher stakes, right? Because at the end of the day it's going to potentially determine how people go about their lives and how they think about their health and all of that I understand that the hardware itself is At the end, when you boil it down, it's still full stack hardware. But everything surrounding it and the surrounding value chain is slightly different and how you approach it differs because of it. I guess starting from the first first trial at going into MedDevice, I feel like the first thing any hardware entrepreneur or entrepreneur in MedDevice would think about is, Who what is, what application are we, have we identified? What is the problem we're trying to solve? Identifying a Hardware Medical Application Need So what do you feel is the best way to identify a hardware medical application need? Do you talk to doctors, researchers, or companies, or hospitals? How do you go about that? Hearkening back to your pointing out that doing development in large companies is different than scrappy startups. I guess let's start with the large company scenario first. So that typically the new product will be something that. The company is already some type of product companies already selling. If they're selling EKGs, they'll want some new EKG and they've got feedback from the market, from their marketing folks and sales folks, and they've put together some new ideas about what they want. So that's one type of situation, but in terms of startups, which I know is the focus of this program that's actually an interesting question. From what I've, from what I've seen, the successful efforts have come from engineers collaborating with clinicians, and it's useful, I gotta put it, it often comes from relationships between engineers and clinicians. People can bounce ideas back and forth because clinicians have certain ideas about what they want. Engineers have a hopefully a good idea of what can actually be done. And then you iterate around coming up with things that are something that might be really useful for the market. In terms of the clinicians, typically, it's working with. The doctor at the research hospitals, so those top level docs to the people who give the talks to, medical conferences and write the papers and things like that. They have a pretty good eye on what's happening and then if you're, once you start working with them on an actual product, the people can get the word out to the market about what's about, Hey, here's this new thing and it's great and everybody should use it. It's almost starting from the field and working backwards to the hardware development. There's also the scenario where, you know, and actually this is not uncommon where some technologists come up with something that they think is a great idea and it usually is a great idea. There are so many I got to put this, there's a lot of different needles that you need to thread in order to get from, Hey, this is a cool idea to this is on the market and doctors can use it. Understanding Reimbursement and Business Models So one thing people often don't think about is reimbursement. So doctors tend not to use things unless there's a reimbursement for it. So you may have some idea for something new that could help a patient in some way. But if there's not an obvious reimbursement path, that becomes a much different thing than, Hey, here's this cool thing and it addresses something we're already dealing with and getting reimbursed for it. But here's a better way to do it. And the clinicians will know that a lot better than the technologists will. That is super interesting because I feel like, with a startup, you're not only building a product, you're also building a business model. And when you're building that business model. You had to take into account the very hairy medical and like insurance and all of that into account. Yeah, I would say that's actually the bigger challenge and the bigger risk than is this a product that people think is cool, right? Because you're not going to consumers and you're not just trying to change your mind. You're selling this into a business that has very specific rules around how they can get paid and what they can get paid for. Especially if you're genuinely I feel like there could be, like, potentially medical technology that goes to just CVS and to consumers directly too, but for ones that, as you said are more so geared for doctors and clinicians and then help patients, that now gets into the whole medical system and the insurance and like payment and hospital management system and you really almost need to know the ins and outs. Or you need to find that out before figuring out your unit economics and what that's going to look like. I really hadn't thought about that. That's a good point. In your mind what are good ways to approach that? Is that information readily available? Regulatory Bodies and Compliance I would assume that it's under wraps because of the current system we're in. I'll try to not comment too much about it. I have a lot of opinions about it, but it's just I'm curious to know your thoughts and how someone could approach it in a step by step kind of fashion. The approach understanding sort of reimbursement and things that type of thing. That's a good question. Getting to your comment about the current medical system being interesting. There's a lot of, let's say, tribal knowledge. So there are resources that I could put out there, right? So there are some the way procedures are built are through what's called CPT codes. Common procedural terminology, I think it is. Anything that gets billed to an insurer, other than the VA, I think. The VA is its own universe, and actually, I like the way they do things. But, for the rest of the world, there's the CPT codes, and actually VA may have those, for also? No, CPT. CPT. And then you said VA, or did I Oh, the VA, sorry, the Veterans Administration. So that health care system I'm not as involved with them. I've been peripherally involved and they tend to just do what needs to get done for patients as opposed to working their world around CPT codes. Which is what the rest of the world does, because the insurers only speak CPT. That's it. You so for each kind of procedure, there's a CPT code gets reimbursed a certain amount of money, depending on where you Medicare will reimburse you a certain amount, depending on where you are in the country. The insurers will reimburse based on whatever arrangement they have worked out with, the practice and with the world and stuff like that. So you can get their list of CPT codes. So it's a code and what, what the procedure is. So you could look through that and you could get an idea of the kinds of things that are reimbursed that. We'll give you some information, but talking to the people who use these things every day would give you a lot more information because there's a lot of things that are customary and, tribal knowledge kinds of things. The other thing you could look at is the FDA and I'm sure we'll be talking a little bit more about the FDA. But the FDA has for any kind of device it recognizes as a device, you will have a classification and a description of what that device is. The easiest way to get through the FDA is to build something that falls under a device that already exists. So you could go to the FDA and look at all the classifications and try to find see if you have an idea for the device, you could look at the FDA and see if there's anything in their database that looks like what you want to develop. Yeah, so that it's, a more prescribed path rather than having to carve out something completely unique. Yeah. So when it comes to the FDA there's several ways of getting through the FDA. And most people take 99 percent or 90, more than 95 percent of applications to the FDA are for what's called five, 10 K approvals, which are approvals where you're saying I'm a substantially equivalent to something you've already approved FDA. And here's You know, how we know we're substantially equivalent. Here's this table of equivalency and here's the test we've done. So will you please let us market this device? There's other things you have to send them, but that's basically what it is. And those are actually pretty easy to do. If you want to do a new device that the FDA doesn't recognize. That's a lot more work because it's something they're not familiar with. You can't just say we're equivalent to this device that's on the market. You have to do, typically clinical trials and much, much bigger effort. Gotcha. Risk Assessment in Medical Device Development Taking one step back from the regulatory bodies and The requirements that are generated from, business business model development from understanding the system and how things get built and such. Every hardware development venture and product starts with requirements. So I'm curious to, I'm curious to know when it comes to medical device, I feel like some requirements will have to be generated from the constraints that regulation and compliance provide. But other than that, well, I would like to hear your thoughts on that. And then in terms of just common, common pitfalls or things that people do wrong when generating requirements for a med device hardware. sure. So first of all as a systems engineer, I hope people start with requirements. It's a really good thing. Doesn't always happen. So the big thing is you excuse me, just clear my throat. So in terms of requirements, I think. We'll start with the mistake that I think people make, which is to start with, Hey, I've got this cool idea. I'm going to build it. And then we'll do this FDA stuff at the end, whatever that is. And that's really, you're nodding your head already. So that's not a great idea. So in general, that's not a great idea to go off into the unknown and have requirements that don't address things that may need to be that you don't, that are incomplete, let's say, because you don't know what needs to be done Yeah. in particular, I think the thing to do is to. Start well, trying to both sides, right? So on the one side, you want to start thinking about product features and functions and things like that. But on the other hand, you really want to think about what your route is into the FDA. So what you're going to call your device, right? So recently I was working on a device. It's actually a consumer device that the company wants to turn to a medical device so they can, tell for medical applications, which tend to be more lucrative. And there were, I think, four or five different. device classes within the FDA that it could potentially qualify as, right? Even though, it, it did a certain set of things it could fall under various classifications. The, so at first you might say it's great. We'll just apply for all of them. There are very different requirements around what you need to do in terms of Documentation and testing and things like that, depending, we can get into that some more if you'd like, but those things, the development processes for those things could look very different, even though they're functionally pretty similar. So one of, one or more of them might've been life support, right? So that's a much different thing than, Hey, the doctor just wants to get a reading for something to get a feel for whether the patient's doing better or worse. Sure. I would start. are completely different. Yeah, exactly. And the. The development process becomes different, right? So there are different development processes, and these are actually called out in standards. So one of the things about medical device development is there's a lot of standards involved and some, and we could talk about those, but there's a few basic standards, and one of them is the Medical device software standard, which is IEC, or ISO, I think it's IEC 62304. And with 62304, you basically do a risk assessment of the, software that you're writing. And then based on that, it calls out three levels of risk, A, B, and C, so if it's a class C, you, it, you don't really need to do a whole lot of testing. Like you should, because it's a product, but you're not required to because you're not going to hurt people. This class A, it calls out tons and tons of tasks and procedures and things that you need to pay attention to. So that would be things like pacemakers or things that have a very high risk of capability to hurt people. I see. I feel like a lot of startups actually go down that path of almost like a pronged approach where they have a consumer version of the product and then they also look at medical because the ones that start with medical realize that they the FDA and all the regulatory bodies almost dictate their product development approach because it has to because at the end of the day, those are the constraints that you need to comply with to exist in the medical field. And so that I've seen for example, one of my guests Droplet, they started off as a medical application. They were trying to build like a I'll do a terrible job of explaining what they were trying to do, but it was a, basically like a dermatology focused product and they were trying to do it so that it could heal wounds quicker, and that was a very medical application, and then they found out that the it, there was a lot of consumer interest in more so like skin care and so they pivoted to skin care, and now they're still they, they are working on medical application, but that's more of a sidetrack R& D effort and I guess when companies are at that point where there is a potential to have a consumer electronics approach and then a side medical approach Do you have any recommendations on how they can go about it so that transition could be potentially easier? Because at that point, you're really not including the requirements of an FDA in your product development. But is there a good medium way that could be done? I'd say that the answer may be a little high level and difficult. So yes, I would say that they could do that. I think it's going to be somewhat on a case to case basis. So what I would recommend is start by going through the process that, I just spoke about, which is to, if you can yourself or grab an expert, it's not very people were expert at this. It won't take them very long to look through the FDA and try to figure out. What, how much risk is involved and what the path might look like, and then just stick that in the back of your mind and say this is nice to have stuff and to the degree, we can do things that make it easy for us to go back through and do these things that this will help us out. Yeah, I think that's the approach that I would take for that. Yeah, so look at the the, I guess FDA guidelines and what that development process would look like for the product and which category it fits under the most, and then potentially like laying out a roadmap. That would comply to that and say, okay, we can't do like process B and C right now because it's too much money. It's going to take too much time, but we'll set it up in a way so that once we have a consumer product in hands of consumers and we're getting feedback and we're going down like the redesign path because every good product development Has that where they get customer feedback and then they go to a redesign, that's why you keep your quantities low at first and you almost treat it as a prototype phase etc. They have the ability to either make a pivot or make a pronged approach to start applying it to an FDA route and set that up early. But the flip side, though, is that if you go through the FDA stuff, let's call it, like the process of figuring out what you would need to do to go through FDA or get CE marked in EU, et cetera, you might actually find it's a lot simpler than you think. So it may actually open up, end up opening up a door for a way to get in, more, more easily than you thought it would be. What do you feel are the common misconceptions of that path and why what parts of it people feel are difficult and what are actually easier than expected? So in medical device development, everything is risk based. Let me take a step back. It is often the case when I work with people, they're under the impression of, Oh, everything has to be medical grade and we have to do all sorts of testing on everything, right? Everything needs to be tested exhaustively. That's not really the case. The case is that you should be very thoughtful about what's appropriate to do. Great. So you'll spend time doing risk analyses which is not. The most fun thing in the world, but, everyone gets through it. There's different techniques to some of them. So I won't get into the details, but everything's risk based, right? And there's actually a lot of latitude, right? So sometimes it's not much latitude, but in general, there's a lot of latitude for you to figure out what you need to do based on your risk assessment. It's often the case that if people do a risk assessment. They'll find things that they really don't have to pay attention to 'cause they're not a problem. Whereas if they hadn't done a risk assessment a good risk assessment, they would be paying attention to things that really are not likely to cause a problem. So that it's really narrowing down where you gonna focus on and that's where the risk assessment comes in. And then as a, on a related topic, there's different ways to do risk assessments. Fault Tree Analysis vs Failure Modes and Effects Analysis I said I was gonna talk about this, but I'll a little bit. So traditionally, people use FMEA, failure modes and effects analysis, which is a bottom up approach to, to risk analysis. There are other techniques. In particular, I often use fault tree analysis. which is a top down approach, which is much more efficient. It makes things much more tractable, particularly for large devices. I mentioned over the last decade or so, I've been primarily working with proton therapy systems, and those are enormous systems with, what I'm working on now, I think it's about 20, 000 parts in the BOM (Bill of Materials). And some of those parts are like a power supply. So they're enormous systems. So for doing risk assessments for something like that, with an FMEA, it's pretty much impossible, but And even with smaller systems using FMEA, it can be pretty exhausted, exhausting and difficult. They typically go until people just have had enough. So sometimes things can fall between the cracks, but fault tree analysis just makes everything much simpler. Could you walk through just for a simple system or, whatever system that you see fit of just how you would go about a fault tree analysis? You start off with the harms and the hazards. So basically the medical device, standard for risk. There's a standard just for how you think about risk, which is ISO 14971. There are either ISO or IC and sometimes which is which. And that is about risk and it actually, it goes through how to think about risk and it doesn't. It says you need to do risk assessment and it gives examples of ways you could do it like FMEA or fault tree analysis. I think there's some other ones as well. There's a cool appendix in the back. I think it's in the new edition. It's still in the back. It's still an appendix, which is a list of all the ways that you could hurt people, which is very entertaining, burning, crushing this, that. I am very entertained by that and terrified. You go through that list basically and you say, okay. Can my device crush somebody, right? No, it can't crush your software as a medical device. So yeah, it's not going to crush anybody. Can it electrocute somebody? Can it, all the different things that it can do. And you narrow it down to the list of things that could possibly happen. And then you trace. Back from what are the harms that could cost? What are the hazards that could cause that? So burning somebody. Something gets hot, right? That's pretty obvious. And what could get hot on our machine? Oh, okay. So this 1 spot could get hot. And then you work backwards from that. And what are the chain of things that would have to happen? Or that to get hot enough to burn somebody, right? So then you say, Oh, okay I can mitigate that. I could put a temperature sensor on that spot and have it shut the system down. If that gets too hot. Okay. So now I've mitigated that problem. And no matter how we get there, I've mitigated that. So I don't really have to think about every scenario in which we get to that part overheating. I know we're good on that. That makes a lot of sense. And that seems from obviously an FDA standpoint, the thing that they care about is just the health of the patient or whoever is using the health and well being of the patient and whoever is operating the device. But I'm sure that there's also... And maybe the FDA doesn't care about this or maybe they do, but the startup owner or the hardware, the product owner will definitely care about this is also what faults could happen that make the system not function Oh, absolutely. Yeah. They care about the two things they care about safety and efficacy, right? So when you're working on medical devices, it's always been your head safety and efficacy, right? So efficacy is that the device does what it says it does. Basically that's all it is. So when you go through the FDA you make claims, you say, here's what my device can do. And they're going to make sure that you've demonstrated that you can do that. And those are the only claims that you can sell to the outside world. So they do care that you can do that. So if you have a claim that I can't think of one I've had uptime, but you typically wouldn't have that as a claim. But you need to make sure that you meet your claims. Other than that, like if you're shutting down 10 times a day, they probably don't care as long as that, allows you to, meet your claims. like it could And it's safe. I'm thinking, this is potentially a dumb example, but I'm thinking of just like COVID tests where they say 96 percent of positive results are accurate or something along those lines. Oh, absolutely. Yeah. That's a claim. Yeah. that's a claim and that's something that they probably have to support with like test data and Oh, absolutely. Yeah. Yeah. And if you have other requirements, business requirements or business risks that you're worried about, you can put those into the fault tree analysis to or FMEA for that matter. And as you're familiar, there's, design FMEAs and manufacturing FMEAs. And, you could do all sorts of FMEAs and you could do the same thing with fault tree analysis as well. It's a good point with very complex systems that FMEA, because it's systematic you would basically end up doing An exhaustive amount of work thinking about every single component, every single subsystem, and it would drive you insane. And maybe some subsystems. It's at that point. It's really up to the discretion. I think of whoever is the product owner or the hardware team lead to say, okay, for, for the overall system, we're going to do a fault tree analysis because in terms of safety, we need to comply by that. And we're going to go through what, what can happen. And then there's this like one system that's like very innovative. There's a lot of things that are new about it. So we're going to do an FMEA on that system particularly. And it's really about finding that balance of which one you do top down and which one you do bottom up. Yeah. And I agree with you. In most cases, the fault tree analysis is followed up by. Some degree of FMEA for, spots that you think it's appropriate. But it just makes life so much easier to start with fault tree analysis. And I'll actually throw out an interesting example which I heard about a few years ago. NASA. Was very big on FMEA. That's what NASA, for manned spaceflight, they person spaceflight, I can't say manned anymore. They would do FMEAs, lots of FMEAs. Then after the one of the space shuttle disasters, maybe the Challenger, they realized that they had missed something pretty glaring in the FMEA in part, because the amount of information is just overwhelming and it's easy for things to slip between the cracks. So then they moved over to fault tree analysis. And there's a NASA document somewhere out there which discusses that discusses, why they did it. And you know what the advantages are. So they also found that you get better information quicker with fault tree analysis. But yeah, I agree with you following up with the FDA as as makes sense. It's a good thing to do. Yeah it's a, that's super interesting. Balancing Documentation and Process in Medical Device Development I hadn't heard about that, but it also makes a ton of sense and I'm sure that you experience this a lot in a medical device because there's such an overwhelming requirement for documentation that there's always a balance you need to strike with documentation and data. because more data or more documentation doesn't always mean that's a good thing for your hardware development. Because if you can't sift through it, if you can't find the information, it's about finding information. And if it's too much, it's people are going to be spread too thin and they're not going to be able to see what's wrong. getting back. So I agree with you 100%. It's a great observation. And the FDA as well. So the FDA is Position from what I can tell, and actually in talks with them, this is the clear signal I've had there you should do it actually makes sense for you, right? If in terms of documentation, you should not do a bunch of documentation because we're afraid of the FDA and we need to do a lot of documentation, whatever gets the job done. So they'll set the parameters. Through standards, everything's your standards. We can talk about that, too, if you want. But the FDA wants to see that you've done what makes sense to do. Basically, it's good engineering practice. And they also want you to show your work. That's the other big thing. So you really should keep records of how you develop things and meetings you had and things like that. Because they want to understand. More. So this is what I've seen. What they're more interested in is not busting you. I found the very, I think the FDA is very easy to work with. Actually, I've had no issues with them. If something bad happens, right? So if a bunch of people get injured by a device, they want to be able to go back through. They want you to be able to go back through your process and understand how that happened. So they're very big on openness. They are not even people make dumb mistakes. They I've not seen them really come down incredibly dumb mistakes. They, nobody goes to jail, but they will become very interested in what you do day to day. But they understand things happen and they want to make sure that, when things happen, you know about it. And, sometimes they know about it, depending on what happened and that you go through your process and figure out what happened. They're very big on process and making sure you have a process that works. yeah, I think As we talk more about it and the requirements that you're setting forth and the way that it's approached is the level of process potential. I think it's a little bit too much for, if you were to just do hardware not in the medical field, I wouldn't say oh, this is a perfect the FDA compliance and regulation structure is perfect for hardware development. I don't think I would make that statement. However I think a lot of startups fail because of lack of process. So in a way using a regulatory body and like that process itself is a risk mitigation for your business too as long as you are able to set up your like fundraising structure in a way that gives you runway to be able to support that. And so I'm, as I learn more, this is really interesting to me and I think my, my whole thing because I've been a mechanical engineer and a program manager where it's like I have these two sides of my brains that fight each other all the time where my mechanical engineer side is saying I hate process, get out of my, get out of my face. And then the program manager side, but it's no, but yeah. Otherwise, we're not going to get to the goals that we're setting, and so it's interesting to see how it almost, this forces you a little bit, shoehorns you into thinking, okay I really need to create some level of process so that I'm in compliance, but also it's going to be a risk mitigation for my business too, so how do you strike that balance, and a lot of companies that I've worked for that have been relatively really successful have even like when you're pitching to VCs, your company they have say 10 slides that they are using actively to express what they're trying to do, but then backups are like 900 slides. And I feel like potentially with the FDA it's like a very similar thing where you have that and this is just a generalization, I'm not saying you should have 10 documents, but having that kind of lean documentation where it's like very easy to find information, it's very methodical and systematic, but then you have all of these like depth of documentations to support all of the claims within that and structuring it in that way I think would help your hardware development and also help you with the FDA. Do you feel like that's a good assessment? Oh, absolutely. Yeah. So I think, in terms of the. Let's say official, the approved documentation or things that people use their approved document, make them absolutely simple as possible, no simpler, of course, whatever that means. But what I do find is that it's what, when a particular startups actually, I take that back, in all levels of companies when people working on a medical device, they tend to clench and say, Oh no, we need to build, make lots and lots of documents and we have to up all kinds of details. And I find that people tend to over document rather than under document. If they're being conscious of making a medical device. They, they'll get extra funding and they'll say, we need to go through this big process and they haven't really done a risk analysis and they haven't really thought through their processes to decide what they actually need, what they don't need the FDA and, other bodies. Understanding Development Process Standards So they, they'll use pretty much the same standards. Now, they call out what your development process. What you need to have in a development process, they say, you need to deal with the following things. You figure out how to deal with those. we're not going to tell you how to do it. You just need to make sure you address these various issues. Importance of Following Your Process And as maybe a bonus, the most important thing is to follow your process, right? It's not to have, so it's much better to have a simple process that gives people leeway to make good decisions, which is always good anyway if you're working with talented people. It's better to have a simple process that you're going to follow than a more complex process that people don't follow because the FDA and everybody else is very interested in you're following your process. Inspection and Audit Procedures When they come in, they do an inspection. That's a lot of what they're going to look at. They're going to look at how you're doing things. You're going to talk to people in the company very often. And customers will do that a lot, like if you're building subsystems for a medical device, they'll come in when they do an audit, they'll say, okay what are you working on right now? Go to some engineer, the engineer will say, tell them, how do you know to work on that? And then they'll start drilling into how, what the process by was by which the person knows what you're supposed to do. And then maybe the other way as to how that's going to get verified and validated. So all processed. Balancing FDA Requirements and Lean Operations From what you said it seems like a lot of the approach people take is there's this assumption of how the FDA wants to see information and wants to see you develop, but rather than developing your entire company and strategy to like over document and over serve the FDA, it's more so to almost be lean minded and say okay what is the leanest level of like testing. Failure mode analysis and documentation I can do that serves the purpose of showing safety and efficacy to the FDA but also keeping my operations lean and all of the resources I create as lean as possible. It's probably a better approach to do that and once you do that, it not only probably creates some trust with the FDA but you can move faster than other people might think you need to. Yes. All of the above. And it's more fun for everybody too. Yeah I'm sure about that. Okay. Testing and Validation in Medical Device Development I have one last question and then we'll go into our podcast break to hear some horror stories from you. I guess my my, my last question is When you're going about testing your product I'm always very curious on how this works with MedDevice because oftentimes the biggest question marks you're trying to validate are around efficacy and efficacy will only be accurately determined if it's probably used with the end use. Do you have to, and this is again a very ignorant question because I've never gone through this process but, Do you have to go through certain qualifications from the FDA to get to that testing point? And how do you partner with people to do that, especially if the testing involves people? Yeah. So I'll start by saying that 99 percent of the time for a new device, you're falling into a category your type of device, the FDA already has cleared at some point in the past or approved. And. All you need to do is bench testing, and to show that, typically, not always, but typically, that, via bench testing, that you're substantially equivalent to the device that you say you're substantially equivalent to. So that makes things a lot easier in terms of doing clinical trials, which I think is what you're asking about. Yeah, that becomes a whole other thing. There's so there's a few layers of things that are going on, right? Navigating FDA and Institutional Review Boards So one is you have to clear with the FDA. And what you'll do is you'll talk to them about something called an investigational device exemption. So basically you're, you want to show them that, we want to do some invest, some research investigation, and we are building this device and it's not cleared or approved yet. And, we'd like an exemption so we don't go to jail when we do that. So you've got to, work with them to get that. The other thing that happens is the, at the individual institutions well, let's start by saying that you're going through hospitals, right? You're going to be using this. Typically, you're not using this in your office with patients. Although sometimes you could do that. But somehow this has to go either to the hospital or through some third party what's called institutional review board. IRB. I think it's a different board. So every hospital, every major hospital will have one. And that's a group of people who will look at the proposed research that's going to be done and, decide whether it's safe, whether it is ethically okay, things like that. You have to prove it before you can start doing those things. So every At least every teaching hospital, and maybe other hospitals too, will have an IRB in house. There's also third party IRBs you can go to. So if you're going to be doing stuff in your office with patients, or if you're going to be doing it with individual practitioners out, in the world you have to go through, through that IRB. The other thing to go through the FDA for is that you want to make sure when you do this research when you get your results that the FDA is cool with them, right? So you don't wanna do research, get results, say, Hey, this proves x and the FDA says no it doesn't. Which happens it's happened more in the past for various reasons, but you want to basically clear the FDA that, here's the study we want to do. Here's the results that we expect. If we do this, will you allow us to make the claim that, whatever the claim is that we can cure common cold 40 percent of the time, and you want to get there by end of that. I see. So before you even set off on your testing I'm sure that like the FDA employs either like a PI or a point of contact that and is it a case where the communication is relatively smooth where you can have them audit your work just to make sure FDA? Yeah, so basically you could talk to them. And I haven't been involved in this much. I've been involved in this sort of secondarily with this specific type of thing. I've been involved with the FDA and other ways, but I think, you basically go to the FDA and says, here, you say here's what we want to do. Is this okay? And very often they will ask questions and they'll say we want to see some more information about this and this. So they drive that process. I think other than whenever you work with the FDA, you should be really prepared, not, sound like a bozo. It's not great to go to the FDA with sort of naive questions. A lot of dealing with the FDA is trust, right? So if they get a sense that they can trust you, that can come various ways. Everything goes, it's like everything else in life, right? If you think you can trust somebody are less concerned and we'll maybe dig into things a little bit less are you sure if you prepare for the FDA, dig into whatever, but it helps a lot if they think you know what you're doing. So with all contact with the FDA, it's very good to have somebody doing that really understands what's going on. Mhm. Mhm. Challenges in Medical Device Innovation and Funding And I guess this is more on the, a little bit on the startup fundraising side, where when startups are going through this process and they have efficacy their claims or their, the problem that they're solving and the solution that they have. I've seen a lot of med devices pitch. And the, one of the questions, because I'm not a med device person, and I don't know the process that involves it, but I'm a mechanical engineer and I care about efficacy and the claims that are being made. I've always asked Have you done tests on this? And do you know that this is going to cure this disease that you are claiming that it cures? And the response I would get back is like I'm not allowed to test on people yet. But basically research shows that it does. So I am going off of that hypothesis, which for a lot of VCs with no background in med tech, they're going to look at this and be like, this person's it's just a scam. It's, yeah, you can say claims like, oh, there's research that's proving this for anything. I, that is my skeptical side and I know that a lot of people have share that skeptical side, specifically VCs who are very risk averse. Do you have any recommendations or advice on how people can get ahead of that or if they can? I honestly think it's difficult. So to some degree, I hate to say this, the system's broken in terms of. Developing really new devices for exactly the reason you're saying. You don't know if something's going to work in the VCs. I think it's funny. You you're afraid that VCs are risk averse. They're not supposed to be risk averse, but it's less risk averse than others, but I take it. There's different levels of risk. You don't know if something's going to work until you try it, but getting to that point is very expensive. And there's a good chance it won't work. It's very often the case that you look at the literature and you have a totally reasonable hypothesis. It seems for sure it's going to work. And then it doesn't pan out in testing. So that's an issue, right? So we have. A scarcity of money to get invested in things like, the scenario you're talking about where something is really new. So we don't get a lot of really new things. They tend to be interested in things that are incremental improvement of something that's on the market, right? And that's not just in terms of efficacy, but it's also in terms of reimbursement. In fact, that may even be a bigger issue, right? You don't know, even if something's effective, it may not get reimbursed. Whoever the insurers in getting to the point where you have a new CPT code, it comes down to CPT codes. If you have a CPT code, you can fall under, then people know how much the insurers are paying for that. And, you can estimate, revenues and things. If there's no code yet, you got to get a code generated, then you get to get CMS, which is Medicare Medicaid. They're the people who set the new CPT codes. They need to set a code, then you need to come up with a reimbursement for that, then you need to go to the insurers to get them to reimburse for it. So that that's a lot of work. So that's a really long winded way of saying that there's not a great answer to that question, Which is one of the reasons we don't have a lot of innovation. I feel in the medical device space, I agree, and I feel like... Oh, this is a rabbit hole that I, I will die going into because I really do think it's a problem. And I think that innovation in this space is necessary. There's a lot of problems that haven't been solved yet. And I think the best, I guess the best you can do is what you said of just whatever benchtop tests you are able to do that potentially don't I guess the closest you can get to research claims is all you can do, it seems before qualifying for tests where it's like, If there's a research data that you're referring to when pitching your product just trying to get tests that are as close to that research data as possible, rather than just being like, oh, we built it and it's like somewhat similar, but more so like drawing examples of the reason it's similar is because we did this bench tap test that these people did in this university, and this university, and these are the like test results that they got from working with real human tissue or whatever. And since we are basically in line with it, we assume that there's a very high chance that ours is going to result in this, but we need money so that we can work with the FDA so that we can actually do our, the tests of our own, and so on and so forth, and having that storyline is the best I'm assuming, that med device startup founders can do. I think that's often the case. I think there's a, so I think that's generally true what you're saying. I think there's a couple of other things that can be done, which are a little simpler. If you want to do something that's really different, let's say you can, one is to work with the VA. So I've had a few clients who've worked with the VA to trial, various new devices and new ways of doing things. The VA is not really driven by CPT codes. They're driven by, we have a budget. We have to use that budget in the best way possible to help people. So if they have some condition that they're spending a ton of money on and they can either spend less or do a better job on it, then they will fund research sometimes for new devices See if they can get improved outcomes that way. The other thing you could do, which I've done in my customers have done in a few instances is if you can team up with doctors. To use your equipment more informally. So rather than having a formal study, you can, work with some doctors who will, go through their IRB or however they do it, they'll finesse it and they'll start using your product in various ways and just getting some data informally that could be helpful to them. And I think in all cases, it'll be helpful to them, it's not something that you can you'd probably not modify treatment based on just that data. That, but that requires to some degree, it's, if if you're involved in a community of doctors, that makes that a lot easier. So if they know you and you know them, that kind of thing, you work with them a little bit. It's a little harder to approach a doctor and ask if they'd want to do that. But that could happen. I see. Okay. And then you start getting some more information and then you can build some more trust around. Whether your device is doing what you say it's you know, so if it's a neurologist, the neurologist come back and say, you know what, I've been using this device to confirm what I've been doing by eye, and it does a really good job of actually, coming up with the same answer that I would come up with. And, I'm a, Neurologist at Mass General Hospital, part of, Harvard Med School. So I know how to do this stuff, but the average doctor doesn't. It'd be very interesting, very useful for them to be able to have this information, which they're not going to be able to do because they don't super specialize in what I super specialize in. But this device will make it possible. So that, that can be helpful. And then organically move out from there into doing other things. When it comes to pitching to VCs or anybody, I think having clinicians, doctors being your advocates is critical. Yeah that makes a lot of sense. They're the potential end users, and they know patients really well, and they know the area, okay, that, those are really I think very good tidbits on how someone could approach this because it is a really difficult field and it's specifically difficult when you're trying to get funds for something that doesn't exist and doesn't have a ton of data like the specific thing you're πŸ“ building. Podcast Break This podcast is presented to you by Pratik, a startup advising and coaching company that is geared to help hardware entrepreneurs get their ideas from a napkin sketch into a lab and out into the world. Podcast break Let's get into our podcast break where we talk about hardware horror stories. So I'm sure that you've had many I'll twist it and say heart, medical hardware horror stories, which sounds. But so if you could talk just, it's a segment to focus on how a hardware startup got it wrong, which set set them up for some issues whether it's technical or financial and obviously you don't need to name anyone, but how, maybe talking to you, how they could have avoided it, what happened and so on and so forth. Sure. I'm trying to think, I don't think I'm involved in anything that ended up in a horror story, like a patient getting hurt. But I've had lots of sort of project oriented horror stories, which are. better. In many cases, the the same as the typical developments low medical devices tend to be higher stakes. I've been involved in a few messes after the fact well, in one case is on the sidelines watching as a supplier to a medical device company and or subcontractor and contractor and in other cases, right? So it's. Typically the case that I get involved in projects when they're having some issues, and that's usually when I get asked to work on things. So I get to see a lot of the challenges. The classic thing, of course, is with all projects is that people haven't done good requirements and a good project plan, right? So that happens all the time and all levels of companies. I guess there's nothing new to medical. It's not new for medical devices. It's just it's a big deal. I guess with the medical device companies, you have the added issues of. The FDA stuff, which people say, we're just going to do it and we'll give, we'll say we're going to spend 500, 000 on FDA stuff at the end. And that's bad because you may have to redesign your device, redevelop your device based on that FDA stuff. And that, that's absolutely, I've seen it absolutely happen. The one disaster that, Actually, this has happened in two companies that I've been involved with was that, and again, but this is something that could happen to any company that building something larger complex is defining interfaces and then having groups go off to develop to those interfaces. And then figuring you're going to integrate at the end and everything's going to work because you've defined your interfaces and that's has led to insane costs, in time overruns. You really need to do continuous integration. So with hardware as well as software, maybe not continuous, but not every six months. I'm trying to think of specifics, not really. I think if you do good requirements. Which is hard, it's really difficult to do good requirements and it's a pain for everybody, but it's important. And you do a really good project plan. My project plans tend to be, 1000 tasks and up even for reasonably smaller devices, just because it's great to break everything out and make sure you. Are you're thinking about everything, right? And you're sticking times and dependencies and costs on these things. But I don't know if there's anything specific to medical. User interfaces are important. So I know devices that have been recalled because of confusing user interfaces. And there's FDA standards around or international standards, let's say around usability that you need to take into account. But, if you don't, people, I think I don't want to put a number on it, but the, whether it's the first or second most common cause of recalls, but it's user interfaces. And is that because they didn't do a good job of like just user interface studies and get feedback early, and they just assumed that it would be straightforward and it very much wasn't? Yes, exactly. You really need to do your homework on that, although it's gotten better because there, there's more it's become more mandatory to do those studies. So again, there's another standard there's actually a few standards. I forget which one's being used now, but there's standards around usability, which, require that you do your formative studies and. Take it through the life cycle to ensure that things are easy to use. Have you ever had have you ever seen something along the lines of med devices performing very differently in the field from the, conducted tests in house? Because I feel like sometimes when you conduct tests, you can over prescribe how the test is going to go and who's going to participate and how it's going to get carried out. Whereas, that... Method and I guess process isn't really followed in the real world and then it just comes back. It's oh, wow, the efficacy is like much lower or we need to redesign this entirely or something like that. Yes, and actually it's a good cautionary tale. When devices are very flexible, people come up with very interesting ways to use them that may not be what you anticipated. So one thing I would caution people generally, and I think this is true of any product development, is try to cut your, your, Features down as much as possible and make it as, the idea is what I always tell people, the ideal medical devices, a button, the doctor pushes a button, gets an answer. That's it. It can't tweak anything else. One thing that does become an issue, and actually this is, I don't know, sure it's a horror story, but it's been a problem the people that. device makers typically collaborate with to develop new devices are the top end, research doctors at these, high end university or medical schools and hospitals. And those people want all sorts of bells and whistles cause they're doing research and they want lots of interesting things. And they think everybody else should have those too. The average doctor just wants the button you press and the number comes out and you send a bill to the insurer. It is, it could be. A little interesting to strike a balance between those two things, because if you just want to do the button that spits out the answer the research docs are not going to be as interested in working with you, but you also want to make something that's too flexible and either the end users just get, confused and they throw their hands up or they do something wrong or that kind of thing. I've definitely seen that happen. Yeah. Yeah, I feel like, features, it's sometimes exciting when you're an engineer and you want to add new features because there are new problems to solve. But at the end of the day, when it ends up in someone's hands those features become your biggest enemy. And I feel like features should be added through headache rather than excitement. As in it goes to the field, people are like, Oh, man I really need to be able to do this. And then you add the feature rather than being like, We have, we created this medical device. It's all the bells and whistles you could ever think. There are 53 features that you can customize to your liking. And then it's oh gosh, everyone's gonna factorial, basically, 52 factorial ways of people who Using that and then it's so it's also it becomes I mean your FMEA becomes a nightmare. It's just it's adding complexity on all fronts. Verification everything. Yeah. And you may just miss the mark. Totally. It's what the doctor wants. And actually there's a recent example. So I was guest managing a project for a major, a very large device maker within the last few years. And about a year I managed the project and then it became too difficult. Cause I was also working with other customers and things. But they really had decided. That they knew what the doctors needed. They didn't want to work closely with the doctors on the development of the product, because that, that, that can become painful for a lot of reasons. So they just went off and built something that was really wonderful and had really cool features. It was really cool. And then when they, at the end, they showed it to the doctors, not quite when they're ready to go to market, but getting close, the doctors said, here's all this stuff that you don't need. That's just confusing. And here's some things that are really important that turned out to be major things. And when you have to tear apart software or hardware to, getting rid of things, actually getting rid of things can be tough sometimes too, because you've got interdependencies and things, but adding new things, once your product is pretty well developed, you may have to rip apart your sort of infrastructure. And it can be challenging. That's what happened with these guys. It became quite a challenge and they were already like most projects their timelines and budgets didn't have a lot of padding. So it it became a problem. And actually the product ended up getting abandoned, not just because of that, but that has something to do with it. Makes sense. Very cool that those were a bunch of horror stories right there so many things that could go wrong, and it's important to I guess it's important to potentially anticipate them. Navigating Supply Chain and Manufacturing Challenges Obviously, don't let it bog you down. Analysis paralysis is also a thing and that could kill a project as well. But... Okay, so shifting gears back into the development, one of the things that I kept thinking about when I thought med devices, obviously and maybe this is another misconception where everything has to be medical grade because medical grade means it needs to be produced in medical grade certified manufacturers which you're the amount of suppliers that you can work with now shrinks into a few a few potentially local ones or just a very low number of people you can work with and coming from a startup perspective where you're trying to be lean and you don't have huge order quantities that you work with, how do you feel is the best way to navigate as a medical device startup the manufacturing and supplier field and how do you get in front of them and actually Actually work with them while big companies are dominating the customer base of most of those manufacturers. Yeah, it's a very interesting question. It's definitely an issue. If you're doing smaller volumes, typically medical devices, with electronics in them, thousands, maybe tens of thousands a year, unless you're going to go to consumers, but then still compared to smartphones and computers and things, you're nothing you're a blip. On the other hand, that there are some good things about medical device development to help to mitigate that. One thing is that the margins tend to be very high. Yeah. So that's another thing to think about, companies will often dismiss out of hand, startup might say I could do this as a medical device, or I could do this as a consumer device. But the medical device seems too difficult, so I'm just going to look at the consumer device. The good side of medical devices is that the margins are much higher, for better or for worse, as a society. But they, tremendous margins. And also, approval is a barrier to entry for your competitors. So there's not a lot of people who can get approvals or who think they can get FDA clearance and get into the medical market so they can be buried entry. But anyway, that's a little bit of a digression. But on the margin side, it also means that you can mitigate some things that may be difficult for other products. For example, If you have inexpensive, pieces, parts, USB chips things, things that cost 10 cents, 15 cents, 25 cents, you might just want to go off and do a lifetime buy and say, I'm going to buy 10 of these things. So I don't, my supply chain is not going to be a problem, right? Cause dealing with supply chain is. Typically the most difficult thing, I think, in terms of manufacturing when you're a small company. And there are also some vendors who like doing medical devices, again, because the margins are high. Texas Instruments, for example, I haven't worked at on board level stuff for a few years, but it used to be the case that Texas Instruments and some other manufacturers really like doing medical devices, because they can charge a lot for a chip. And the the buyers are fine with that because they've got the margins and they just really want to make sure things don't screw up. That can be very helpful too. I guess you need to work around, there's no magic to other than the vendors, the few vendors who really want to work with medical. And those are the people who make processors and other sort of more expensive components So you can work with them and they're happy to work with you. But for the other stuff, I think you just have to work around the realities of the supply chain and don't get yourself caught in a situation where you can't get parts right. And that happens because somebody discontinued something or they changed they made some, have a new rev of a chip or something like that. And you just can't get, you just can't get what you need. In terms of qualifying vendors so yeah, there is often this misconception that you need to buy medical grade parts that, that doesn't really have a meaning. FDA does not approve components. They do not approve subsystems. They only approve or clear. You say approved or cleared depending on certain FDA products, medical devices that are fully functioning medical devices. So it's not like you need FDA approval for a part. Yeah. When you're qualifying vendors and qualifying parts, it comes down again to risk analysis, right? So everything in medical devices is looking at the risk and then saying, what's the risk here, right? So if you're buying resistors, unless it's a resistor that if you're off by 10 percent or if it doesn't meet a spec, let's say somebody's going to get really hurt, then you don't have to worry about it too much. The best mitigation is you should try to make sure your vendors are ISO 9001 certified, and, for most parts you're going to buy that's as much qualification as you need. For high risk parts, the. You may want to get some more information from the vendor. You'll definitely want to make sure they're 9001 qualified, and then... If you're familiar with ISO 9001, I assume most people are, it's a quality system directive, and anything you sell in the EU has to be ISO 9001 certified, I'm pretty sure, or at least compliant. And in the US it's optional, but you should definitely do it. It shows that they have a process that will end up creating, what they advertise their product does, it actually does. So for high risk products, you may want to even go, audit your vendor, right? Make sure that they're doing things properly. It's really all about risk and figuring out what do you need to do to bring risk down to a lower enough level that you're comfortable with it. Okay, so if I were to summarize what you said and like in addressing the question of working with manufacturers when big companies are dominating them, it's saying like with components that are relatively low risk of change order. So basically like a USB stick, stuff like that, where it's like, We will likely not have to change this. It's super, super low risk of that happening you could just go ahead and do a bulk order of that which I know that in the episode with Droplet, when they were doing This, they actually ended up taking away the feature altogether and they had all of this stock that was sitting, but that goes back to what you and I were talking about in terms of adding features is you should really add features with a lot of discretion. I think that's just when you're setting up your requirements, just really asking the question of does this feature really, is it critical that it exists and how much data do we have to back up its criticality? But I think there's a quote by Steve Jobs. I think it was something along the lines of genius is not what you It's what you take away. yeah. Oh, I, actually, you're right. I had heard that before and that is true and it's difficult. It's difficult to make that call but I think that makes sense. And then in terms of, especially if it's like a bigger medical device oftentimes, because the margins are so high manufacturers are a little bit more lenient, it seems at lower quantities because that, they know how they know the customer base that they're serving and they know that it's not going to be this huge mass production. Element. So you might be able to get away with vendors being interested even though you're not at super high quantities. Is that a correct assessment? Yep. That's true. The other thing you can look for, particularly you can with processors and more expensive components is sometimes manufacturers will guarantee the availability of part for 10 years or something like that. And they'll have a process of, they'll notify you and you have to do a last time by and things like that. So that, that could be very helpful Gotcha. Okay. Because you really don't want to change processors, in six months that. Yes, they're all ARM, but they're all different, and you don't want to re qualify with a new processor. Totally. And you said something along the lines of, the FDA doesn't care about the components, it cares about the full system. Does the FDA not go through a checklist of the bill of materials of a med device? And would there ever be an instance where when they go through the BOM, if they do that they would say this is really not okay to have in here or something along those lines? No, I don't think so. They might say, this is interesting, why did you do this? But I don't think they'll say no. Now, the EU is a little different, right? Because the EU has Rojas, REACH, WEA. They've got directives that you have to follow. And typically, there's something I should probably add also. Understanding FDA and EU Regulatory Differences We've been talking about the FDA. I've been saying FDA a lot. But that's basically shorthand for all regulatory bodies. And the good news is that they're all becoming more similar to each other and actually quite similar to each other at this point as to what they're looking for. So they all point to the same standards generally, right? So for example FDA used to have its own it's called a guidance document on how to do product development. And they were either about, they're either about to, or they've announced they're either about to, or they have at this point started just pointing to. What's called ISO 1345, which is the quality system standard for medical devices. That's the same one that the EU uses. So usually that's another tip, when you're building a product, maybe don't think about it as we're going to, build it for us first, and then we'll go into EU and other markets. It's not that much more work to go into. To develop something that can get cleared in all your different markets, or at least US EU and some of the other ones that basically follow the same schemes. There are some countries that are a little different, but they're actually a small part of the market, so it's not as important. But in the EU, there is, there are some differences in terms of they have directives that you have to follow around, what materials are in components and things like that. Gotcha. Okay. That makes sense. And that's that, that's actually quite interesting because I feel like that w that might also be a common misconception that it's like, Oh no, like we're going to focus really very much on the U S market because then we need to spin up our entire product development and potentially make a design changes for the EU. It's if they're not that different, maybe you start. Considering both at the same time so that you have broader markets, but obviously that's more of a business development strategy, which is definitely not my specialty, but it's about it's really great to hear that is very attainable. You can just buy into the flexibility. So even if you don't know that you're going to go into that market. So I would say that the best way to get to the FDA is do what the EU wants, because the FDA gives you more leeway around what you can do. But for almost everything, they say, oh, if you use the standard that the EU wants, That covers this area that we're concerned the Venn diagram of the EU is a bit bigger and it includes FDA in it, it seems. Yes. And it's not very much bigger. It's very similar. So I think it's reasonable to shoot for both. Awesome. That is excellent. All of this has been so incredible, and I feel like we've really just scratched the surface. I know that it's really difficult to talk about these in relatively a high level, because all of them have such depth and, Just processes and codes and all of these. So I really appreciate you being able to stay at the level. Obviously as I get feedback from listeners, if there's any particular topic that they want really in depth, I'll reach back out to you, Alan. And I guess for. Final Thoughts and Advice for Medical Device Startups Wrapping up this podcast episode, this podcast episode was really to encourage and hopefully help people who are trying to do the hard thing and try to create a medical device that exists in the world. So do you have any either words of affirmation or advice to those that are daring to do this? I'd say, I guess it's probably not as much work as you think it is, but it's definitely work. Do your homework first, including the FDA. And I'd also say that I'm being a little self serving here maybe because this is part of what I do for a living, but if you can find somebody who's very conversant. With the regulatory stuff, who's also an engineer. You'll be able to get more information in a day than otherwise you would get on your own in months. I think you're right. It's a very niche field and it's understanding the technological burden, but also the regulatory burden and be able to cross pollinate. Those is a very unique skill set. And people who are doing this require that it's just a given. Read read the book that Alan wrote. It's excellent. I'm going through it myself. It's truly, it it speaks to any hardware developer's soul, I feel, especially ones that are interested in systems engineering and systems level thinking. And. I think the information set forth in this episode is a really great starter, at least for people who are even thinking about it, of just like, how do I even approach this? That, that's really what I wanted to unlock and Alan, thank you so much for your incredible insights and expertise in this and for your willingness to, to share with the broader community. Thank you, Sarah. It's been a privilege. Thank you. All right. If you've come this far, you are in the TL deal section, which I like to call too long. Didn't listen. Where I go through some key takeaways from the episode, diving right in. For medical devices. Alan mentioned to not over document, just because there's a belief that the FDA will need it. Do documentation that serves your product development and work with an FDA regulatory specialist or a consultant to determine if there's anything else you will need. If you were working on a med device. That the end users or clinicians or doctors make sure that you get their feedback as soon as possible when it comes to the minimum viable features. He says that oftentimes my device designers would put more features than needed, which would over-complicate the product and result in them giving the feedback of, I only need these three features instead of 50. Instead of an FMA, which is a failure mode analysis. Elements analysis do a fault tree analysis instead. What a full tree analysis is basically you start off with harms and hazards. So basically in medical devices you think about it in risks and he quoted an ISO. 1 4, 9, 7 1. And basically you need to do the risk assessment and give examples of ways that it could potentially harm someone. So you go through a list and apparently there's a appendix. To the ISO manual. At the end that says that gives a list of all the ways you could hurt a person and you go one by one and says can my device cross somebody? Could my could it electrocute somebody and go through all of the faults that can happen and then go backwards because an FMLA would take too much time because you have to go system by system or component by component. And oftentimes these really large meant devices have somewhat around 2000 to 10,000 to 20,000 parts. So it would not be feasible. So that was one of. Really a useful tidbit that Alan shared with us. And then you'll definitely want to make sure when procuring components, some will. Be required to be medical grade, but not all but make sure that they are ISO 9 0 0 1 certified. Or at least compliant. AlSo, we talked a lot about the FDA, but Alan wanted to mention that the FDA and other regulatory bodies are very much converging on their standards which is called ISO. 3 4 5, which is a quality system standard for medical devices. And it's apparently the same one that the EU uses. What he wanted the key takeaway to be here. Is that when you're building a product, don't think about it as, oh, we're going to do us first. And then we're going to go to EU because if you comply πŸ“ with EU usually chances are you'll comply with the U S as well. So that is a really interesting. Kind of market perspective. The opinions and information shared on this podcast are for informational purposes only. We always recommend that you seek professional advice before taking any action related to your business or personal ventures. Thank you for listening, and I hope that you enjoyed the episode