#371: Achieving ISO 13485 Certification

Weonika Michaluk: First of all, do a proper gap analysis and also think whether you have enough knowledge internally, whether you have experts internally to do so. Because I do think it will make your life easier to even reach out to a partner that already have done this or reach out to a consultant that already knows how to set up a QMS and how to go through the the audit process. Because it will definitely make the life easier.

Zach Markin: Welcome to the global medical Device podcast, where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge direct from some of the world's leading medical device experts and companies.

you're looking to tackle ISO: 1345

it about their journey to ISO: 1345

Weonika Michaluk: Thank you so much for having us here at the end. And actually, it's great to see you again, as we had the chance to see each other in person two weeks ago and last week as well. It was great to see you and happy to be here as well.

Etienne Nichols: Absolutely. It's been a great kickoff to the year with true quality Roadshow in Boston and then also LSI in California. Shout out to those two events and. But, yeah, Zach, I didn't mean to cut you off. How are you doing today? Glad to have you.

Zach Markin: Thanks for having me. I think I'll have the least to say all hours, so no worries at all. But happy to be back with you and happy to be be chatting.

Etienne Nichols: Always glad to have you both on the show. So why don't we just talk? We won't make the assumption that everybody has heard every episode leading up to this, but we will put that in the show notes. If anybody's interested in, in, in the pre and now the post, why don't you give a quick introduction to HTD who you are and what you do, just so we can have a better understanding.

Zach Markin: Maybe I'll start with that. And then Veronica, I'll let you talk in depth about our medical device work because I think that might be of most interest to the audience today. But yeah, well, thank you for having us. At HDD Health is a digital consultancy. We are about eight years old. We've always been focused exclusively on serving the healthcare community and we, you know, we offer all of the classic things that a digital consultancy offers, but we think our approach and our deep focus healthcare, and specifically certain segments within healthcare ecosystem, let us do those things in a little bit more of a compelling way and a more comprehensive way. And so we, you know, we offer a full spectrum of services from business and technology strategy consulting, through things like technical due diligence, et cetera, but then all the way through the traditional product engineering spectrum. Product design, user research, business canvas research, and then a lot of product engineering work, platform engineering, data infrastructure, data and analytics work, data and analytics consulting. A lot of people, they almost hesitate to use the AI word today because it doesn't mean what it used to, but a lot of data consulting, and you could call it advanced statistics. And we mostly in terms of segments, we do a ton of work with the provider community, both what we kind of call next generation providers, as well as more traditional providers. We also do a lot of work with platforms, software platforms that serve the medical community, SAS providers, and also with medical device companies. And Veronica runs that practice for us. And then serving, serving other parts of the ecosystem as well, the investment community, payer, etcetera. But heavy focus on providers, platforms and devices. So maybe, Veronica, you'd like to talk a little bit about the software's medical device practice and your work in starting that in HDD and the background there. I hope it's all right at the question. Absolutely.

uct lifecycle. We're also ISO: 13485

ith us what your focus was in: 2023

maybe I can start. So now, in: 2023

at you do. A lot of times ISO: 1345

ontinuous improvement, as ISO: 1345

Zach Markin: Yeah, well, I was thinking a little bit about, you know, I always look at things from. From a slightly different perspective from. From you, Veronica, which is like, more is kind of less. You know, you. You have a hard. You have a harder task on a day to day basis in terms of you're actually responsible for getting the things working and delivered and maintaining satisfaction of clients and other things like that. And I have a maybe a little bit more luxury to think about our work in some other areas. But I was kind of laughing to myself when you started to describe the focus on safety and other things, because I remember when I was in consumer tech world and my older brother, he's an emergency room physician and a critical care doctor, and I used to joke with him that his job was a lot harder than mine because in the worst case of my work, like a website might not be available or something. And I would be like, it's pretty. I feel fortunate that I don't have that kind of stress. And then as we kind of a decade later, now, I'm looking at these medical device products, and they are. They do have that same level of criticality, and they can have that impact on people. And so, for me, I don't really think I would be comfortable doing that work if we weren't an organization that had those standards in place and had leaders like Veronica responsible for active maintenance of those programs. Because I think it's pretty serious, and I think patients who use those products think it's pretty serious. And so, for me, of course, we want to grow our business as much as possible, but we also want to do that responsibly. That was a strong motivation for pursuit of that participation. But it's also a testament to Veronica as an individual, because I know, atene, you've had the pleasure of meeting Veronica in person. But, you know, when you're running a company, you hold a kind of liability both for the actions of kind of yourself, but also for the organization as a whole. And so if you're going to enter an area that's pretty sensitive, like medical devices, then you need a. You. You need leaders in that area that are going to. That you'll have faith in, and you can sleep at night. So, really happy with this programming.

Etienne Nichols: I definitely agree. And one other thing that Veronica said that I kind of want to touch on, or maybe emphasize was this way. The people who are working in the. In the qms, they have a better feeling for the regulations and understanding. And I think she's talking about the continuous improvement. But I'll kind of go a different direction in that you have a better and more empathetic pro. Approach to what your customers are going through and what the people you're working with directly have to, have to adhere to. If you're going to adhere to that standard, you can help those other customers who may. They're like, well, do we do this, do that? Well, we ourselves. So I could see that empathetic or empathy maybe being helpful as well. So, okay, we get the idea and the motivation behind it makes a lot of sense. What were some of the things that you felt helped you prepare the most? And I wonder if you can maybe describe some of the journey or maybe some of the changes. Were there any changes that had to happen or preparations that need to be made in order to obtain this ISO certification?

y understand the standard ISO: 1345

Etienne Nichols: What do you think she liked about it? I'm just curious. I just have to clue in that I'm curious.

Weonika Michaluk: Yeah, definitely. So, first of all, it was the first time that she saw green light guru as a QMS, and she was very happy with the thing that we ran the whole risk management there and everything. The traceability. Traceability was something great because we really could show the full traceability in the, let's say, design controls, and then because we are developing software, right? So we are using Jira, then other tools. So great integration between different pools. It also helped us to then prove the traceability, which traceability in software medical device development is very important. So that was a very, very good thing. And also kappa the process, how we did Capa was very well received by her. So shout out to both green light guru and HDD team from, from auditor.

Etienne Nichols: Absolutely. That is fantastic. You know, that traceability, it's hard to emphasize that enough because, I mean, in my past, when, when I was working at a place that maybe was completely on paper or sharepoint or whatever you want to, because I've. I've worked in multiple. That traceability is really important. And everybody, I think. I think most people understand the importance of traceability. Let's say you have an, something that happens in the field, something that hurts somebody. You want to go back and look at your traceability, say, okay, well, where did this. It was at material. When you're doing your kappa, like you said, you're going to trace back to what was the root cause and then move forward and say, well, what? Lots of material were affected by this and, and who else could be potentially in harm's way in the field? And without traceability, you can't do that. And so, I mean, there's lots of different reasons you want to have traceability from a regulatory standpoint, a safety standpoint, product liability standpoint. But that I, it's easy to just say the traceability word and we move on. I think most of us understand their importance, but I think sometimes we, we just kind of let it gloss over. So I think that's important to just kind of reemphasize. Can you talk a little bit about. Oh, yeah, go ahead, Zach.

Zach Markin: Maybe just one quick comment on traceability, which, and again, speaking from someone, you know, more, more outside of the, the process of the software, but I think that's an area where it is very challenging to foresee how difficult it is. And so I imagine when people are looking at different eqms, that may be something that becomes, for green light, that is a little bit of a barrier to overcome, because it may not be so easy for someone to see the benefits of green light if they haven't, you know, if they don't, if they, if they haven't been actually in the process of creating it. And so I guess to some extent, like, you know, maybe, maybe this commentary is helpful for someone thinking about that. But I'd say until you're actually delivering one of these projects and you have to actually produce that, that traceability analysis, I do think it's, it can be easy to say, oh, well, there's both. Both these tools have it, so it's going to be fine.

lready maybe in line with ISO: 1345

gement here, we are using ISO: 14971

Etienne Nichols: The two things that I wanted to kind of pull out from what you said was at the very beginning you said one of the things the auditors really impressed with was your CAPA process. And I think that's interesting because you said one of the things you had to kind of get up to speed on was Capa. Even me, or maybe come from the outside of the industry. And I want to highlight that because sometimes I feel like in the industry, if you look at the number of 483s, that, or the, if you look at different 483s, what are the top reasons? Well, Cap is one of the top three reasons medical device companies receive 483 and warning letters and so forth. And so I think that sometimes someone from moving a little bit outside the industry coming in, you might have a better take. I hate to say it, I'm for the medical device industry, Mike. I hate to say it. You probably have a better take looking at with fresh eyes and looking at this from best practices versus just what we've always done. And that's cool. Yeah.

Weonika Michaluk: You know, for us. Yeah. Because we wanted to really set this up properly and we put so much attention into that. So maybe that's why. And also using, again, guys, your software made it easier. But yes, we didn't have that, but we really put a lot of attention into that because we know that, you know, Capa is really important because, again, patient safety first. So we want to have these processes done correctly. We were also very happy, you know, to hear from the auditor that she was impressed with Kappa, even though we didn't have the process in place before.

Etienne Nichols: Yeah, that's cool. And I'm going to mention something Zach said earlier on the advanced statistics versus using the AI. That's pretty perceptive of, of him as well, to use that term. I think that's cool. And I'm glad you're liking the different features of the risk management because that's something we're pretty proud of at Greenlight guru, too. What about some tips and tricks? You know, are there any specific things as you went through this ISO audit that you could give advice to the listeners on and say, hey, maybe you're in stage one or stage two certification audit. Here are some things to do to not to do. Any, any thoughts?

Weonika Michaluk: Yeah. So, you know, first of all, do a proper gap analysis and also think whether you have enough knowledge, you know, internally, whether you have experts internally to do so. Because I do think it will make your life easier to even reach out to a partner that already have done this or reach out to even one consultant that already knows how to set up a qms and how to go through the audit process because it will definitely make the life easier. And of course, document everything because documentation in quality and in the regulatory world, we kind of love that what's not documented doesn't exist. Right. So have to really document everything and ensure that it's all in place. And also, I do think that investing in proper tools like Greenlight Guru will make life easier again. You can do that. You can do the whole documentation and traceability in Sharepoint or other tools, but it will just be more difficult, let's say, especially for the first time. And then once you get more and more work, it will just, I think having just proper tools will make the life easier again.

Zach Markin: Yeah, so something, it also depends on what your, what your goals are for your organization and whether you plan to, you know, continuously invest in that product or maybe just build it and then have a version of that, be stable for a long time. Because I think people, people tend to underestimate the difficulty and complexity in continuing to deliver and continuing to evolve a product. And I think across all areas of product engineering, but especially within device, the more product surface area that exists, the higher the cost of every incremental changes. And so anything you can do, and that's kind of counterintuitive because people would think, oh, you're going to get more efficient as you get farther in or as you get bigger. And that's true in some ways, but there are also some natural things that happen in a product ecosystem as it evolves and you start to have challenges that are unique to an ecosystem that has production users, that has production data in it, that has dependencies or connections to other, other third parties or other areas. And so it becomes much more important to be careful and incremental in the evolution of that platform and that product. And I think some of those more legacy modes of operation and more legacy tooling ecosystems for delivering. There may not be such a huge gap in, in a small discrete component of work. I think the more modern tools like greenlight are better, but you may not notice it as much. But I think where you'll really notice it is ingoing maintenance and evolution of an ecosystem. Cause I think a slower pace of improvement of a product is a meaningful cost to an organization as well. Not to mention that the time and overhead cognitive complexity that it would occupy from the team engaged. So I don't know, just related thought there.

Etienne Nichols: No, those are really good points. One of the terms that I love that you use is that surface area of your product. I don't know if that's a software term or I've heard that used in different places, but I really like that because it's a really good point. Any additional page you build on your software, and I'm not a software guy, so you're going to have to correct me and keep me honest here, but you have to maintain and continue to maintain for all the different updates to every other connectivity. But the other thing that I think is interesting is when you talk about the simple versus the more complex products and yeah, maybe the simple products, you can get away with using simpler tools. It reminds me a little bit of when I was in engineering school and I was on the cusp of having to learn to use a drafting board versus something like 3D CAD, like solidworks or so forth. There's some simple things that you can draw out and put the dimensions on, but it doesn't take much before this other tool makes a whole lot more sense. So, no, that was interesting.

Zach Markin: Or until someone says to you, hey, can you make that same thing but slightly different in this way? And you're like, oh, let me just do everything again. Yeah, exactly.

Etienne Nichols: Yeah, yeah, yeah. No, that's a really good point. There was one other thing you said that I wanted to bring back up, but, uh, it's, it's, it's elusive. But no, those are really good points. And I think that, oh, I know what it was. One thing that we discount sometimes, even if we have a simple product, because you mentioned, how long are you going to evolve the product? Do you have plans to do that? Do you plan to do that? Is a more mature mindset in my mind, because you are thinking this product will evolve versus somebody who says, okay, this is a simple product and we're going to try to keep its main state, steady state. Once we have it, we probably won't need to change it much on the market. Well, that's not a very mature mindset, because I was actually talking to a surgeon recently who had developed a positioner for an elbow, and he said once he got it done, prototyped up, he licensed it to a manufacturer, they built it. You say, well, this isn't exactly what I want. You know, there's a couple of things after, used it a few times, and I think inevitably is that that's, that happens even after you get commercial. I mean, you may think I'm done, but the market says, no, you're not. Would you agree?

Zach Markin: 100%. And I think especially those incremental changes in software become more difficult, not more difficult, but certainly they require greater skill or greater, more thoughtful organization of labor and process. When there are dependencies and complexities between those pieces, and if you are evolving one of those pieces that another piece is connected to or that certain data lives in one way or another, you know, you can't, there is no option to move quickly and break things. And so, you know, you want to, you want to move intentionally and you want to have good tools that support you for that intentional movement. And so I think it, there's meaningful challenges and opportunities there yeah, for sure.

Etienne Nichols: I think that's really, really wise and perceptive. It makes sense. Veronica, you were telling us a few other tips and tricks on the audit itself. Any other things come to mind?

Weonika Michaluk: You know, just be prepared. Again, invest in the time. Invest also the time to understand the processes and what, based on our actually experience, write Sops to make your life easier and not just write them, you know, from like some templates. Because for example, what we did, what we did at HCD and I also talked about it last week at LSI we implemented compliant agile process. We are compliant, but we are agile at the same time. We actually wrote our sops to make our life easier. And what I mean by that is that we are developing software. Software is a medical device. We don't really want to follow the waterfall process. And the reasons are because being agile will help us adapt to changes quicker, adapt to customer feedback, user feedback, adapt to regulatory changes as we know at the AU through using different guidances, etcetera. So by being agile, we can decrease the cost of development, accelerate the development, the time, and just improve overall efficiency and operations. So what we've done, we did this gap analysis, we checked what are the ISO requirements and then we thought how to actually make it again, agile and compliance. So that we actually wrote the sops. As I mentioned, we've already been doing lots of things and we just wrote them within the sops and made sure that they are compliant with the regulations. And I know some of the companies, and this is, I even talked to some regulatory folks at LSI as well and they told me like, you know, some of the, like, the CEO of one of the companies, they were like, oh, we wrote all of the Sops, we used some of the templates and then auditor came and they actually asked them what did they do, you know, and he was like, but we don't do this. We do it completely different way. And then they checked the Sops and they didn't even know what was written in the Sops. So the kind of tip, don't do it, just, you know, ensure that you know what's written in the SOP and, and ensure that it's already aligned with the process.

Zach Markin: If I may, I guess I would have one more maybe tip or suggestion which again is at a lesser tactical level, but I would say probably, probably everyone who gets into this space would say to do this. But I think in practice there's a difference between kind of doing it, truly doing it, and doing it in a superficial way, which is to have the quality team and the individuals who are creating the processes, the SOPs, etcetera, have a real perspective about your actual delivery process. And so I think there's a temptation, and particularly a lot of people who have, like, careers in quality, you might have some kind of separation between the quality team and the delivery team. And that's natural, because there are certain aspects of the compliance regimes which require those roles and other things like that. But in our case, for example, before Veronica left us to do her work at large device companies, and before she came back to us to run our sandy program, she was a product owner in our digital health organization. And so she knew very well that she had an intimate knowledge of our delivery practices in a way that I think that was very beneficial to the process. And so you might not be able to have an individual like that who, you know, you're able to, but I would encourage doing something like that. And short of that, Veronica also spent a lot of time with our delivery leaders in the. In the creation of that. So I guess I would just say, like, you know, kind of building on Veronica's tip to, you know, to design your. If I. If I may interpret Veronica's language, I would say that a tip is to design your sops with intentionality, that are informed by your actual best practices for doing the work. But in order to do that for the executives, I would say, make sure the teams that are responsible for those areas have both of those domains really well. And ideally, someone who's expert in both, which is Veronica, in this case.

Etienne Nichols: Yeah, that's a really good point to highlight that experience, because I've been in many companies where we imagine the ideal way of doing things, and we put that on our SOP, and it doesn't necessarily reflect what we're actually doing. And there's nothing wrong with the way we're doing it, but we just, you know, the people who are writing the ideal perfect from a regulatory standpoint, what would an auditor want to see? Well, they may not actually want what we think they want. They want to see what we're actually doing. So I think that's a really good point. You know, I. One other thing I'll say about that, I'll just use agile as example, because you both have kind of mentioned that. And Veronica said we wanted to do an agile method. There is even an ideal agile method, whether it's scrum, you know, depending on whether you go scrum.org or scrum alliance, I mean, who's your perfection, your. Your model are ideal, I'm sure you all have your own special take on it, and I'm guessing that's written into your sops. Per how you approach project management, not necessarily just the ideal agile versus, or the ideal project PMI, project management institute versus, you know, waterfall methodology, it never makes sense to just look at the ideal and then write that into your SOP. It's rather write what you do and then do that. It was a little long winded, but yeah. Yeah.

Zach Markin: Well, and I guess I just maybe add one, if I may. I don't want to. I would say that maybe just responding to your commentary, speaking outside of the software medical device space, I would say there's not one ideal agile, but there is the right, there is the right flavor of agile for the work that needs to be done. And so you do lose some flexibility when you move to a compliant agile framework, because the compliant agile framework, you are picking an ideal agile for people who are maybe like skiing, you can think of that like a mountain ski that lets you kind of go everywhere. And so, but if you were, you know, if you were outside of a regulatory regime, you might pick a specific, a specific ski for a specific area. But I, you know, if you are thinking about working with a service provider, I would encourage a device company to ask and have a conversation with that service provider to understand what is the flavor of agile or the flavor of delivery that they use, and then have some thoughtful discussion about whether that's the best fit. But we have no illusion. There are areas of device work and there are areas of, of digital health work and our work more broadly, where it's not a fit. And we're pretty candid about that and we're happy to send folks to folks who we think are a better fit or one way or the other. But, so I would encourage people to maybe go one level deeper on process and particularly the concept that informed the process.

Etienne Nichols: Really good point, because the ideal, when I mentioned that, and I'm glad you clarified that, is it ideal for just efficiency to get a product done as quickly as possible, or is it ideal to be compliant with Eumdr versus FDA? Or what's the ideal? What is it really fit for? That's kind of the point.

Zach Markin: And who are you as an organization? And you might be one organization for the first five years of your organization life, and then your product might mature and end up in a different place. And that's normal. That's how, that's natural.

Etienne Nichols: Yeah, that's a fun conversation. Someday we're going to have to meet in person. Zach we'll have to talk more about this because this is fun. Let's talk about what's next for HTD Health. And I'd also be interested in how you plan to use green light grew in the future, if that's evolving or changing. But both what you're doing in the future and how you plan to use these tools in the future.

Zach Markin: Veronica, maybe you want to comment within the software medical device domain and then I can add a little commentary more broadly if that works for you.

Weonika Michaluk: Definitely. So when it comes to software as medical device, you know, we want to continue improve. As I mentioned, continuous improvement is at the base of our collaboration. We want to just also broaden our reach and serve different organizations, different customers. We are currently serving some great organizations and we want to just help them grow and help them, you know, get to FDA clearance or, or approval. As this is our really focus. We want to also keep on meeting great people like you at the end and keep on learning from other industry experts, as I do think collaborating collaborations and extending partnerships also help us grow and help us serve our clients in a better way. And Zach, feel free to add.

Zach Markin: Regarding HDD, the themes are similar. We're both focused at the practice level, within each practice of the business on continuous improvement, but also organizationally continuously improving. And that is reflected in all areas. Maybe a phrase to describe how we're evolving as an organization and a business is that we're moving towards what we call best in the world thinking. And so basically that means, is there a credible opportunity for us to become the best service provider in the world within the thing that we're doing? And if there's not, then what is the thing where there is a credible chance to do that? And so we're very focused on asking and being honest with ourselves about what those things are and picking areas that are big enough to be interesting but narrow enough that we really have a credible shot at that. And we're fortunate to be in a place where there are some areas that are really interesting to us that we think are viable targets for that kind of thing. So maybe at a future conversation we could go deep on one of those in the, maybe in the, in the software's medical device domain.

Etienne Nichols: Cool. I love that. I actually have tried to let my career guide me, and I think everybody would do well to look at that and say, could I be the best in the world that this, you know, that, that's, that's really cool. I don't, and you don't have to.

Zach Markin: Be the best out of the world today. It just means is there a pathway and can we take, is there, are there things we can identify and steps we can take that'll move us in that direction? And I think if people as individuals or organizations do that, then you're probably 90%, 90th percent pile already and then climb the remaining ten.

Etienne Nichols: At the very least. I think you could use that exclusionary criteria and say, I know I couldn't be or we couldn't be the best at this. Google's got it down. Let's do this other thing. But using that as a guiding star. I've never heard anybody talk about that. That's cool.

Zach Markin: Well, it's very important in services, and people need to be aware of, you know, what our services is. You know, I would say, like, it's true in product ecosystem because every product has competitors. Services are a little bit further in the spectrum of a broader range of competitors. And so I think it's a, yeah, I could talk for a long time, but maybe I'll pause there.

Etienne Nichols: No, I really appreciate it. That's a fantastic goal, and I look forward to seeing where you guys take that and where that leads you. I don't know if I'll see you all in Copenhagen, but if you're at the true quality roadshow, maybe we can catch up again there. I think it's May 16 and there are future road shows as well. But it's been really fun talking to you all. Any last piece of advice for the audience before we close out?

Zach Markin: I sold too much already today, so I came to Veronica.

Weonika Michaluk: So, as Zach mentioned, investing the right people have rights, partners, you know, and just be open for the challenge because software as a medical device, again, I will say you refer to the mountain. It's like hiking a mountain. It's very challenging, but at the end, it's very rewarding. And the view from the top, it's simply amazing. So, you know, it's not easy, but it's worth it.

Etienne Nichols: And I'll throw one other thing out because we don't have the picture of the visual. When Veronica gets to the top of the mountain, as hard as it is, as hard as HTD, you know, the things they do. She could do a split at the top of the mountain, too, so they make it look easy. So I'll just throw that loud last piece out there. Really cool. Love you guys. Really glad we got to have this conversation. Appreciate you listening, and we look forward to next time. Everybody take care.

Etienne Nichols: Thank you so much for listening. If you enjoyed this episode, can I ask a special favor from you? Can you leave us a review on iTunes? I know most of us have never.

Etienne Nichols: Done that before, but if you're listening.

Etienne Nichols: On the phone, look at the iTunes app. Scroll down to the bottom where it says leave a review. It's actually really easy. Same thing with computer. Just look for that leave a review button. This helps others find us, and it lets us know how we're doing. Also, I'd personally love to hear from you on LinkedIn. Reach out to me. I read and respond to every message because hearing your feedback is the only.

Etienne Nichols: Way I'm going to get better.

Etienne Nichols: Thanks again for listening, and we'll see you next time.