Design Assurance: The Unsung Heroes of R&D

What is design assurance, and what function does it serve in the overall product design process? It’s not a role that gets a lot of upfront credit or name recognition, but it’s an important part of the process and impacts product development more than you may think at first.

Orla Connaughton joins the podcast today to discuss design assurance with Etienne Nichols. Orla began as a mechanical engineer and has a Master’s degree in Project Management. She has 18 years of experience, mostly working in the medical device sector, and has worked at a Senior Management level for both multi-national and start-up organizations. She’s been running her own company, Aztek Medical, for over 8 years. And she has a lot to say about design assurance.

Listen to the episode to hear the conversation as they discuss what’s involved in design assurance and why it’s so important. Orla shares how her thoughts on the scope of the design assurance process are related to The Lion King and how design assurance “packs the parachute” for the overall product design process.

Listen now:

Like this episode? Subscribe today on iTunes or Spotify.

Some highlights of this episode include:

• Orla explains what’s involved in design assurance and why it’s required. Global regulations require that a product is developed in a specific way and that there’s evidence that the project is developed that way. A working prototype is a great thing to have, but it’s only a starting point.

• Design assurance personnel have to be able to touch all the different processes and regulations. Orla explains that design assurance involves understanding the basic quality system standards and regulations, to product-specific standards, clinical investigations, and more.

• There are no college programs that directly lead to a career as a design assurance professional. These positions want a technical background with a high level of understanding of many different types of products and roughly 5-10 years of relevant work experience in the area. The position also requires a level of creativity.

• Although there’s no degree program leading directly to quality assurance, it’s often done as a module of a regulatory-type qualification, so it can be taught to people who are interested in learning the concepts.

• Design assurance packs the parachute for the product design process by putting the pieces together in order to tell a cohesive story to the regulators that allow the device to get approved. People may not see design assurance up front, but they’re serving a vital function in the process.

• Design assurance is a valuable process and skillset in its own right. It’s part of the big picture.

Links:

Orla Connaughton

Aztek Medical

Etienne Nichols LinkedIn

etienne.nichols@greenlight.guru

Greenlight Guru Academy

MedTech Excellence Community

Greenlight Guru

Memorable quotes from Orla Connaughton:

“Having a working, functioning prototype is great, and of course, it’s required, and it’s a great starting point, but really that is what it is – it’s a starting point.”

“Once you have a good technical solution, at that point, you should implement your design controls and start creating your documents and start releasing your procedures through this control process.

“What I really think makes a good design assurance specialist is the mindset element.”

“I think quite often creativity is not a trait that’s recognized with quality type professions, but really it’s very valuable in these situations.”

“The design assurance person is the quality engineer of the R&D process.”

Transcript

Announcer: 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. Welcome back to the Global Medical Device podcast. My name is Etienne Nichols and I'm the host of today's episode. In today's episode, we spoke with Orla Connaughton on the topic of design assurance. Orla started out as a mechanical engineer. She holds a PMP certification from PMI and has a master's degree in project management. She has 18 years experience primarily working in the medical device sector and has worked at the senior management level for both multinational and startup organizations. She's also run her own company, Aztec Medical, for the last eight years. On top of all this, she's passionate about design assurance. This is a phrase I haven't heard too much in my neck of the woods, so if you're like me, don't worry. If you're familiar with the concept of design controls, then you'll know exactly what we're talking about. A few of the points we get to are things like what is design assurance? Who's qualified to perform design assurance? What are some key principles and aspects of this position? And how do you gain that experience to do it competently? We talk about a lot of other things. I'm hoping in the future that maybe we can do and ask me anything, an AMA session with Orla in the community. So if this is something you're interested in, then definitely shoot me an email and let me know. Without further ado, please enjoy this episode with Orla Connaughton on design assurance. Hey, everyone. Good to be back with you today. Today with me is Orla, you know what? I forgot to ask you how to pronounce your last name. Is it Connaughton?

Orla Connaughton: Connaughton.

Etienne Nichols: Connaughton, okay. Good to be with you, Orla. I focused on the Orla, I thought I could do that.

Orla Connaughton: Yeah.

Etienne Nichols: So good to see you. I hope things have been going well. How have you been?

Orla Connaughton: Yeah, I'm great. Everything's going well over here. Yeah, I'm really excited to be here today and thank you for having me on.

Etienne Nichols: Well, I'm excited to have a conversation. We were talking before we started recording, but design assurance and this topic, this seems like an undervalued topic in the broader industry. My background was as a mechanical engineer. When I went into product development, I was maybe not ready for the level of detail required when it came to design assurance. But maybe I'm getting ahead of myself. I wonder if you could maybe introduce some of this topic. Maybe tell us a little bit about what design assurance even is.

Orla Connaughton: Sure. Yeah, definitely. I think that your experience is very common, Etienne. What often happens I think is, in companies is that they particularly maybe in small to medium companies where they're maybe coming up with a new innovative product and all the focus is on the product. So can we get a concept that works? Is there a need for it? Will we have a market? And really focusing a lot, as you said, from an engineering perspective on the product itself, the device and its technology. And what happens is a lot of people get a working prototype and then they get very excited and they think, right, we'll be in the market in six months. And they think, well, if I have this working now, I'm just going to maybe do a bit of testing on it. Maybe I need to do some kind of an animal study or something. But really they expect a really short time to market because they believe they have their product functional and working. And really what the regulations globally require, I mean, we primarily tend to focus on the US and Europe, which is wise. Because really everybody else has a version of those or can even work from those approvals. But both of those regulatory processes require that the product has been developed in a very specific way through a design controlled process. And that there is evidence of design control process being worked through the whole product development process. So having a working functioning prototype is great, and of course is required, and it's a great starting point. But really that is what it is. It's a starting point. Because what has tended to happen is to that point, people have maybe just gotten samples in from vendors. There's no traceability maybe on the manufacturing of those samples, or they don't know if they've been manufactured in a controlled environment, what kind of conditions they've been exposed to. They've generally put them together themselves on the desk in the lab. There's no work construction, there's no training evidence of the engineer doing this. Maybe the equipment's not calibrated because it's still in that early phase. But for product designers, this is what they are about. And most of them don't even know or have some kind of side knowledge, if you like, that there is something out there that's quality system. Maybe that's a regulatory pathway I need to follow to get this product on the market. But what often is missing is the understanding of that pathway, and particularly the design controls pathway that documents the product development process. So that when you go and submit your data and you want a regulator to approve your device, that they have the comfort. That if it was developed, if your device has developed and tested and assessed risk assessed, for example, through this control design development process. That gives them the confidence to trust the data that they are reviewing. So they fundamentally can trust the data. They fundamentally can trust the process that the product has been developed through. Therefore, their focus now is particularly in the US, is really just on reviewing the data pack and can they accept it? Does it say what it's supposed to say? Does the device meet its intended uses? Is it going to perform? Is it going to be effective? So if you can demonstrate that you have brought that data to them through this controlled process, you're just in a much stronger position.

Etienne Nichols: Yeah, that makes sense. I like how you put that if you've gone through this appropriate process, they can trust the data. One of the things that I would be maybe curious about is as a regulatory professional, when you work with these different design engineers and so forth, when do you get involved and when do you recommend people start working on the design assurance process?

Orla Connaughton: Yeah, so I think once the device and once that the engineers, if you like, have brought it to a good working concept. At that point, you've got to start implementing your design controls. Because what I say to people is, at that point, if you continue to try and do things, I'm going to call it in an uncontrolled way. But I mean maybe acquiring components to assemble your device that are not, you don't have traceability on, or like I mentioned, your machines are not calibrated or whatever those types of things are. Really at that point, what you're doing is you're throwing good money away because, you think you're gathering data, but it's not going to be able to be submitted to the regulatory authority. So once you have a good working prototype and you think, I'm pretty confident this is close to my final design, it does not need to be the final design, but you have a good idea of where you're going. At that point, I really think the design controls need to start coming in because you have a very defined process. It's required by both regulations. So 21CF4A20 part 30 is design controls. And then in the ISO 13452016, it's section 7. 3 defines that you have got to develop your product through a product development process. So once you have a good technical solution, at that point you should implement your design controls and start creating your documents and start releasing your procedures through these control process. Because now everything you do has value and adds value. And you now can start submitting all of this data. So any lab book studies you're doing, just trying to record anything, any metrics, tensile strength, I mean it doesn't matter what it is, deployment forces. Once you are gathering that data through a controlled process, it's valuable and you can use it to support your case when you're seeking approval from a regulatory authority. So I really think at that point, what we call the concept phase almost, of the design control process. Is like I have a good working model, something that I believe is close enough to start really putting effort into. And that's the point really where I believe design assurance really should engage.

Etienne Nichols: And I'd almost like to get your advice on this. So when I think about that concept phase, you have kind of, know pretty much what direction you're going in, what your product's going to look like.

Orla Connaughton: Yeah.

Etienne Nichols: And that's typically what I would say too. Obviously that's when you need to at least start having some things hammered out. But the question I guess I have in my mind is those engineers, they probably have some of that design controls already in their head. I mean, if you think about user needs and design inputs, they've probably already, I mean really that's floating around in their head or else they wouldn't have gotten to this point anyway, at the concept phase. So I don't know if I turn this into a question necessarily, but what's one of the better ways to pull that information out of people's heads and put it on paper that you've seen? Do you have any advice or thoughts on that?

Orla Connaughton: Yeah, sure. So you're quite right. I mean, people haven't come up with a product from nothing. They've identified hopefully, they've identified a need. They have done, as you said, even that basic market research almost, even if it's not formal. As you said, the design control process has documents or terms such as product specification, user needs, documents, and these types of early stage documents that allow you to document exactly. Well, what are we going to consider? And what are the types of things that we want to deliver to the patient to the clinician, to whoever your user or patient population are? And how are we going to phrase those needs? Such that we can provide evidence that demonstrates to the regulator, for example, that we meet those needs. So if you take something even a catheter, that a lot of people are, I suppose quite familiar with, it has certain requirements. So for example, there's certain tensile strength that the bonds have got to withstand so that for example, when it endures the pressures of deploying it into the body and withdrawing it, that it doesn't fall apart. That it's going to be able to withstand those types of pressures. There's also user needs around, depending on your device, if it's a mobile device, you're going to need it lightweight, perhaps. Other types of devices will require things not to leak, for example. So there's user requirements and specifications like this. And sometimes, as we can talk about a little while, maybe there's specific design standards that dictate for a particular type of device what those requirements need to be. What those specifications are, but others, then when you're coming up with a device that's maybe a little more novel or it's going to be used in a different way. You've got to determine those user needs and specifications for yourself and define them. Because every user need, you've got to demonstrate that you have evidence to show that you can meet it.

Etienne Nichols: Yeah, and maybe we can just go straight into that. You mentioned some of those other standards are those, Sometimes when I look at the standards as far as what all is out there, it's just a sea of standards to a certain degree.

Orla Connaughton: Yeah.

Etienne Nichols: I'm sure there are some that you say, Hey, these are ones you need to look at every time. I'd love to get any thoughts or advice you have for companies when it comes to the standards and looking at those.

Orla Connaughton: Yeah, sure. Well, I'll tell you, I'm a big Disney fan. I grew up watching all the Disney movies and my kids, I educated them all very well. And sometimes I think about design assurance in the context almost of The Lion King. And I know this probably sounds a bit crazy to some.

Etienne Nichols: Oh no, this is great. I'm very familiar. I have a four year old.

Orla Connaughton: Yeah, there you go. So there's the scene in The Lion King, and it's Mufasa, who's obviously the dad and he's got his son's Simba there. And he's showing him everywhere the light touches is our kingdom, basically. And this is the scene from The Lion King. And sometimes I think that is design assurance. It's almost like, as you say, what are the specific standards? And it's like design assurance personnel have got to be able to touch them all. So from understanding things like the basic quality system standards and regulations. So how does the quality system work? What does the design control process require? What's that structured design control process that we have to go through? Then you get into things like if we look at the product specific standards, but well, let's take more of the, I guess what we call, the horizontal standards. So it would be things like risk management, ISO 14971 is the risk management standard for medical devices. And no matter what type of medical device you've got. You've got to be familiar with that standard so that you can assess the risks, understand where the risks are to the users, the patients, et cetera. How to mitigate those risks and basically generate a device that will be safe for the populations. Another kind of horizontal standard, if you like that is if you need to do clinical investigations. So you'll have ISO 14155, and again, that's like how do you do clinical investigations no matter what your device is? So there's some horizontal standards like that. And again, design assurance professionals need to understand these, know how to navigate them, and drive the creation of the documents quite often to comply with them.

Etienne Nichols: I'm going to ask a dumb question real fast if I could. So what do you mean by the horizontal? I'm not familiar with that.

Orla Connaughton: Sure, sorry. So horizontal is standards that apply no matter what your device type is. So they're general standards.

Etienne Nichols: Okay.

Orla Connaughton: So like I say, the quality system, the risk management, the clinical investigations. If you like, and then what we call kind of vertical standards are the very device specific. So if I'm developing a coronary catheter, I now have maybe like ISO 25539 I think is one of the device specific standards for maybe a coronary catheter. If you have a device that has chronicle fittings on your device, for example, one of the standards that will be applicable to use the ISO 20594. So these are very specific to your device and they're what are generally called the vertical standards. So horizontally kind of go across everything. And then vertical is like, well, I'm in this silo, I'm either in the currently space or I'm in the GI space, or I'm in the whatever. And it's the standards that are very specific to those. Yeah, that's one of the things like biocompatibility say standard would be another kind of horizontal or the sterilization standard. So what happens with design assurance is if you take all of the elements of the technical file, whether it's for a US submission, European submission, really they all are very common threads. Like there's biocompatibility, sterilization, it's a sterile device, there's the design verification of validation, which touch on these specific standards. There is labeling, there's all of these various risk management, various sections, and design assurance has to have a knowledge of them all and know how they all entwine. And to ensure that the story that you need to tell to the regulator at the end to get your device on the market. That the story links all of these elements together and that it's a consistent story. So that for example, we do some risk analysis and we identify maybe what our risks are, and then we determine what's our design verification testing out of that? What's our design validation testing out of that? So what sample size am I going to use? Well, you're going to be looking to your design assurance professional to help guide you with that. What tests do I need to do? You're going to look to your design assurance professional to say, Well, there's specific device standards for this type of device. Therefore, we must do those tests. But also have we other user requirements or user needs or specifications that we want to make a claim about our device, maybe because we want to be a differentiator in the market, we want people to buy ours over theirs. So maybe we have other specifications there, and you're going to be looked to your design insurance professional. How do I test those or what really how much testing, how much data do I need? Your technical engineers are going to develop your test methods. So it's not that technical element of it, but it's the link to the risk. And once we do our testing and discover that everything is fine or not so fine. How do we communicate these residual risks in our labeling? It's tying all of these elements together, telling a consistent story. And they need to have that kind of technical know how, but at the same time, they're still keeping an eye on the big picture.

Etienne Nichols: So I'm going to kind of describe what I've heard and you tell me where I'm missing the mark maybe.

Orla Connaughton: Sure.

Etienne Nichols: So it's almost as if they are something of, they can speak the engineering language, but they also can somewhat speak the language of the regulator. And they're kind of the begin with the end in mind guy. They know what is going to have to fit or hand over to the regulator, but they also understand from a technical side to a certain point to kind of mesh those together. I don't know if I'm.

Orla Connaughton: Yeah, yeah. You have it,

Etienne Nichols: One thing I might ask about that, with the design assurance professional, it's a very specific subset of skills.

Orla Connaughton: Sure.

Etienne Nichols: That they would need, whether it's making sure that, well, like you said, like biocompatibility having a general understanding of 10993 or 11607 for sterilization and all these different things. How does a person get to the point where, I mean obviously it's always going to be learning, but when they're a design professional, what leads them up to that point? Or what would you say is a good pathway of learning to get to that point? Do you have any recommendations there?

Orla Connaughton: Yeah, yes, certainly. Yeah, it's a good point, because you can't go to college to be a design assurance professional. It's not there. So quite often, and I mean even do a search for even job specs for design assurance people, and there's always quite a big similarity. So they all want a technical background and generally quite a high level. Because you do need to understand there's different products coming at you all the time and you need to be able to, as you say, you don't be, you're not a technical expert on any of them, but you need to have an understanding of the nuances if you like, with the devices. So they generally always want a technical background and then with roughly 5, 8, 10 years experience of working in the area. So that generally what'll happen is people will have either come through. As you said, something like an engineering or a science qualification and maybe a product development type environment and will also have worked maybe in a regulated environment. Ideally medical devices because they understand the whole quality system elements and stuff like that, but some kind of a regulated environment. So that's quite often the kind of the technical know requirements if you like, on a job spec. What I really think makes a really good design assurance specialist, if you like, is the mindset element of the job, if you like.

Etienne Nichols: Yeah, let's get into that.

Orla Connaughton: I think it's really important. I think you do need to understand the technical aspects like we said. So there's a design control process. You need to work in a quality system, regulated environment, you need to have a good technical understanding. But more than that is you have to be creative. You have to keep an open mind. You have to understand what the regulation is looking for, and it's not just reading the black and white words. It's trying to understand the nuance and behind it, understand the context in which the device that you're engaged in on this project. So what are the important facets of that device that can meet this regulatory requirement? So it's like that interpretation element of it with respect to the device that you're looking at. And it's constantly kind of going, Okay, well we have this data, how can I present that to meet the regulatory requirement? So how can I present it to show that this device is safe and will perform and be effective in that? So the team are going to come up against failures. For example, you encounter testing failure. It's like, okay, what does it mean? How can we solve it? How can we solve it in a way that we can still present it as a learning or as a positive, if you like, within our whole this story the way have to tell to the regulator? Or do we need to just take a step back and go back maybe and do design freeze again and then maybe move forward again such that we have a clean set of data to submit to the regulator. So it's keeping all of the balls in the air and constantly knowing, keeping an eye on the end game the whole time. So how am I going to tell the story that the device is safe, it will perform, like I say, it'll be effective and we've followed it through the appropriate design control channels. Thinking of different ways to do that depending on what the device is. And just being very open I think, to new ideas. And I think quite often creativity is not maybe a trait that's kind of recognized with quality type professionals sometimes. But really it's very valuable in these situations because it's like there's no two projects are going to be the same. You're going to encounter different issues and it's about understanding all of the balls that need to be kept in the air, I think.

Etienne Nichols: Yeah, no, that's a great point. So while you were talking, maybe kind of think back to some of my past. I try to think in zooming out or nitty gritty detail as a manufacturer working with product development and quality, sometimes you'd have a print for a single component and they would inspect what we called the CTQs at the time, the critical to quality aspects. That would be inspected every time and bring that up because the product development engineer and the quality engineer, they were the ones really who determined what those CTQs were for the most part. Maybe the manufacturing had some input based on what could be inspected and so forth, but you'd have those CTQs for that component. If you look at the design assurance, keeping that concept in mind, they're almost looking at the entire component, the entire assembly and determining what is critical to making this a working safe and effective part. And they're looking at every different aspect, whether it's biocompatibility, like you said, labeling the risk and the sides, the ways this could fail. They're almost like helping to determine the CTQS of the entire assembly to a certain degree. Would you agree or what are your thoughts there?

Orla Connaughton: I do often say to people, because sometimes you do come up against people who don't know what design assurance is. And they think, oh, I have my product development engineers and maybe they have manufacturing engineers. And people can often understand what a quality engineer is with respect to manufacturing. So as you say, you know are on the manufacturing line or the production line, and there's a quality engineer there. And people can understand that their job is about creating the quality of the output or ensuring the quality of the output. So sometimes there's inspection in there, sometimes it's dealing with CAPAs and non-conformances and all those fun things that they encounter. But people can, but people can understand what that role is. And what I try and say to people is, well, design assurance is that role for the product development process. So you have a product development team or engineer who's developing that process and they need to be supported in that process by the design assurance engineer. The same way a manufacturing engineer who's now trying to determine a process for manufacturing these componentry or whatever, that needs to be supported by a quality engineer. Who's working with them in tandem as part of the same team to deliver the device. So I fully think you have the analogy perfect there because it's one I often use to explain to people to kind of say the design assurance person is your quality engineer of the R&D process.

Etienne Nichols: Yeah, I'd never heard anyone verbalize that, but I think you said it Great. That's really good point. I love that. So you mentioned something about when we were talking about the process leading up to the education. An engineer, typically it's on the job, you have a certain amount of technical. You get regulatory and you become this, actually, it almost sounds like with the balls in the air, they're going to need some project management skills too, and creativity. So it's a special person for sure.

Orla Connaughton: Yeah, it is.

Etienne Nichols: If you're really good at it. So I want to ask your thought then, and maybe this is purely theoretical. You mentioned we don't really have an academic pathway right now to a degree in design insurance engineering, but maybe I wonder if it could be possible to have one. I mean sometimes we have professors listening to this. I wonder if that's something that could be possible. Do you think it's even teachable or does it have to be on the job? What are your thoughts?

Orla Connaughton: No, it's definitely teachable. And I mean it's done quite often as a module of a regulatory type qualification. So quite often they'll do a module in design control so that they know it exists. We're very lucky here, actually, I'm based in Galway in the west of Ireland, and we have a bio innovate program running here with the local universities that started in Stanford. And basically some of the professors here went over and have taken the concept here and it's hugely successful. So there's a huge amount of small to medium enterprises here based in the west of Ireland that are looking at where there is clinical needs and trying to generate solutions for them. And they go through a great kind of two year academic program, if you like, combined with getting clinical experience and various opportunity experiences like that. But they are taught a design control module and other kind of masters and regulatory affairs that are being taught again locally and here in other institutions if you also have a design control module. So people do come out with the understanding that there's a thing over there called that. So you can educate to a point what the processes are. But I really think as you say, a good design assurance professional has the confidence behind them also of experience because the processes are top level defined. In other words, you must have regulated process, there must be these kind of top level elements to it. But really you have a lot of flexibility within the process also. So how can you be more efficient understanding the device that you have with the lower risk device versus a higher risk device? Understanding the level at which, for example, something like risk management needs to be done. So you could go to hundreds and thousands of lines and they do, and I've seen them and sometimes for class three implantable really complex device, you have got to get to that level of determining the risks. But some people make the mistake of going there and then finding it so hard to come back from it. And it may be a much simpler device that really you don't need to analyze it at the same level at all. So that's the kind of experience that a good design assurance can bring. And can look at for this type of device, we're going far enough here. For the next type of device, we need to go further. And also understanding the benefits of taking say something like risk management to a certain level because then you can start using the risks that you identify, for example, using them in your post market environment, if you like. So a complaint comes in, you receive a complaint for something, and one of the questions is, did you consider this? Did you realize as manufacturer that this could happen to your device? And in Europe at the moment with the vigilance requirements, it's like if you didn't realize that this is something that could happen and by didn't realize, I mean didn't document. Because if it's not documented, it didn't happen as we all know. So if you have it documented, for example, in your risk analysis, then maybe it's not a reportable complaint to the regulators. So an MDR reportable type event. But if you don't have it documented, in other words, an author could come in and say, No, you never realize that could happen, because I can't find it in your risk management file. Then maybe you end up reporting these types of events to regulators where there may be no need highlighting a risk that are really not risks with your device, it's just that you hadn't documented your risk management at the right level. Regulators are getting a bit concerned about you, why aren't we seeing complaints with that company, not with the other company who have a similar device, for example. So it's understanding all of those nuances. That's what a really strong design assurance professional can just bring that level of nuance, understanding and just professionalism to a product development process.

Etienne Nichols: Yeah, I couldn't agree more, and this is probably going to step on someone's toes at some point. But when we were hiring new engineers, that was a consideration just as an engineer for design. Just because if you hire a new grad, they have such a solid foundation and especially depending on where they went to school and so forth. But at the same time you have the thought, I'm going to have to train this person to be a good engineer.

Orla Connaughton: Yeah.

Etienne Nichols: Because you're right, without, that's something to build on the real world experience. It's hard to, you just can't beat it.

Orla Connaughton: Yeah.

Etienne Nichols: So that's a good point. I want to, you mentioned the mindset. Do you have any specific tidbits of wisdom or thoughts, stories, anything about that applying that mindset or developing that mindset of a design assurance professional?

Orla Connaughton: Well, I guess there's a lot of, kind of examples and things that we could come up with. But there's one particular story that I like and some listeners will be familiar with this story because it's used in other contexts I should say also. But I like to think of it for design assurance. So if you have a minute, I'll share.

Etienne Nichols: Absolutely. Let's hear it.

Orla Connaughton: So there was a Captain Charles Plum, who was a graduate from the US Naval Academy, and his plane was shot down after about 74, 75 successful combat missions over North Vietnam. So he was parachuted to safety, but he was captured and he spent over six years in jail while he was being captured. So afterwards he came home and Charles and his wife were out to dinner and they were in a restaurant and a man rose from a nearby table, came over to him and said," Your Plum, you flew jet fighters in Vietnam from the aircraft carrier and you were shot down." And Charlie was quite surprised and he thought," How do you know this?" So the man replied," Well, I packed your parachute." And Charlie Plum looked up and surprised and he gave the man a thumbs up and said," Well, I guess it worked." But that night he would lay away thinking about this man because he thought about the hours that he was a sailor, actually this individual, and he thought about the many hours that he had spent bending over a long wooden table in the bottom of the ship carefully folding all the silks and weaving the shrouds. To basically make the parachute for somebody that he didn't know and would never meet, probably. So I often think, so this kind of story is told is often to say, think about who packs the parachute, or the importance of packing that parachute. So in this context, I sometimes think that design assurance packs the parachute for the product development process. So it's kind of like that understated thing that people don't always realize almost is happening, that they are quietly kind of just getting the story together. Moving all the pieces of the jigsaw around to kind of create this cohesive story, if you like, that we can tell to the regulators to get the device approved. But it's packing the parachute for that product development process. So I think people end up seeing the product and there's rightly great admiration for the technical minds that came up with it and developed it and all that. But you know what? The design assurance professional is there in the background and without them, you're not going to get that product to market as quickly as efficiently because they can't tell the story. And like I say, even afterwards, when your product is in the marketplace, they can also be providing you that benefits because when they're doing a good job. They're also protecting you for the post market or for what's coming down the road in the commercialization phase. So it's just a little story. I think it depends how you think about it, but that's the way I think about it.

Etienne Nichols: I think that's a powerful story. I think that is so good. People are probably going to be yelling at their podcast player, whatever it is that's saying, how do you not know if it's a common story? But I had not heard of that. That is so good. I love that. Thank you for sharing. Yeah, the design assurance person is the one who packs the parachute. I'll have to remember that. That's great. I feel like that's almost like a mic drop moment. Did you have any other recommendations or advice for companies as they're building through this? Any other thoughts?

Orla Connaughton: I guess what I really wanted, I suppose out of today when we selected the topic of design assurance was just for people to understand that it is a process in its own. It is a skill set in its own and that it's very valuable to an organization to try and get a product out to the market. But also they have the big picture in mind, they have the prem virtualization of post commercialization and then also the patient groups, the patient, the clinician, all of their users in mind if you like. So I think they can future proof if you like, as well as just look after the process. And another colleague said to me recently about design assurance, and she said," It's like insurance." She said," You don't even realize you need it or you don't even think about it until something comes up." And maybe I'll give you a few little facts and figures if you don't mind it, Jen and I won't please spend too much on it. But no, in Europe people will be aware we have this small little thing called the medical device regulation that is causing havoc at the moment. But there's some data starting to come out now obviously because certain companies are, there's tech files going through and being submitted and we're starting to get some data on how long it's taking to get products through the review cycle and a number of questions and things like that. And one survey that was performed here with some companies across different notified bodies and different class of devices is that on average there is like 170 questions coming back for each technical file that's been submitted. And some are getting three and 400, and these are files that were already products that were on the market under the MDR. Yeah, and most of the time there's not one of those has required new testing. So this is all documentation clarification, making your documents stronger to align to the requirements of the MDR. And I mean that's exactly what we're talking about here is that's what the design assurance professional can really build into it to a product development process. But all of those questions that are coming back approximately 65 to 70% are in areas that the design assurance professional touches. So I'm talking about things like in risk management, for example, the links to risk management and labeling. So if you identify risks, are you communicating those risks, the links back to the clinical evaluation report, if there's risks being identified with other types of devices, are you considering in them in your risk management file? Things like that. And I'm not saying they're design assurance specific questions if you like, but they're touch points that the DA professional will engage with. So it's a big learning. I think for a lot of companies who haven't maybe had the best design development processes or documentation of them, they're really struggling because remediation is expensive and it takes time. And like I say, it's kind of scary in some ways that there's no additional testing being required. Which means that thankfully companies are generally doing the right thing and have the right data packs together to demonstrate safety and performs none of their device, but they're not documenting it in the way that the regulators need to see it. And I guess to me, that's a really important message to get out and to just basically understand how your DA professional can engage with that.

Etienne Nichols: And if you layer on another piece of data in that, I don't know what the specific number is, and maybe you do, but specific percentage of tech files that have even been submitted for MDR. It seems like it's pretty low compared to all the products that would need to do that.

Orla Connaughton: I can't remember the exact numbers actually off the top of my head, but there's a very small percentage gone through that needs to go through if you like. And over the next two years, I think 2024 has by far the greatest percentage of CE certificates under the MDR due to expire. But what's happening is, and the nullified bodies are telling people, get your submissions in now. Because one of the piece of information I do have to hand on that small kind of survey that was done on 16 technical files here is that the average review time to clearance. For example, for the class threes is over 500 days here. And for the class twos, it's coming in roughly in the three fifties, three eighties, some are going over 400. So that's over a year. That's a year and a half even for your class two devices, that's almost year and nine months almost for your class threes. So if you have a C certificate that's expiring in 2024, you almost need to be getting your submissions in right now.

Etienne Nichols: Yeah, so one of the reasons that I brought that up is if this low number or what's being submitted right now, and it takes so much response, whether it's 150 to 300, 400 questions answering. It sounds like we're going to have a spike in demand for this design assurance professional, or at least their skillset. And if we don't develop this skillset with our design assurance professionals, that answering those questions is going to fall to the people who are in regulations. The regulators or the regulatory affairs or your design control engineers, which really would likely be better suited doing what they really do best. And so this design assurance, it's almost seems like it's going to be a gap. I don't know. Would you agree?

Orla Connaughton: Oh yeah, I think it already is. And the kind of funny because the companies who value it can't get enough of these people. And then the companies that I've never heard of them are not looking for them, but there's already a shortage. And kind of back to your good question earlier about is there an education pathway? I think it's going to develop, it's going to be like regulatory is relatively new in the industry and there's now courses out there. You can do masters in regulatory affairs, the wraps, qualifications. So there's courses being developed that didn't exist 30 years ago because really regulatory is kind of in its infancy in terms of kind of industry. But I think the same will happen with Design Assurance at the moment. It's a module or two of certain programs so that they know it exists. But I think, again, no more than the PMP qualification that we talked about, the project managing professional qualification know that we both are proud to have.

Etienne Nichols: It's Difficult to get.

Orla Connaughton: So it's nice to have. But I can see something being developed for design assurance as well. Because I think it is kind of, it's out there now, people know about it, but as you say, specific skill set or a program hasn't been developed around it.

Etienne Nichols: And I feel like at this point, I should shamelessly plug a friend of mine, Aaron Lucas is he's building out the Academy for Green Light Guru.

Orla Connaughton: Oh sure.

Etienne Nichols: I don't know if you're familiar with the Green Light GU Academy. Definitely recommend people look out over there, talks through some of the way you can do certain design controls items and so forth. So yeah, a lot of free content there that's valuable. Well, cool. Thank you so much, Orla. I thought this was a very valuable conversation. I learned some things, which I always am excited to. That's one of the reasons I do these podcasts, so I enjoyed our conversation. Where can people go to find you to learn more about what you're doing and what you're up to?

Orla Connaughton: We have a company here, it's called Aztec Medical, so www.aztecmedical.com, Aztec as in Aztecs and the Incas.

Etienne Nichols: So what's the story, if you don't mind me asking?

Orla Connaughton: I don't even have a good story.

Etienne Nichols: I'm sorry.

Orla Connaughton: When I was in school, I was about 13 or 14 and we were learning history and there was a student teacher in actually, and I just that sometimes you just like a teacher and then you like a subject. But anyway, I like history.

Etienne Nichols: Oh, yeah.

Orla Connaughton: She was teaching us about kind of, I guess that was like the, what even was that? I don't know what kind of era that is. But anyway, I just love the sound of the words, the Aztecs and the Incas and the Aztecs and the exhaust seems to be this. So when I was coming up with a name for Aztec Medical, I was like, Oh, I just like the Aztecs. So I better actually maybe think about that.

Etienne Nichols: I like that.

Orla Connaughton: But yeah, that's where it came from. So anyway, we're www.aztecmedical.com and we kind of specialize in this area. So we are regulatory design assurance and clinical affairs and quality system management, if you like. So we implement quality systems from scratch for companies as well, or help them out with their quality systems. So we kind of work in this area because like I was saying to you earlier, there's a lot of small to medium enterprises who know the technical side of it. Have the product development engineers have the ideas, but they don't know how to translate that idea to a commercial reality or to regulatory approval. And we, I guess provide those support services in these areas of, like I say, quality systems, design assurance, regulatory affairs, and clinical affairs. So that's who we are.

Etienne Nichols: Awesome. Well, thank you so much, Orla. And those of you listening, you've been listening to the Global Medical Device podcast. If you're interested in how you can find a software that takes you from beginning to end traceability, check out www.greenlight.guru. We have the only med tech lifecycle excellence platform on the market, and definitely check that out there, the ones who make this podcast possible. And thank you so much for listening. We'll see you all next time. Thank you so much for listening. Just a few of the points I took away from this conversation were, number one, the design assurance person is the quality engineer of the R& D process. And two, there may not be a degree in design assurance yet, but this is a teachable subject, especially for the technically minded engineers who can enjoy documentation and technical writing. Granted, that's a special person, but I know they're out there. Third, the design assurance person is the one who packs the parachute. If you were listening, you heard a powerful story that Orla shared. Those design assurance people are protecting you, the medical device companies from problems in post- market. If you enjoyed today's episode, please reach out to Orla on LinkedIn and let her know. Also, I'd personally love to hear from you via email me, 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 MedTech lifecycle excellence platform. And on top of that, we've built both a community and an academy where you can go to join the conversation or learn more about the things we discuss on this podcast. You can find those at community @ greenlight. guru or academy @ greenlight. guru. Next week we'll be speaking with Karen D Badal on common QMS mistakes, software medical device companies make. Should be good. So definitely stay tuned for that. Finally, if you enjoyed today's show, please consider leaving us a review on iTunes. It helps others find us. It also lets us know how we're doing and helps us figure out how to improve. Thanks again. You guys are great. Take care.

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 Sp