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.

Hey, everyone.

Welcome back to the.

Hey everyone.

Welcome back to the Global Medical Device Podcast.

My name is Etien Nichols.

I'm the host for today's episode.

And today I want to talk about kind of a relationship that is not talked about very often, the project management and quality manager or quality professional relationship and the, the, the benefits of those two, particularly if you are a quality person and you want to build out your qms and you want your QMS to be adopted by company and actually to be effective in your company.

How do you do that?

Who do you get on board to make that happen?

And so with me today to talk about this topic is Beth Waring.

She's a medtech quality expert with over 10 years of experience in medical devices and pharmaceuticals.

She specializes in building and improving quality management systems that comply with FDA, ISO and European regulations, including ISO1345, IEC6304 and 21 CFR 820.

As a medical device consultant at Greenlight Guru, she supports companies through product development, design controls, kappa audits, postmarket surveillance and EQMS implementation, and probably a lot more of, maybe even, I don't know, certain therapeutic depressions, things, you know, as you're going into the medical device industry.

But her background includes leadership roles at sbd, Swiss Precision Diagnostics and mologic, if I'm saying that right, where she led quality efforts across clinical trials, manufacturing regulatory submissions.

She has a lot of deep regulatory knowledge and I'm excited to hear some of the things that she has to, to share with us today.

How are you doing today, Beth?

I'm very well, thank you.

How are you doing?

I'm doing, doing well.

I'm excited for this conversation.

Ever since we talked when you, I think one of our first conversations ever where you talked about how when you kind of inherited a quality management system that there was a struggle for people to, to buy into and, and how you overcame some of those issues.

I'm, I, I'm excited to hear that because that's kind of every company struggle.

Would you agree?

I think engagement with the quality management system, whether it's inherited or new or however you put it, is real, a real struggle for a lot of people.

Engagement is key and it's really important to sort of build a good quality culture.

And quality culture is a very buzzwordy thing to say, but it really is important and comes from the top all the way down to people who do manufacturing.

So really important to get a good grasp of it.

Yeah, I think that's a really good point.

It is something of a buzzword.

It can be, but it's also a buzzword.

The FDA has used, you know, a culture of quality.

And I think that's even in the preamble for 21, the QMSR, 21 CFR predate 20 harmonization.

So that's, it's, it's important apparently to the regulators as well.

So it's really interesting.

And I, I don't know if you have any thoughts on why there is friction so that maybe we can get, maybe let's do a quick kappa on.

This problem, get to our root cause.

I think maybe, maybe take more time than you and I have today, but we can make a good go of it.

I actually think one of the main problems is the phrasing that you use for it.

Just naming it quality and then having departments called quality, I feel like, makes it seem like quality have some sort of ownership of it.

And that's where we say things like quality is everybody's responsibility.

But then again, you have to have the flip side of that.

Whereas quality is then everybody's responsibility to implement in the first place.

Which is why one of the things that I find is there's a lot of friction is that you'll have quality departments where it's very almost authoritative, dictatorial, where you'll say, this is how we do it.

And I feel like people, generally speaking, don't like being told what to do.

And so sort of human nature to kind of rail against that.

Whereas if you bring people along for the ride and you say, look, we together are going to build a quality management system.

We want your input.

There are things that we're going to have to do, but we're going to bring you along for it.

Everybody's voice is just as important as everybody else's.

And if we can give you the quality management system that you want as a scientist, as a project manager, as a clinical specialist, then we're going to get much more engagement because it'll be a system that everybody wants to use.

Yeah, I think that's a good point.

And it is a. I can also see an inherent problem.

If you just say quality is everybody's job.

Well, there's going to be a little bit of resistance in that.

Well, why did we hire someone to do it?

You know, what do they do if it's everybody's job.

You know, I could see a little bit of irritation almost there.

So that's a really good point.

Our language really kind of like that phrase, we shape our tools than our tools shape us.

I think it's similar with the words that we use.

Yeah.

And I think keeping that in mind, where quality is a very specific function, where quality's main role is to make sure that the company complies to the regulations and that the processes that we have in place are compliant.

So it's not that quality don't have a role.

I think it's where you have that you want a quality culture because you want everybody to be compliant to quality.

You want everybody to be following the processes.

But it's also that element of it's a function and it's a mindset.

And that's where I think the disconnect is where you have.

I used to call it big Q quality, which would be the quality department, and small Q quality, which is the quality mindset.

And when we say we want to implement a quality culture, it's that small Q quality where everybody does the same thing.

And I can't remember who the quote is for, but it was like, quality is doing the right thing when nobody's watching.

Yeah.

Well, you can get away with it because especially when we work in medical devices and pharmaceuticals, that is the difference between potentially someone's, you know, life and death in certain cases if you try and hide things.

And that's why quality culture is really important.

But there can be a disconnect there with some of the language of what big Q quality is and what small Q quality is.

Yeah.

And so there's different departments, I guess, or different roles that have to interact with quality in different ways.

And the one that I'm curious about just because.

So project managers.

I was a project manager at one point, and there's.

They can be seen as anti quality at times because they're trying to maintain deadlines or maintain whatever it is, relationships with vendors, et cetera, but they're not anti quality.

I always felt like you needed to be friends with the quality people in order to get those things through.

I mean, that.

That's.

They're really anti obstruction and.

But I wonder if you have any insight into that relationship or thoughts from.

From your side?

I find the best project manager and quality relationships are one with open communication and trust on both sides.

And that comes, I think, a lot from the quality side on it by being willing to listen and being willing to be flexible to the amount that you can be.

So for example, if you were to have a very rigid structure for your quality management system, which said this is a very specific way of doing it.

So for example, if you wanted, you have a design control and the process specifically says you need for this phase six procedures, but then the product that you're making may not align with that.

You could be requiring somebody be writing documentation because the procedure is so rigid.

Whereas that's why a lot of medical device companies will have something like a deviation process.

And I was always very open when I was a quality manager to all right, what's the risk of doing this?

What's the justification for doing this?

Could there ever be a risk to patient safety down the line in which this has happened and is it still compliant?

Because a lot of people will over engineer their processes as well through time and through having audits and internal findings where they'll just tack things onto procedures without necessarily really thinking about whether or not this is going to fix your root cause or fix the issue.

And it's just easier to slap a line in a procedure which may have detrimental effects down the line and then do you really need it?

So having a process where you can be as flexible and the best way of doing that is building flexibility into the process itself from the beginning.

So having some non negotiable requirements for each design phase, for example, and then depending on what the product is having built in contingency for, you could use this or that or different things.

So I think it's inherent on quality to make sure that we're not being dictatorial and we're being collaborators rather than enforcers.

We don't want this quality as a police force mentality, which is used to be very prevalent in the industry.

Unfortunately, I think it's changing.

Yeah, I do too.

So I had a mentor, his name was Eric, who told me that early on he said quality can be a partner or they can be police or they can be a partner.

We want to make sure they're a partner.

And I was leading a drug delivery combination product at the time and you know, we, you spoke to this about how the, the SOPs, if there's six and maybe you don't need all the different things for the product that you're designing.

That was actually what got me into reading regulations.

I looked at our SOP and I'm like, man, why do we have to do all this?

They said it's in the regulation.

I had somebody tell me that.

I'm like, well, I'm going to Go read the regulation.

And I read all 21 CFR part 820.

I printed off ISO 1345, have it, have had it sitting on my desk ever since for, so that I can always go there.

And I thought, no, it's not in the regulation.

Now that being said, the regulations are intentionally vague.

And so you as an industry, there may be reasons to make your SOP slightly more strict and so on, but you need reasons for that justification.

And if so, I, I love the way you kind of describe them as a quality, as kind of an educator.

And project managers need to also be willing to be educated.

I think that's important as well, that receptive mindset to recognize these people have, these people that you are working with have a very specific skill set and you need to take advantage of that and not just push up against it, if that makes sense.

Yeah.

And I think if you look at a company as a product, think of quality as being a risk management mitigation where you don't want to have a risk management mitigation there, which stops you being able to function entirely.

But if you're walking on a very thin, you know, like a, walking a plank or something, it would be good to have guardrails there to stop you from falling off.

Do you need them?

No.

But you'll be a lot shakier.

You're not going to feel as secure.

So if you have the guardrails there, and that's really what quality is, it stops you from falling to either side.

But you also need flexibility to move.

If those guardrails are too tight, you're not going anywhere either.

I've got to throw one thing in there about risk management because I could just hear someone in the audience saying, well, that's a product development activity, which is not necessarily fairly true, should be cross departmental.

But when you say risk development in that context, I hear company wide risk management, it oftentimes in this industry we hear risk management think ISO 14971, where you're thinking about the harms to the patient through the product.

But there are additional harms that could come about in that maybe you're going to have a recall just because you have a regulatory issue, maybe you got your labeling wrong, you're misbranded, et cetera.

You have to go to court and be subpoenaed because you're selling off label or all these different things, things that may not necessarily.

You can make an argument, I suppose, that it could cause some patient harm, but a lot of those do not.

But you're still, that's a company risk, that product.

You know, in product development you may not be thinking about because you're so focused on the product.

I think that's really good where we talk about collaborators and I would never advocate for ever having a risk project with a single person.

So I would never want a risk project regardless of whether it's a company wide one, where you're talking about overall risk strategy or a very specific one for even a part of a product, you want cross collaboration.

And we would have a team, not necessarily from every department, but we would have scientists, we would have a specific risk manager as a mediator.

We would have customer feedback because they have really unique insights into the prevalence of harm and complaints that they hear and things like that.

And they have insight into what it is that our customers are saying back to us from previous products.

So having them on board to be able to see.

Well, I know you're talking about the highest level risk, but this is what we're actually seeing and being able to bring that in and be able to influence risk scores.

Having regulatory in there as well, if you don't have a cross QA and RA department because they can catch things like what would happen if a regulatory submission fails or what would happen if we have a recall and what could preempt that.

Because as much as you want the device specifically to be safe, people need to be have access to it and people also need to be able to get the information that they need.

And that's really where this sort of cross departmental function comes in.

So yeah, I think a really good point about, you know, no man is an island and you don't want your project leaders and scientists alone to be doing risk management.

Obviously they have a lot of technical knowledge and that cannot also be shoved to one side.

But it's really important to get lots of different perspectives on risk.

Let's talk about the tools specifically.

That's one of the things that I can see.

Well, okay, confession time.

I guess when we tried to implement a big quality management system tool, I was one of the ones who knew all the ways around it because it took way too long.

And so I recognize that wouldn't do that now.

There's a company issue there, you know that.

But, but I was not the only one either.

And it was a, it was an implementation problem and an adoption problem.

And I'm curious what you think about how to overcome that.

It, it, it almost doesn't matter what tool you're talking about if it's different, if it changes my workflow and it almost, you know, you could almost extrapolate this out, out to the product itself in a healthcare setting.

It's interesting that product development people are oftentimes the biggest offenders in a medical device company, yet they are also working towards the same thing so that their product is adopted in a workflow in a healthcare system.

But anyway, that's a different topic.

How did you, or did were you able to overcome some of those resistance to changes?

I think first of all, if you find that somebody is getting around the system in whatever way that is trying to be as non judgmental as possible, whilst also holding people to account is really important because obviously people agree to work in a certain environment.

So when you work for a regulated company, you agree to follow certain rules, which is following the procedures.

But I would also ask the question of why is it that they felt they needed to go round the current procedures, Are they too stringent, are they not meeting their needs?

Because whilst quality managed the quality management system, it is genuinely owned by everybody.

So I would try and listen to these people and I would also look at the risk of what they've done.

So if they've managed to sort of like not do everything in a process but they've gotten to the same end goal, is there something that we can learn from that?

Because there must be a reason that they didn't follow the process and I doubt it's because they just really want to rail against quality and they don't want to do as they're told.

It's more a case of I found a more efficient way and maybe they're not feeling like they would be heard if they came to quality because maybe they've in the past come to quality and they've said, I've got a new way of doing something, can we try it?

And quality have said we don't do that.

That's not how it's done here.

So again, giving people the space to breathe, giving people the ability to.

And it's one of greenlight guru's sort of buzz phrases of taking risks safely.

So if it's safe, if it's not going to have a detrimental effect, why not try it out?

If it's still compliant, maybe we can try and implement it and it could come up with a solution that is beneficial for every project manager going forward.

So if you're trying to sort of get around a system but at the same time, if you're doing things and it's not compliant, then we're raising the nc, we're raising the capa.

We're doing this but it's a case of being again going back to being collaborative.

We're not, we're not nursery.

Nursery attendants to kind of keep kids in line.

We're adult professionals who should be treating each other with respect and hearing different perspectives.

So yeah, and thank you for your non judgmental response.

That was a good one.

It's cathartic.

So.

And I also want to just do a quick caveat that nothing I did was truly against the company, but it was rules.

But there, there was like an understood we're trying to move into this other direction.

And I'm like, well I'm going to stay over here moving fast as long as I can.

But anyway, hold on the topic.

What do you think?

What do you think are some of the most the biggest objections or are there certain areas that a quality management system is not you not taken advantage of, not followed properly, Whether it's through misunderstanding or I don't want to use the word rebellion, but you just resistance in whatever way, even, even if there is understanding, if that makes sense.

I think the biggest benefit to a company would be to get quality more involved in a proof of concept phase.

Because I've always said that good quality design development starts with really good quality research and development.

And you have instances where you'll have sort of R and D people who are looking for proof of concept, seeing if things work and then they've not documented things properly.

So when it comes to wanting to move into an area like feasibility, things aren't documented properly.

You don't have your lab log books put in correctly, you've not had anything categorized properly.

So you don't actually have sort of the scientific validity that you would need to move into a feasibility phase locked down.

And it's not that it's impossible to move to that, but having something concrete to fall back on.

And this kind of also goes back into areas of you can prove that you were working on it first.

If you don't have those things documented, you don't have those things written down properly and properly categorized and controlled.

And I'm not saying it needs to be to the same extent that you do when you're in formal design developments.

But having a limited process in place for things like proof of concept, where you can just have a streamlined version of what the QMS would be doing later on in development, I think would be really helpful for companies in order to be able to use that initial proof of concept things going forward that.

Makes sense are there Are there certain phrases or certain terminology that you changed that you use, and I'm not saying that very well, but language that you change when you go from department to department?

As a quality professional, are there any phrases that you think are particularly pertinent to one department over another that really gets their attention and helps them get on board with what you're trying to.

Accomplish, department to department?

It really depends on the structure of those departments.

So if you want to speak to the other side of quality, regulatory, you want to show control.

You want to show using things like it's controlled, it's compliant, it's, you know, safe.

They're very familiar and comforting words to a regulatory department.

Whereas if you wanted to speak to a scientist who's working in proof of concept, you kind of want to use the same buzzwords because they want the sort of safety net there as well.

But you want to.

You want to show things like it's not going to impede you, it's not going to slow you down.

It's just a way of it's.

And I think for talking to people like scientists, R and D scientists, showing that we're there to protect them and keep them safe is very different to.

So to allow them, because we want them to be able to experiment, we want them to be able to do the things that they're going to do.

But it's about doing things safely but without being able to slow them down and then showing the effect of what happens if they are just being able to treat it as the wild west and be all like.

So it may slow you down a little bit, but in the long run, it'll get you to your destination faster.

So it may not be the most direct route, but there's pitfalls and speed bumps and all of that on the direct route.

So we want to take you maybe on a slightly more meandering way.

But yeah, in terms of buzzwords for quality to different departments, I think it really depends.

But I think quality is meant to be structure, safety.

But then showing how that applies to different departments in different ways is important.

Yeah.

How do you.

Do you have any stories that you could share with about, I don't know, using buzzwords or using changing their language or how you maybe turned someone into a champion in one way or another?

I mean, my favorite story is it's not necessarily turning them into a champion, but it's an.

It's an element of sort of a quick win.

So we had, we had a scientist who had worked all of his life in research where it wasn't as regulated, it wasn't as controlled.

And he was fairly late on in his career and he'd started working for us at Malogic, so trying to teach him basic document control.

In terms of when you're working on procedures and when you're working on batch records, you can't just cross things out.

You can't just do all of this.

You can't just, you know, delete your entries and obliterate them.

You know, there's certain, you know, alcoa principles you need to follow for all of these things where you just can't do it.

And I remember one day he came up to me and this is after I had sent batch records back to him numerous times, basically saying, you've destroyed evidence, you need to show what it was originally there for, all of this.

And he came up to me in my office and he just put a record down on the table in front of me and he'd crossed it out and he'd initial and dated it and he was like.

And I didn't even think twice about it.

And he was so proud of himself.

And I was like, I don't know if he was proud of himself in terms of he did it, but he was more like.

But he was just happy to have done it because he wasn't doing it.

And obviously he wasn't doing it intentionally.

He wasn't doing it to try, but he didn't understand the importance of it.

So getting that understanding, getting the why behind it to say, well, you may you cross this out because you've put in a concentration of a reagent, for example, you've crossed this out to put in something new.

But what if that one that you had put down there had been correct?

That could be the cause of why dispatches failed.

But we're not going to be able to see that now because you've obliterated that entry because you could have taken the wrong concentration out of the cupboard or whatever it was.

So it's important that we can be able to see these things.

And once he understood the purpose of it and that we're not just doing it to follow some weird set of document management rules.

People get on board when they understand the why.

And I think that's why it's important to explain these things to people when they're doing it.

It's not just telling them you shouldn't do that, it's explaining why they shouldn't do it.

And that's sort of.

That's my favorite story in terms of project management.

But it's when we were implementing so we, before disclosure, we were implementing Greenlight Guru.

It was actually the project managers who became our biggest champions of it because of how the quality management system would really benefit them in terms of having a good quality management system really does save them time in terms of being able to create the trace matrix.

Because previously we had a very long process which was very manual.

And just being able to show them a different way of doing it is really helpful.

So it's good to have and this is why you get them in early because then once you get the hardest people in, and I think project managers can be some of the hardest people in because there is an element of seeing quality as being the responsibility of quality.

And especially when implementing something like an EQMS or any quality management system, it's to benefit quality and just showing that no, this will benefit everybody as you, the entire company is really, I think showing value is important in everything.

So yeah, when you have those, no, that's great.

I love it when you have those guardrails in place to make sure that when you have a change order, for example, it forces you to answer the question, why is this being changed?

I mean, I just go Back to that 21 CFR Part 820.42 document control.

The things that they ask for, they went, what's changing?

What was it?

What's your justification?

Who is approving this?

When is it approved?

Forcing you to go through all those things and in addition to that asking the question, is any product being impacted?

Do you need to verify it?

Do you need to go back and validate?

Do you need to look at risk?

Do you need to look at this?

So it can be a little tedious.

And you know, in greenlight grew, you can choose from a company standpoint, you can choose to use it or not.

But I think most companies would benefit from that because in my experience, having gone through some FDA inspections and received 43s justification on change orders was one of the big reasons.

Not any of mine personally, but although maybe had they found some of mine, they would have thought so, I don't know.

But yeah, that's a real thing.

But if you go to what you're talking about with the design controls especially, I bring that up because I feel like the change order process in a lot of different companies is not straightforward.

It's difficult if you're paper or if you're in a system, both of those can be really tedious.

I, I, man, this is like going down memory lane.

If I go, if I go to my paper memory days where I remember routing paper around, wow.

I can remember losing change orders on the VP of product development or no, it was the VP of RD R&D's desk twice.

And I'm like, I've, I.

You realize if I have to do this again, regulatory isn't going to just accept that there are no changes that from what they, they have to go through the whole week long review process again.

And so anyway, whole deal.

But with, with an eqms like with Greenlight Group particularly, I don't, I can't speak for a lot of them, but you can go back and see nothing's been changed, et cetera.

So if you have to back something up or something someone doesn't want to approve, it makes it much simpler to go back and approve.

Nobody's trying to, I don't know, pull the wool over someone, a previous reviewer's eyes and getting that signature a second time.

Hopefully that some of those remotely make sense those, those things that I'm saying.

But absolutely to the extent that not in a medical device company, but a pharmaceutical services company that I worked for.

Because of the loss of paperwork.

When we had a paper management system, they had to install a new procedure where every time you moved a piece of paperwork there was a barcode and that barcode was attached to a laptop in a tray in a room.

So you had to scan in that piece of paperwork.

So we knew the last place that it was because paperwork went missing on people's desks, anywhere you could.

People might take it into cold rooms or storage or it could just be left around the warehouse or attached to the back of something else.

And because it's paper based, you put a paperclip on it or whatnot or staple it, you've accidentally stapled it to the back of something else and it's gone forever and you will never see it again.

Yeah, and it's just.

So it doesn't necessarily have to be something as sophisticated as EQMs.

It depends on where you are in your, your company journey.

But just having something electronic, being able to write something electronic and at least have a record of that is, yeah, you need to do it.

It's, it's.

I want to mention one other thing about the design controls because I don't think people realize this or project managers probably don't realize the benefit that using.

And I'm just going to go ahead and toot Greenlight Guru's horn because that is actually one of the things that sold Me on Greenlight GRU as a platform, because as a project manager who was, who was managing design controls and risk management, when I saw how you can maintain the traceability between the two and maintaining those relationships from many to one, one to many relationships from user needs, design controls, design design outputs.

I'm getting all this wrong.

User needs, design inputs, design outputs, verification, validation and the relationship between all of those and relationship to revisions of documents, sources of documents.

It's just, it's huge because when you try to do that in Excel, that becomes your full time job.

Making sure that whoever reviewed this last did not change the spelling of anything so that when we filter it then it will filter properly and we'll actually be able to see everything.

There's lots of different issues there that seem trivial but take up so much time and take away from what you're actually trying to accomplish.

So there's a lot there that you will benefit from if you actually recognize.

And you know, traceability is something everybody really wants.

If you really think about it.

You don't want to spend your days running after whatever revision of document you want to.

Okay, why did we choose this?

Oh, there's an easy link here it is.

Traceability is not, that's one of the examples in my mind that it's not just quality's fetish.

This is, this is every, what should be everybody's goal.

And so it's, it really does help you in your, in your day to day work.

Yeah, and I completely agree with that.

And going back to the sort of change control, if you have a product change control, being able to say this is the change control in which this product changed on and linking that to a design review where you can say, okay, so we've opened up the product again, we've changed it, we've closed it, we've closed the change order and everything is linked together.

And that will give.

Because I don't know how other companies do audits, but we would always bring the project manager in when we were going over a specific product because they need to justify the decisions that they have made.

They need to justify the changes that they've made and being able to find that information and have it linked together rather than, okay, so I've got this change order number now I need to find this change order.

Having it there like that is, you know, it's really great.

So it's, it's a, it's a really good.

And again, I know we're just sitting here touting, well, yeah, EQMSs are available.

But yeah, greenlight guru, the one that we're familiar with, it just is a game changer.

And that is why going back to the initial premise of quality management system belongs to everybody.

Everybody is going to get benefit from it.

And that's why bringing in project managers really early in the onboarding process, because design controls touch everything.

They require documentation, they require change orders, they're going to require quality processes if they have MCs and customer complaints.

So design controls touch everything.

So it's really important that project managers, scientists, everybody who's involved in that design control process has a really good understanding of every aspect of the qms, not just design controls.

And seeing how all of those things can work together and seeing how, okay, if we raise an nc, how does these things all link together?

How can I link it to the different workspaces?

How can I make sure that we're not going to lose that traceability?

Because ultimately it's the project manager who's going to have to justify where these links have come from.

At least in my experience, when we've had an audit, we get the project manager in and they're the ones who are going to have to go through the flow and go through justifying why this happened and what the outcome was.

And being able to link all of those things together is just such a, such a time saver without having to have an Excel trace matrix and then a document tree and then creating all of those things.

It's yet so it's a real time saver for project management.

I would say more than any other department, Project management benefited from getting an eqms probably more than any other department.

They certainly enjoyed it more than any other department, I'd say.

I know I would have, oh man, it would have made my life so much more bearable.

And I actually enjoyed project management quite a bit.

I will say.

I didn't even mention the dhf, you know, auto generation of the DHF reports and design reviews and the way that you can actually maintain the little bit of that's a whole herding of cats in the real world as well.

So the one thing you mentioned there, and I'm glad you did, was in Season Kappas because oftentimes you think, okay, design controls, that's early on, that's early stage, we're done with that.

Come on, we're now we're manufacturing and I've worked as a manufacturing engineer and so rarely do I go back and look at the risk management file.

And it was not part of my really, I don't know, maybe I should have broadened the aperture of my mind.

It wasn't necessarily in my field of view most of the time, but it should be for companies who get kind of any kind of customer complaint going back and being able to see, why did we make this red, this button red, when everybody says that's the go button.

Maybe it should have been green, but maybe there was a reason.

Maybe we had a human factors report and wow, I could just click right in.

Now I see the report, now I see the change order, how it actually was originally green and everybody kept getting damaged or whatever, you know, just to.

Maybe there was a point of caution.

There's lots of different reasons why we do things, but traceability is the only way to maintain that.

Because you think, oh, you know what?

I know this project well, guess what?

When Stryker comes calling or J and J comes calling and you head out the door and someone else has to take over your project, that poor soul, you know, just give them a little bit of traceability so that they can handle that project.

So, yeah, absolutely.

And there are cases in companies I've worked for where somebody retires and a lot of that.

So we have all of the information written down, but it's gone through multiple changes through multiple different QMSs over years.

So you mentioned that I worked for SPD.

They've had products on the market for 35 years.

So pregnancy tests on the market for 35 years, that has gone through a lot of different regulatory.

So it's gone, you know, back when, you know, 13485 is now 2016.

I don't think even 13485 existed 35 years ago.

So it's a case of it's gone through so many iterations and being able to go back and obviously.

But this is why even putting in things like old records is really good in terms of you can then just search for them.

You don't have to look in a box and dust things off.

So scanning things in, even if it's frustrating to do because it'll just sit there, you don't need to worry about it anymore.

But creating an electronic copy of something is really great as well.

Categorizing it, putting it in, because you never know when you're going to want to need it.

And to your point of what?

Why is this red and not green?

That decision could have been made 25 years ago and you don't know.

And then you might turn it green and then it could create a whole slew of other options.

Because colorblindness or whatever you would want to call it or however it would be.

And so but you could lose that information.

And also if it's not documented.

So that could have come from an nc and if that NC isn't documented and linked to a change which is then linked to a design control which has been updated, you're going to lose that.

So it's.

It's.

It's good to have that traceability and then have it be not exactly effortless, but as close to effortless as it can be by just piping in a search and linking it together.

I think.

Yeah.

Yeah.

When you were you.

When you were telling your favorite story, I meant to come back to this point about what I always call a good documentation process or practices.

Gdp.

You mentioned ALCOA principles.

And maybe we just need to run through that because I always.

Every time we use a.

That would be an acronym.

I recently learned about acronyms versus initialisms.

That's a whole nother thing.

But FDA is an initialism.

Did you know this?

It's not an acronym.

An acronym makes a word or I have that flipped.

I think it's.

Anyway, it doesn't matter.

Okay.

But.

Oh, that's interesting quality people.

I just thought they were all.

Yeah, I call them acronyms all the time.

I may have to.

We're going to have to change every single process now.

Which has a table of acronyms because most of them aren't going to be acronyms anymore.

Table of acronyms and initialisms.

This is anything new?

This is just a pure English major, you know, thing.

But anyway, a friend of mine came up to me and so.

Okay, so ALCOA principles.

Just so those who are maybe not familiar with them.

I pulled them up to make myself look smarter so that I.

Because I didn't know if either of us would remember.

That's too long.

Five.

It should be three, you know.

And any acronym should be only three letters.

But ALCOA attributable which.

Which indicates who collects or generated the data.

Who made the subsequent changes.

So who do you attribute this change to?

Legible.

And maybe I should have given you the opportunity to remember this.

You want me to try?

I'll try.

Let's see.

Yeah, see if you can remember all.

Okay.

It's the usual.

It's the.

I can always remember the.

Cuz it's a really silly word.

Just to make the.

Just to make the initial initialism work or whatever.

It's attributable, legible, contemporaneous, original and accurate.

Oh man, Beth, that was good.

Memory.

Yes, I love it.

Contemporaneous.

I thought about that one.

I'm like, yeah, okay, I guess the root word's contemporary, so it's just timely.

It's just.

Yeah, it's at the time.

That's all it means.

But could have been altoa.

You don't want three A's in it, I guess.

But yeah, I guess yes, could be timely.

But whatever.

Okay.

Anyway, contemporaneous, we'll remember because it's a weird word.

Beth, thank you so much for the conversation.

This has been really fun.

If you had one takeaway that you would want the audience to walk away with, what would that be?

I would say the takeaway from this is challenge yourselves to take on other perspectives, which I think has been a bit of a theme of what we've been saying.

Quality people, try and step into the shoes of your project management colleagues.

Try and think about what their what the problems they're trying to overcome and then trying to stick them to their perspective.

And project managers do the same for your quality colleagues because we're all just trying to get to the same point.

So let's all row in the same direction.

Absolutely.

Be willing to listen, project managers, because a lot of quality people are trying to make your life easier.

So yeah, same back to quality people, though.

So willing to listen.

Thank you so much, Beth, and thank you, those of you who've been listening.

Reach out to us if you have any questions.

I'm sure Beth would be willing for you to blow up her LinkedIn or however else we could put or email on here.

Feel free to reach out to me if you have any positive or constructive feedback.

We're always trying to get better.

Until next time.

Take care.

Thanks for tuning in to the Global Medical Device Podcast.

If you found value in today's conversation, please take a moment to rate, review and subscribe on your favorite podcast platform.

If you've got thoughts or questions, we'd love to hear from you.

Email us at podcastreenlight Guru.

Stay connected.

For more insights into the future of medtech innovation.

And if you're ready to take your product development to the next level, Visit us at www.greenlight.guru.

until next time, keep innovating and improving the quality of life.