Common QMS Mistakes SaMD Companies Make

What pitfalls do SaMD companies run into when they set up their QMS? How can your company avoid making these QMS mistakes?

Today’s guest, Karandeep Singh Badwal, is a Regulatory Affairs Quality Consultant who is well-versed in EU MDR, and regularly works with medical companies producing Class I, II, and III medical devices.

Listen as we talk about what a quality management system is and what the goal of a QMS is, the importance of validating software, and the differences between AI and machine learning, among other things.

Listen now:

Like this episode? Subscribe today on iTunes or Spotify.

Some highlights of this episode include:

• A quality management system is a structured system of procedures and processes covering all aspects of design, manufacturing, supply, risk management, management responsibilities, customer-related processes, corrective actions, and preventative actions.

• Quality management systems come in several forms.

• There are differences for QMSs at SaMD companies

• Validating software means making sure it can do what needs to be done and produces consistent results

• Issues or shortcomings that SaMD companies have with validating

• For SaMD, intellectual data that you’re storing on your servers could be considered customer property and needs to be addressed in your QMS

• It’s important to define specific roles and responsibilities for when the person ordinarily responsible for that role isn’t available.

• The differences between AI and machine learning: AI basically mimics human behavior. Machine learning is more like a neural network.

Links:

Karandeep Singh Badwal's LinkedIn

Karandeep’s YouTube

MedTech Podcast

Etienne Nichols LinkedIn

etienne.nichols@greenlight.guru

Greenlight Guru Academy

MedTech Excellence Community

Greenlight Guru

Memorable quotes from Karandeep Singh Badwal:

“That’s one mistake that a lot of these software as a medical device companies are making. They just validate their own software.”

“Basically, what I’m looking for is evidence to prove you’ve done what you said, basically.”

“Customer property is one that I see a lot of Software as a Medical Device companies not addressing effectively.”

“Software as a Medical Device companies don’t realize that the software platforms they use are suppliers, and those need to be controlled.”

“The whole point of an internal audit is you want someone who’s independent.”

Transcript

Anouncer: 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.

Etienne Nichols: Hey everyone. So glad to be back with you. Today's episode is about the pitfalls of softwares and medical device companies, SaMD, sometimes run into the things that they run to as they're building out their QMS. To navigate this discussion, we spoke with Karandeep Singh Badwal, founder of QRA Medical and hosts of the MedTech podcast. Karandeep works with companies all over the world to help them with ISO 1345, 27001 and 14971 compliance. He's well versed in EU MDR, which right now anyone who's well versed in EU MDR is pretty much worth their weight in gold. So we love talking to those people. And he also works with Class I, II, and III medical devices. On top of all that, he's the host of the MedTech podcast, where he interviews MedTech leaders across the industry. So definitely check out his show. We'll have a link in the show notes. While we tried to focus on software as a medical device, a lot of what we discuss is applicable to anyone implementing a quality management system. So we hope you enjoyed this episode. Thanks for listening. Hey everyone, good to be back with you all today. Today I'm with Karandeep. Karandeep, great to have you on the show.

Karandeep Singh Badwal: Thank you for having me on the show. It's a wonderful opportunity to be here, and I hope we have a wonderful conversation.

Etienne Nichols: Yeah, I'm excited for it. I know we've talked a little bit in the past, but we've never spent a lot of time together, so I'm excited to dig into your experience and background and talk about the different things that are related to medical devices. One of the things that we talked about before we started hitting record was quality management systems. And I know we were going to talk about quality management systems specifically for software as a medical device, but maybe we could start out with talking about what is a quality management system?

Karandeep Singh Badwal: Yeah, it's question often get a lot, what exactly is a quality management system. So in short, it's basically a structured system of procedures and processes covering all aspects of design, manufacturing, supply, risk management, management responsibility, customer rated processes, corrective actions, and preventive actions. And the whole purpose of a quality management system is to have number one, optimal end product, and more importantly, minimizing risk for end users.

Etienne Nichols: Interesting. I really appreciate your definition there. Makes a lot of sense. Sometimes when I talk to different people, they're looking at different softwares and they're calling it an EQMS. That is their quality management system in their mind versus the procedures. And really they're two different things. I mean, would you agree with that, or how would you define that? What are your thoughts?

Karandeep Singh Badwal: So yeah, quality management systems can often be in many different forms. You have the traditional quality management system, which is paper- based, what you would see in traditional offices, everything's on paper, everything's recorded by hand. And then EQMS on the other hand, is basically everything is electronic, everything is online. And in the middle, which I'm seeing as well is hybrid systems, which is a blend of the old paper based system, also combined with the electronic quality management system. And it's usually a mix of all three that I'm seeing in the industry.

Etienne Nichols: And I guess the point I'm making, I don't know if I'm making it very well, but when we talk about a paper- based quality management system, we're not actually talking about the paper, we're talking about the information on the paper. Similar with an EQMS, we may talk about different softwares, but it's not the software. There are aspects that the software does helps you achieve, whether it's signatures or traceability, but the information, it's your approach to quality. Would you agree with that?

Karandeep Singh Badwal: Yeah, definitely. So a quality management system is basically, it's the records that you generate. That's the most important piece of it. A procedure just tells you what to do, but then you've got to go out and do it. The analogy that I can give, it's like having a car, you've got the engine, you've got the gearbox, you've got all the controls there, but you need to actually sit down and drive the thing to actually get something out of it.

Etienne Nichols: Yeah. So maybe a question I'll kind of add on is now that we kind of have talked a little bit about what a quality management system is. Specifically, for software as a medical device, I run into some companies where they think, " Well, we're not really a medical device, we're SaMD." Okay, well you're still a medical device, you're just a software as a medical device. A lot of times they don't see themselves the same way. How do you view the QMS from the perspective of software as a medical device? Are there differences, and if so, what differences are they?

Karandeep Singh Badwal: There are differences there. So what's common with a lot of software medical device companies, because they don't have manufacturing facilities, it's not uncommon for me to come across software medical device companies that may not have a physical office, or they may just have an office that's never used. It's just an actual address that they have hence they have a remote working team. One of the most common mistakes that I see within software companies for quality management systems is they look at the term software validation within a quality management system and they assume that it means validating their own software. Which yes, they have to do, but software validation means that all of the software that you're using within the scope of the QMS. Do you have somewhere to store your files? Are you using an EQMS where everything is in place? Do you have things like complaints portal? Are you using workflows? These all form part of that software validation. And that's one mistake that a lot of these software medical device companies are making. They just validate their own software, but not all the other software that they use within the scope of their work.

Etienne Nichols: So how do you determine what the scope of that software validation is? I mean, for example, I come from a physical world where I was a mechanical engineer, I used SOLIDWORKS quite a bit. I can't imagine us having validated SOLIDWORKS, but I know there were softwares or pieces of software tools that we did validate, our EQMS and things like that. But how do you draw that line? Any tips you can give?

Karandeep Singh Badwal: So generally what I say with companies is first, comb down a list of all the software that you're using. It could be Word processing, it could be servers, it could be something like G Drive, it could be like Amazon AWS, anything that's sort of... Comb down with a list and see what you're doing in those. If you are storing documented procedures or maybe you are storing draft files in there, that's part of your quality management systems, hence needs to be in scope. Also, sometimes they have backup systems in place. Some companies may every week or so have an internal server, maybe they're using an EQMS and every week or so they downloaded those files and putting that into their backup service. Again, that needs to be validated. Some companies are using workflow systems, i. e. inaudible or nonconforming product that needs to be validated. Also, your complaints portal, if you go onto a website, often if you make a complaint about a product, it often may feed into a software. So it may be using some sort of project management software such as Trello, where they've got that complaint system coming in. Again, that needs to be validated. So if there's any activities within the scope of your quality management system that involve the use of the software, then most likely that needs to be validated. Now what does validation mean? Is that software able to do the task that you want it to do consistently and provide a reliable results?

Etienne Nichols: So when you go through that validation, for example Trello, I'd be curious what kind of validation, what does it look like? What are the procedures, as detailed as you want to be, however deep you want to go?

Karandeep Singh Badwal: Yeah, so what I often find with companies is they're using Trello as part of their complaints portal. So for example, I may go through their app, I may go through their website or even via an email where I submit a complaint and it might not just be a complaint, it could just be feedback, Look I could be saying, "You know what? This is a fantastic product and I love this." I could be saying something like that. And then that may feed into a trailer board and that trailer board is basically theirs. So a member of staff picked it up, they see that feedback and they respond to it accordingly. So if we were trying to validate that, basically what we do want to do is, number one is I would send out that test email. I then want to see that it's come onto their Trello board, and then I want to see the evidence of the staff replying to that and me actually receiving that at the other end to say that my complaint has been looked into or we've done X, Y, Z to rectify this for you, so that is basically it. And the way you record that is up to you. Some companies like to do video where they have a screen capture where they show that whole process. Some companies prefer to use screenshots, and then again, some companies are very old school and prefer to print things out. So basically what I'm looking for is evidence to prove that you've done what you've said basically.

Etienne Nichols: So when you do those things, are there any common mistakes that you see companies getting into with those validations?

Karandeep Singh Badwal: Yeah, the most common one is not collecting evidence is they just said, " Yes, we tested it and it came upon our system." Like, great, you've said that, but where's the evidence? I can write on a piece of paper that I've done so many things, but where is the actual proof? Where is the evidence? And I need to see that from an auditor's eyes. That's the way you need to see that. If you were being audited and they pick up these people say piece of paper and say, " Okay, we've done X, Y, Z," great, where's your evidence for doing this? " Well, our manager did it." Great, what evidence do you have? So again, that's why I recommend things like screenshots or video captures or even just sign documentation to say that you've done it.

Etienne Nichols: Okay. You kind of mentioned the two different types of software validation. So mentioning, validating the elements of your EQMS. Are there other issues or shortcomings that you see companies getting into with that? And feel free to talk about that, or maybe we can even talk about validating the software itself in whichever direction you prefer to go in.

Karandeep Singh Badwal: The way that a quality management system, a term that we use, especially in ISO 13485 is risk- based approach. So you want to evaluate risk. So when you are validating your software, especially if you're using things like cloud- based servers or anything that's based on the cloud cloud, there's going to be times when there's going to be server outages, it happens, there's going to be risk of hacking. So when you're validating that you maybe want to look into other things that what would we do in the event of a server outage? Okay, we've got a backup system in place. Great. Do you maybe need to have multifactor authentication? Because another thing that's part of validation, especially when accessing files is you want to have controlled access. You want top management or maybe the QAR person to have full editing access of all documents, but you don't want someone who works in human resources to have full editing access. You only want them to have viewing access. And again, anybody outside of the company, you want them to have no access at all. Again, that's something ideally that you should be validating. Number one, that only the people with the correct credentials can actually go in and view the files. Only the people with the correct roles are actually able to go in and edit them. And the most important one is sometimes, let's face it, we're humans mistakes happen. Sometimes we make an editing mistake. Is there a way for you to retrieve that old file back? And again, that's something you want to validate. So if we just push the requirements aside or any legal requirements, ideally as a company, you want to be doing something like that. If you make a mistake, you want to be able to retrieve things. And again, let's face it with companies, people are always leaving, people are always going, You also want to make sure that there's some form of audit trail. Who audited the document? When did they audit the document? What changes did they make? And maybe you can revert to an older version because let's say in the future, maybe two years from now you are having an audit. The version of the procedure that was followed two years ago is going to probably be different to the one that's being followed today. And you want to be able to retrieve the older version to see why you did the certain actions that you took at that time because they may not follow the procedure that you currently have today. So it's just basically building that history trail. That's what we're looking for.

Etienne Nichols: Yeah, when you start talking about those different things, the different things, you're validating the different processes. I had a flashback to when I was working in a certain company where whenever we had a drawing that came up with a certain person's name on it and I brought it to my mentor, " Hey, I've got this issue, we've got to work on something here." He'd say, Oh." He knew all of the different things that might be wrong with this in this instance because this one person. So I know training is another thing and making sure those things happen. We get questions about that sometimes. And maybe this is going off in a different direction, bear with me here. But what about validating your training programs to make sure that those are effective? Is that something that you delve into or see issues with ever?

Karandeep Singh Badwal: Yeah, definitely. Because what a lot of companies do, the mistake that they're making, this is another mistake that we go on is training is what they do is they just say, " Have you read the procedure?" And you sign a document and you say, " Great, fine." You've read the procedure, but has that person understood the procedure? And then what I say to these people is basically within your training, you want to make sure that the person actually understands that procedure. Because if I write a super complex quality and regulatory procedure and then we have someone who's maybe just come out of college and maybe doesn't understand what quality management systems are, are they able to pick up this procedure and actually make sense of it? That's what you want to do in your training. So the way you do that is often the way that I like to do it is you come up with sort of tests. So for example, I will maybe, let's say for example we're training them on CAPA. What I would do is I would just create a fictitious CAPA and a certain scenario and I've given the procedure and say, " How would you deal with this?" And if that person gets it wrong, that is not the fault of the person. It's the fault of the person who has wrote that procedure, has not made it simple enough for the person to understand to be able to use it. So again, if in training that person is making mistakes, great, because it means we can improve on it.

Etienne Nichols: I love that. In my career I've heard that human error is not really a very good root cause and so that makes a lot of sense how you do that. I like how you do that, giving that CAPA, walking through it. That's cool. So when we think about like SaMD specifically, we can talk about validation of the software and then maybe the QMS processes, maybe moving away from validation. What specifically do you see or other issues or common mistakes that you see SaMD companies getting into?

Karandeep Singh Badwal: One of the most common ones, and this is specific to ISO 13485, which is 7.5. 10 customer property. Now when we use the term property in traditional devices, people think of something physical, they think of a building or if I use the word property to you, you might start thinking of real estate or maybe commercial buildings. But what people don't realize, especially for SaMD companies, if you have an intellectual property or patient data that you are storing on your systems, that can be considered to be customer property. So as part of ISO 13485, they are certain clauses of which you can say are not applicable to you. So a lot of companies are saying that we don't have any customer property because they're thinking of the traditional physical sense, but they have patient data, they have intellectual property that belongs to your customer and that needs to be addressed with the new quality management system. How are you storing it, what backups do you have in place? Cybersecurity is other interest in one as well. So yeah, customer properties is one that I see a lot of software as medical device companies not addressing effectively.

Etienne Nichols: Okay. And what about if they have a physical component? Do you see a lot of people, you know what I mean? When I've talked to SaMD companies, they're either software developers typically seem to be coming to the medical device industry or medical device physical people who are getting into software, not necessarily always a SaMD person. So are there issues with that transition when they have a physical component and can you speak to that?

Karandeep Singh Badwal: Correct. I have often seen that with companies where, for example, let's say something that detects certain types of lung conditions and I say, " Great, where are you getting your data?" " Oh, we have a physical operators that you breathe into." " Oh stop there." You now have a physical element to your device. You're no longer just a SaMD company. And then again, when you have a physical element to your device, you have product handling, you possibly may have sterilization, you may have cleaning. Again, it's a different thing. For example, with a software medical device, a recall is you just can just turn your cloud server off, that's it. Nobody has access anymore. But a physical device is completely different. You are possibly going to have to go into hospitals, you're possibly going to collect that from people's homes. So let's say you have a fail safety corrective action or something goes wrong with your device, you're now handling physical product. And again, number two, because you've now got physical product, that's something that you're handling. Again, that's also customer property. You also need to have segregated areas in your workspace. So if you have a defective physical product, you want to keep that away from physical product that's working. You don't want to mix the two. So that's another mistake that a lot of software medical device companies, because they're predominantly software. Okay, great. But if you've got a physical element to it, like a data collection tool, you need to put measures in place.

Etienne Nichols: You made me think of a very specific, maybe I shouldn't get too specific, I don't know, but suppose there is a wrist watch, a smart watch that you were on your wrist, that there was a software too element to that was passed as a Novo. This is something I've always wondered about and I'll just say it. So the Apple Watch has the SaMD component to their algorithm, but I don't think the watch itself does. So I'm curious, what are your thoughts about the, I've never quite gotten an explanation I like about that and it seems like whatever information you put into your algorithm, the amount of control for those, that algorithm should be applied to the device that it is getting the information from. But I'm curious what you have about that, what your thoughts are.

Karandeep Singh Badwal: It really depends. So when I've arrived first work with the company, the first thing I always bank on about is an intended use statement. Because as silly as it sounds, a lot of companies don't know what the product is and what does that mean? What are the medical indications, who are you treating? Is this pediatrics, is it adults? What is the clinical setting that's going to be used? And is something going to be used by the lay user is going to be something that's maybe in a professional setting, is it going to be in a hospital settings? And that's really it. So when you use something like the analogy of an Apple watch, it depends on the intended use. So the software is there, but if it's only intended to be used with an Apple watch, then that element also becomes part of the device because that physical component is required for the software to be able to do its job. Without that physical component there, the software is more or less useless. So that becomes part of the device.

Etienne Nichols: Okay. Well I'm going to have to do a little bit more research on that then though, but I agree. Yeah, that makes sense. Okay. Well when we go into, and I don't know how deep you want to go necessarily with the SaMD with physical component, are there other issues with the validation or even verification when you have those two mixed together? Any other advice that you can give companies as they're getting started with that part of the development process?

Karandeep Singh Badwal: Yeah, clearly define the interaction between the physical component and what information is going to be feeding into your software device and how that affects the algorithm because now you've got a physical component in there, that physical component can fail. And again, with software, what's also interesting is you can have false positives, you can have false negatives, you've got cyber security issues. Those are other things you need to look into basically. And again, that physical component that you have is communicating with your software. That leaves you liable to things like hacking, potential loss of data. That's also another thing that you have to control.

Etienne Nichols: Okay, that makes sense. And really how does that fit into your quality management system? Because I know usually we tailor those to software when we're working with software companies, how does that fit in?

Karandeep Singh Badwal: So how it fits in is you've just kind of got to treat it like a traditional physical device because you've got things like non- conforming product for example, in ISO 13485. There's a different procedure of when the defective product is noticed or the non-conforming product before delivery or after delivery. With the software, that's not really applicable. That's kind of it. So that's the other things I have to look into. Like I mentioned, is you are handling property, you've got storage, your distribution, and again, if you have physical components, again, this often is modifiable or depending on the customer requirements, so you're going to have different components to it. Again, you also got storage as well. So how are you going to store the defective product away from the actual product that works? And then that's it basically. And again, recall as well, this is an also interesting one. A lot of companies are outsourcing their manufacturing or maybe buying in this product. And this is another mistake companies are making. They say, " Oh, we're a software medical device company. We're buying in our product from somebody else. It's got nothing to do with us." Okay, but it's got your name on it, hasn't it? So if I have a complaint, I'm going to be contacting you. So although you buy the product in from somewhere else and you don't manufacture it, on paper you are the legal manufacturer for that product because you're slapping your name on it.

Etienne Nichols: Yeah, that's a good point. And it kind of begs the question, if you go one layer up, I guess with your quality management system, when you're looking at those different components, whether it's physical or software, if you were purely software, maybe you'd say, well these clauses don't apply to us, but with physical, well they do. It really boils down to right sizing your QMS and writing those procedures where it's clear in this case, whether it's software, it's not applicable, but in this case it is. Would you agree? I mean it's really just a matter of tailoring that at those SOPs to your specific scenario. Is that correct?

Karandeep Singh Badwal: Correct. And generally what I recommend is in your quality manual, have your non- applicable state of there and put your justification why. So the idea being if an auditor comes knocking on your door effectively as you would annual relief for ISO 13485, or if you're having your initial audit, they can just pick up that quality manual and say, " Okay great, these are the reasons why these particular clauses are not applicable," and I think this is fine. And that's it just makes the auditor's life a lot easier. Yeah.

Etienne Nichols: Okay. So going one layer deeper, so we're looking at the entire quality management system, what is one of the biggest areas or pitfalls that you see companies getting into when they're setting up that quality management system? Whether it's softwares or physical device or both? Is there a specific area that you think really, really deserves a special attention?

Karandeep Singh Badwal: Yes. So often I find companies where they have procedures in place and they define specific roles and responsibilities, which is great. You've said the RA manager's going to be doing this and the HR manager's going to be doing that, but what are you going to do when the RA manager's not available? So what I always say to companies is always in your procedures say that at certain times or in certain cases that you may give this to a suitably trained deputy and I said trained deputy because if that particular person goes on a holiday or is long term sick, it means that somebody else can take over that procedure. Now if there's only one guy in the company that can do that procedure and that person's not available, that basically means you can't follow the procedure.

Etienne Nichols: Yeah, that makes sense. So if we go back to the beginning when we were talking about software as a medical device specifically, there's something that just popped into my head that I don't think we, well we didn't cover. Machine learning versus AI is another thing that I think sometimes we get a little bit tripped up by. And how do you capture that? Is that something that you want to cover as far as ML versus AI and what the differences are?

Karandeep Singh Badwal: So yeah in layman's terms, AI is basically mimicking human behavior and machine learning, think of a lot of virtual neural networks. So AI is very good at what it does, but it does one thing. Machine learning is like your brain, it's constantly learning and it's learning from its mistakes. Those are the difference between the two things. However, AI machine learning are so overused, they often cross link to things like digital health and telehealth, but they're very, very loose terms and they can mean a lot of things where people automatically see AI, they start thinking of what they see in the movies and things like that. But AI's a bit more complex than that and it's really depends on what you are doing with it. That's what it is because just consider it a tool. And with a tool you have many different things that you can do with it. It's how you use it basically.

Etienne Nichols: So what makes me think of that is, for example, machine learning, when you have something's changing, it seems like that would make it a little bit more difficult to validate. So we started off talking about validation. We'd start off talking about CMD with machine learning and AI, is that accurate? I mean are there any nuances to the validation of that type of software or any eccentricities or specific aspects?

Karandeep Singh Badwal: From a technical point of view, yes, but in terms in the scope of a QMS, whether the device is AI or not, doesn't really directly affect it. That's more to do with the product itself. And again, as part of the regulatory framework, you know just can't keep changing your intended use all the time. So generally what companies do is they release their devices in the form of iterations. So maybe they've got AI, maybe they've got machine learning in the background that gathers a lot of data. So they create a version two of the device that they release and then a version three and then a version four. That's generally the trend that I'm seeing with companies.

Etienne Nichols: I love that you bring it back to the intended use because that makes it much more clear, what am I really trying to accomplish with this device? And it's almost like you said, your QMS isn't going to change necessarily with your device until things are out of scope or things actually truly do change. So yeah, that's a good point. To bring it back to the intended use statement. What other advice do you have companies kind of starting out? Well actually let me kind of tweak my question. I really liked the example you gave with giving that kappa or that example of a kappa and having someone go through it and see if they trip up or maybe your Trello example, a pseudo issue and see if somebody catches it. Do you have other tactics or strategies that you use to kind of pressure test the QMS?

Karandeep Singh Badwal: So other strategies, I mean maybe we're going slightly off topic here, but one topic I'd like to talk about is supplier evaluation. So sometimes I have companies hire me as a consultant, whether that be to build a QMS or sometimes doing internal audit. And the first thing I look at is that their supplier evaluation process. Why am I not a supplier there? Why have I not being put down as an approved supplier? Because I am supplying you a service and that needs to be validated. How do you know that I'm correctly qualified? How do you know that I'm able to do the job that you hired me for? That's very important. And again, on supplier evaluation as well, if you're using software like Trello or Amazon, AWS, et cetera, they are supplying you a service. They are suppliers. So again, that's another mistake that SaMD companies are doing that. " Hey, we don't have any supplies." Great. Because when you look at it from the physical product sense, there's may be a supplier of 10 components. This supplier provides this type of component, this supplier is for sterilization, but software, medical device companies are not realizing the software that they are using our supplies and that needs to be controlled.

Etienne Nichols: So in that vein or that thought, what kind of perspective should be somebody having when they're looking that supplier? Anything outside the company, whether it's a person or a tool or a company that interacts with my company, is it to that degree or do you have a more succinct way of applying your logic?

Karandeep Singh Badwal: So again, it goes back to lot was saying with the software validation, if you just have every single software or every single supplier that you have there and then you deem what is term to be a supplier. So for example, if you're storing your file somewhere, that's a supplier. If you're using a complaint system like Trello, again that's supplying you a service, it's part of your customer portal. If you're using people like me, we're service supplies. So it's defining that. And again, in some cases you can't control suppliers. So generally you want a supply quality agreement with a supplier where you write down that these are the services that we want you to offer and you do that. Good trends trying to do that with a big company like Google or Amazon. So in those cases what you do is you take the risk based approach. So your agreement will be the terms and conditions that you have with them basically. And then you have a risk based approach. And again, that's part of your software validation. You validate that they're able to provide that service what you were do in the event of an outage. So you control what you can do within the scope of what you have. Basically with big companies, you may not get that. If it's just a company there, maybe there's 10 employees and it's like a home brew specialist software. For example, let's say some purchasing softwares are very specific. So for example, one point I worked with a contact lens manufacturer and it was just a very small company that was creating it for them. In those cases you can have a tailored supply quality agreement. With the bigger companies you can't. So you just control what you can basically.

Etienne Nichols: Okay, that makes sense. And you mentioned risk based approach a couple times throughout the conversation. I wonder if you could go into a little bit more detail. So I know 1345 kind of has that specific lens. How do companies apply that to the different aspects of their, whether it's QMS or business in general, any advice there?

Karandeep Singh Badwal: So generally what you do, of course you're going to have a risk assessment as part of your sort of quality management system and also for your product as well. What you basically want to do is look into it and see what are the risks that are in place and you want to categorize them. So for the argument of this conversation we're having, we just have high, medium, and low. That's it basically. So low risk is something you maybe don't need to worry about. Medium risk, that's something you can maybe mitigate and bring that down. And high risk is what you need to focus on. So what is the risk of something happening? What procedures can you put in place to mitigate that risk? And then what is the residual risk after you put that in place? Now in some cases, so risk, the word that you use is as far as possible, as far as ISO 14971, you reduce a risk as far as possible. In some cases you can't eliminate risk altogether. It's always going to be there. But in some cases, regardless of the mitigation that you put in place, the risk may still be present or may still be present in sort of a higher level. That's something that maybe you want to monitor over something that's a much lower risk basically. So again, you can't remove risk altogether, you just do the best that you can to mitigate that. And the most important thing is you monitor it. And again, when that risk arises or something happens, you may want to put corrective actions in place and you're constantly looking to improve that.

Etienne Nichols: So as far as possible, I think I understand what you're talking about there. I remember another acronym that I think it used to be was ALARP, as low as reasonably Possible.

Karandeep Singh Badwal: Yep.

Etienne Nichols: Can you speak to the differences there? Maybe philosophical differences.

Karandeep Singh Badwal: Philosophical is as low as reasonably practical and as far as possible, I suppose they're interchangeable, can be determined to be the same. But again, the whole point of it is basically try to reduce that risk as much as you can basically. That's basically what we're trying to say.

Etienne Nichols: Yeah, yeah. Okay. One other aspect of that. I know sometimes when we look at risk- based approach from company, if I'm maybe the finance guy, I'm thinking a financial risk. And I know that's not something that the FDA certainly, and I'm sure every other agency considers a risk that they really deem to be worth. Let me skip to the end. So when you do BRA, so a benefit risk analysis, whether it's for your company, your QMS, or your product risk that is associated with economics, that might not necessarily be a consideration. Do you deal with that very often or what are your thoughts?

Karandeep Singh Badwal: Correct. And I think that's probably the difference between ALARP and as far as possible. ALARP considers economic risk, but as far as possible doesn't consider that. So I think that's probably the key differences between the two.

Etienne Nichols: Yeah, I always go back to when we're making medical devices, we're affecting people's lives and not necessarily our pocketbook, although obviously the worker is worthy of his wages, but the definitely goal is to improve the quality of life. Well this has been a great conversation. Any other thoughts? What other advice do you have for companies working through these different early development stages?

Karandeep Singh Badwal: So another mistake that I'm seeing is unfortunately internal audits, companies are auditing their own work. That's not the purpose of an internal audit. The whole point of an internal audit is you want someone who's independent. Now the word independent is often interpreted as external. You don't have to hire somebody external to do an internal audit. And the example I'm going to give is we got regulatory and we've got human resources. Human resources can audit regulatory, regulatory can audit HR, but they can't audit themselves. And that's what I say to companies is don't just have one internal auditor. Have maybe two to three people that are trained within the company to be able to do that. It doesn't always have to be external. Of course the benefits of having somebody external is they are not familiar with your systems and they may see things that you don't see. So for example, if you're doing something for years and years, you get very used to it, you get very complacent and there's maybe certain areas that you may not see, but hiring somebody external, you have somebody with a fresh set of eyes and is able to spot things. But not just that. External people are also quite experienced working with other quality management systems. Not only can they spot issues with the system, but they can also spot improvements. So there are benefits to both, but what I say to companies is that is don't audit your own work, have other people within the company that can audit different people. That's the best way around it.

Etienne Nichols: What about the flip side? What if I'm a small two person company and I'm thinking, " Well I'm going to audit my partner and he's going to audit me," but is that internal enough? Is it possible to have someone externally perform an internal audit?

Karandeep Singh Badwal: Correct. That does happen. I do get hired sometimes to do internal audits as well, and that's what I recommend. If you're a company that's very small, and especially if you're a small startup, you're super busy, you're focusing on 20 things at a time, you're probably haven't got the time to sit there and do a fully focused one day audit without any other distraction. You're probably going to be responding to 50 other emails. And again, the last thing that you want is you have an audit test sitting across from you and saying, " I'm sorry guys, I can't certify you because of these reasons why."

Etienne Nichols: Yeah.

Karandeep Singh Badwal: It's more cost effective to get someone to be able to put the procedures in place for you and tell you what your mistakes are to make sure that you get through the audit. But not just that. You want to be able to sleep at night making sure that your product is safe and not harming people. That's why it's good to get experts in to do with these things.

Etienne Nichols: Absolutely. So I kind of take your logic that you were talking about as far as using HR to audit regulatory, regulatory to audit HR, having multiple people in there. So if you apply that to the product development process in like CFR part 820. 30 where it talks about that independent reviewer for your design reviews, a lot of times companies will specifically say, " Okay, we're going to have a stage one design review, stage two design review or phase one, phase two, and we'll have a specific independent reviewer review everything." But that's not necessarily the case or is it, I'm curious what your thoughts are. Is it possible to perform a design view on certain sections of that design review and have someone else within the project who maybe didn't touch that software side or that software guy touch, he's going to perform the design review or the independent review of my physical component? What are your thoughts there?

Karandeep Singh Badwal: My view on that is always get an expert in place. Quality starts at the beginning of product development. You don't want a mistake to carry through and then that mistake carries through and gets bigger and bigger, right to the point where you've got a final product and it doesn't work or there's a serious issue with it. So in that case, in the case of design reviews, I always recommend getting an independent expert in place. Unless of course you've got someone in the company's an absolute whiz and has 30 plus years experience in that device then by all means go for it. But I always recommend get somebody independent. Are you somebody outside your organization? Because design reviews are critical to make sure that your device is able to do what you say is going to do.

Etienne Nichols: Yeah, fair enough. That makes sense. I respect that. Okay, what else? Any other pitfalls that you typically see companies getting into?

Karandeep Singh Badwal: Very, very small detail, but ISO 13485, you may have seen the terms EN and BSEN around if you're familiar with those.

Etienne Nichols: Yeah.

Karandeep Singh Badwal: What people don't realize is that these are different versions of it. So EN is the version that's aligned with the European regulatory requirements. BSEN is the British standard because don't forget England, well sorry, Great Britain is no longer part of the EU. So the standards we follow in Great Britain are BSEN. So if you are a Great Britain based manufacturer, and I use the word Great Britain here because the UK has also Ireland in there, but don't forget, Ireland is part of the EU while Northern Ireland is part of Great Britain. So it's a very, very small minute detail. A lot of people don't realize that. So make sure you are following the standards applicable to the jurisdiction that you're in. ISO 13485 is international, EN is for Europe and BS for Great Britain. Those are the standards that you want to be following.

Etienne Nichols: Great. And so is it specifically the certification for those or are there differences within the standard?

Karandeep Singh Badwal: The standard differences is something known as Z annexes. It's a very, very small minute detail and it just aligns with the regulatory requirements in the region that you're working in. That's all it is. But you want to make sure that you are following the regulatory requirements because ISO 13485 does state that you must follow the regulatory requirements and the region of which you're operating in.

Etienne Nichols: Okay, that makes sense. We may need to get a chart or something about the different locations and things, or maybe you have one right there, but if not, definitely that would be useful. Well, very cool. Anything else? I love the minute details because there's money in the details. It's good.

Karandeep Singh Badwal: And again, if we go on the topic here, this is an interesting one. So of course you've got reporting to regulatory authorities, which for ISO 13485, now as many people know is obviously the EU. We have the medical device regulation. We came out in 26 of May, 2021. Within the UK we also have the UK medical device regulation, which adds to the confusion, but that is largely based on the previous medical device directive. So ensure in Great Britain we are following the old MDD, but we just called it the UK MDR. And then of course in Europe we are following the EU MDR. Now the key difference here is reporting deadlines. Now for serious public health threats, that's two days. For something that's sort of serious deterioration state of health, that's normally 10 days. And then for everything else within the EU is 15 days to report it. And the MHRA within Great Britain, it is 30 days to report it. A lot of people since the transition to the new MDR have not updated that final bit from 30 days to 15 days.

Etienne Nichols: In the UK MDR. Okay,

Karandeep Singh Badwal: So the UK MDR is the old MDD that recommends 30 days reporting where the new EU MDR recommends 15 days. Okay, small minute detail.

Etienne Nichols: Worst case scenario then, when you think the edge case, if you want to do the one that, and I'm going to ask this as, you tell me where I'm missing the mark here, but if I'm following the EU MDR and make that transition to EU MDR, am I still covered with everything that you would find in the either old MDD or UK MDR?

Karandeep Singh Badwal: The way I go about it is I have both in the procedures. I'll say if an incident happens in Great Britain, these are reporting deadlines and if an incident happens in the EU, these are our reporting deadlines. Now to further add to the confusion, the UK, sorry, Great Britain again is going to be coming with a new regulation at the end of June, 2023. Now theory dictates that it should follow the EU MDR because that's what makes sense. But at this moment in time, no one actually knows what it's going to be like. So we'll just have to wait and see.

Etienne Nichols: Yeah, okay. That makes sense. Well, I like that approach anyway, just having both in the procedure and indicating how you're going to handle those things. I mean we should be used to that by now anyway. Whether you're an FDA and the EU MDR, you're likely going to be doing something similar. I assume that's how you would handle that as well, if you're also reporting that.

Karandeep Singh Badwal: Yep, that's completely correct. I mean that's what you do within companies, you split US and the EU, now you would just add Break Britain into it basically.

Etienne Nichols: Yeah. Any other little details like that, that you see maybe people getting slipped up by?

Karandeep Singh Badwal: Another interesting detail, and I have actually been minored for this on audits. So this again goes to the C marking. So if you a C mark or a UKCA mark and you have a quality management system. So for example, sometimes you have a quality management system to ISO 13485, but you don't have a product. You may just be providing a service or you may be an OEM, but if you actually have a C marked or UKCA marked product, you need to have some sort of procedure in place for unannounced audits.

Etienne Nichols: Okay?

Karandeep Singh Badwal: You're going to have unannounced audits from time to time, and you need to have a procedure in place. So you need to deal with number one, verifying that the auditor is actually genuine. Let's look at social hacking. So this is a completely different aspect. If I'm wearing a uniform saying I'm from BSI and I knock on your door and I look official, you're probably going to open the door and say, " Hey, get down. We've got to an unannounced audit." I could be a complete fraud stand. You wouldn't know about it. So number one, you want a procedure in place where you check these people's IDs and you can pick up the phone and make sure there's genuine, because that's what it is in the term unannounced. They're not going to call you a week in advance and say, " Hey, we're going to have an unannounced audit for you, be ready." The whole purpose of unannounced audit is they just turn up on your doorstep effectively. You need to deal with that.

Etienne Nichols: You said you got a minor on this, was it not checking the person? Or how did that go?

Karandeep Singh Badwal: So we never had a procedure in place. So this was very early on in my career when I worked in quality management systems and I thought, " This is ridiculous." But then it really clicked in place for me, because let's just say the whole RA department is away at a conference or maybe not available. If somebody knocks on the door, and again, let's say somebody who maybe just works in your manufacturing facility or maybe somebody who's just a developer, how are they going to know how to deal with this? So again, it goes back to what we were talking about, having super clear procedures where they can just pick this up and say, " Ah, great. So an unannounced audit has turned up. Okay, I need to verify their identity. I'm going to get on the phone with a notified body. This is what I do. I'm going to sit them in this particular room and I'm going to give them access to these particular service with read only, and this is how I'm going to go about doing it." So that's really it. You need to know how to deal with the unannounced audit because you don't know what's going to turn up. You don't know who's going to answer the door. You can't just shut the door and say, " Hey guys, we're not letting you in," because straight away you will fail the audit. So again, number one, it's the compliance point, but number two is you need to make sure that people with the new company know that unannounced audits exist, that maybe they don't think it's a prank or a joke, which let's face it, if you're a new company, you may think that somebody's paying a prank on you. It's perfectly viable to think that. But also, you need to make sure that they're handled correctly, that they're seated in the correct area and they have all the information that they require. And that's basically it. So make sure that you're dealing with unannounced audits and also make sure that you're dealing with how you're going to deal with external audits. If an external audit's going to happen on ISO 13485, the process for that is going to be completely different to unannounced or internal audit. So again, what are you going to do? Invite them in? Are you going to seat them in a particular area? Who are the people to be contacted? That's basically it. How are you going to accommodate for an external audit?

Etienne Nichols: Great. I love that tip. It sounds like every time something happens early in your career that kind of rattles you or you think, " Oh, I wish I'd done that differently." It kind of sticks with you. So I love hearing those things because they are meaningful. What else? Any other pitfalls you've seen people get into or you gotten into yourself? I love the specific stories. They're just great.

Karandeep Singh Badwal: No, I mean I could probably bang off for days all the little details, but what I say with companies is they often start doing things like product development and things like that, and they look at the QMS. Guys, what you really need to do is look at the QMS at the start, especially with companies is, I often go into companies and they have a product and they have no design history file, they have no device master records. It's like, "Oh, we had no QMS in place." I'm like, " Well, that's your mistake guys. If you had a QMS in place..." And again, the earlier you get the QMS in place and the earlier you start using it, the earlier you can start tweaking it and make it better for your organization. Don't try and do a QMS in retrospect, because that's just setting yourself up for failure because you're going to have documents all over the place. If you have a QMS at the start, it's going to be clear where your documents are. You're going to have document controls in place, you're going to have backups in place. And that's the way around it. It just builds that quality culture in a company because a C mark or an FDA approval or a UKCA is on your product. A quality management system is the whole company. So it's not just regulatory guys, the HR guy, the person who works in admin, somebody could just be working the pulse department of your company. They all play a part in your quality management system. So it's something that your whole company needs to know top down from top management.

Etienne Nichols: That's great. I feel like that's a mic drop. That was a great point, Karandeep, thank you so much for being on the podcast. I'll put a link in the show notes so people know how to find you and get ahold of you and see what you're up to. And I know you're very active on LinkedIn and I always appreciate your videos. You have the heart of a teacher and I really appreciate that about you.

Karandeep Singh Badwal: Well, thank you very much for having the opportunity here and I hope the guest enjoyed it. And again, if anybody here is listening or yourself, if you've got questions, feel free to reach out.

Etienne Nichols: Great. All right. Thank you for listening. You've been listening to the Global Medical Device podcast. I hope you enjoyed this episode and we will see you next time. Hey everyone, thank you so much for listening. If you enjoyed this episode, reach out to Karandeep on LinkedIn and let him know. Also, I'd personally love to hear from you via email, etienne.nichols@greenlight.guru, or look me up on LinkedIn. You can learn all about what we do. If you head over to www.greenlight.guru, we're the only med tech lifecycle excellence platform. And on top of that, we built both a community and an academy where you can go to join the conversation or learn more about the things we discuss on the podcast. You can find those at www.community.greenlight.guru or www.academy.greenlight.guru. Next week we'll be speaking with Kyle Rose on the topic of EUA, the emergency use authorization and the impending transition away from EUA authorization. We just did an AMA, Ask Me Anything session with Kyle in the community. So head over to the community as well and check it out. Finally, if you enjoyed the show, please consider leaving us a review on iTunes. It helps other people find us. It also lets us know how we're doing. So love to hear any feedback. Again, email me directly if you're able to. Thanks again. You're the best.

About the Global Medical Device Podcast:

The Global Medical Device Podcast powered by Greenlight Guru is 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.

Like this episode? Subscribe today on iTunes or S