What’s the difference between design verification and validation, and why is it so important?
Today’s guest is Niki Price. Niki is a Medical Device Guru with 15 years of experience in medical devices who worked in production, quality, product development, and project manager. Today she discusses questions like what is being tested by design verification and what is being tested by design validation.
Listen to the episode to hear Niki discuss what’s involved in being a verification engineer, tests used for verification, and the biggest challenges she experiences in her role.
Watch the Video:
Listen now:
Like this episode? Subscribe today on iTunes or Spotify.
Some of the highlights of this episode include:
-
Niki’s background and experience
-
The process involved in being a verification engineer
-
The Greenlight Guru difference
-
The steps that a verification engineer has to go through
-
Tests used for verification
-
Difficulties with the steps for verification
-
The career path to design assurance professional
-
The biggest challenges about this role
-
Pitfalls of design verification
Links:
Beginner's Guide to Design Verification & Design Validation for Medical Devices
Memorable quotes from Niki Price:
“I wanted to be drawing body parts in an OR somewhere. Or illustrations in books.”
“The best time I ever had was sitting at my desk running through thousands of lines of data and trying to make charts out of it. I loved it.”
“Requirements are a lot of times going to be your acceptance criteria for your testing.”
“You have to think about verification is for design inputs, validation is for user needs.”
Transcript:
Etienne Nichols: Hey everyone. Welcome back. I'm excited to be talking with Niki Price today, although I don't know if she's excited to talk to me yet or not. We'll see. How are you doing, Niki?
Niki Price: Good, good. Just a little under the weather, so I apologize if I sound scruffy.
Etienne Nichols: Okay, so it might actually make you sound good on recording, so we'll see.
Niki Price: Hey.
Etienne Nichols: Niki's a medical device guru at Greenlight Guru, and.
But before coming to Greenlight Guru, she was a validation engineer. And why don't you tell us. And you know what? Let's. We can even go up a little bit before then, because we'd liken to talk a little bit about validation today.
Or not. Validation. Verification. I'm sorry. Um, but why don't you give us a little bit of your background and your experience?
Niki Price: Yeah. So, I've been in medical device for quite some time. I started off like most people in production, dissecting tissue for Class III implantables.
And I moved into quality just kind of naturally. Um, I think most people kind of get out of production and start to do other things.
While I was in quality, I started doing incoming inspections. I did shelf-life validations for a company, and then I went into other aspects of quality. I'll say I've done everything for quality that I can think of.
And then I ended up getting sort of recruited into an IBD company where I was doing verification. I was called a verification engineer, but basically, I was on the verification side, which I always said was kind of the last stop for the quality release, because we tested everything to make sure that it actually worked before it got released into the field.
So.
Etienne Nichols: Okay. And so, one of the things that I wanted to throw out, too, was I was always impressed when I heard about your experience in college with the anatomical art. Is that right, or.
Niki Price: Yeah, So I actually went to school for medical illustration. I was on a medical track. I couldn't have. The only reason I knew what a medical device was is because I like drawing them.
But I would have never thought I would have landed here. I wanted to be drawing body parts in an or somewhere or illustrations in books.
Um, and I was just right at that time when things started to go digital.
And so, when I got out of school, I said, let me get a job, and I got a job at a medical Device company and never looked back for the most part.
Etienne Nichols: That's so cool. Well, I'm sure it activated parts of your brain that maybe some of us in the industry haven't activated. I don't know.
Niki Price: But it makes for good conversation because people will be like, oh, you're an engineer. And I'm like, not by trade. I'm actually an artist. And so sometimes it throws people off and sometimes they're like, oh, that's really cool. Tell me about it. So is what it is.
Etienne Nichols: So.
And I know you got into project management as well, so you saw all aspects really of a design in the design development process. But you're a verification engineer. How did that.
Can you tell us a little bit about that process?
Niki Price: Yeah, I actually, I will say that's probably the thing that I loved doing the most on that side of things. I'm a geek for writing protocols reports.
I love doing data analysis. Like my. The best times I ever had was sitting at my desk running through thousands of lines of data and trying to make charts and things out of it. I loved it. But generally speaking, where I worked, we had software engineers that would do the software engineering and then we would actually get parts for our device from OEMs. But once it all came together, it was kind of us as the last stop shop to say, okay, here's our requirements that we have for the device, here's all the testing that we're going to do for it. So, we may not have necessarily been the ones who did the design outputs, but I had to link everything.
And so, I always use this as a, as a way to kind of talk about Greenlight, because at one point I was managing in Excel six different trace matrices for two different products based on the different time zones, based on the different markets, and they were like 600 pages apiece.
So, I had to do all that manually when we changed things. And we did iterate things quite often.
So that's why I always feel like, let me, let me tell my customers about this because this is why I would have liked Greenlight.
But generally, yeah, we wrote requirements, we wrote all the documentation around the requirements. I wrote all the protocols for testing, coordinated with the people in the lab to do the testing, analyzed all the data, um, and made sure it, it passed. And if it didn't pass, I was the one who was also writing up the, the, the problem reports or the, I'll say, the deviations for the protocols.
Etienne Nichols: Okay, so we have to get into all of those different processes. But before we do, you talked about 600 pages of, of Excel. That's. Oh man, I'm blown away a little bit by that.
Niki Price: That was, that was for one trace matrix and for that particular product I had four and then, so 600 times four and then another device I worked on, I think they were, it was about a 400-page matrix times, times four. So, it was a lot.
Etienne Nichols: And what.
Okay, so that in and of itself, okay, I can see. Well, it seems like a lot, but it's still going to be a lot. In Greenlight Guru.
Niki Price: It would be, yeah, it's a lot. But the thing is, is greenlight at least you can put everything in there.
You can search for things, you can tag things, things light up green. You know, if you say it passes. I don't know, it's like I had to go in, if, if somebody said oh, okay, we're going to do the new version of this software.
I had to go in and manually look for like okay, what, what protocols does this impact? And write up an assessment. And then I would have to do sorting and to try to make sure.
And then it was just, it was a lot of manual work that then I had to constantly spot check myself because there's, there's just no way a person can handle that really. And I very much had errors here and there, but I think I did a pretty good job as a one man show for that.
So yeah.
Etienne Nichols: Did you ever have many to one or one to many inputs, outputs, things like that? How did that work in Excel?
Niki Price: So, with Excel we did have.
The way we did it is we just had our design inputs in one thing like per line. And then sometimes yes, we would have multiple user needs or multiple design outputs but never had like design inputs linked to design inputs or had multiple design inputs linked to one user need. It was all, I'll say it was all anchored off the design input went like that.
So, a little bit different. And I didn't have, you know, replications or things like that. But I will tell people generally, I think the way that greenlight looks, it is like an Excel spreadsheet. You know, I don't think it's that different other than it has things that kind of help you out, you know, from searching and printing. Because I would have to format that Excel spreadsheet everywhere single time. Sometimes it took me a full day to get it to print correctly.
And then again, it's like I have to make sure like okay, I just did 30 protocols. I have to make sure I put pass for everything. There was no like Indicator.
Now I probably could have built a macro in there, but that's not to say like, you know, again, it was just, it was very, it was very time consuming.
Etienne Nichols: How'd you get it signed off? Or did you, did you.
Niki Price: I had to print it. So, I had to print it. We, we had an eQMS, but we did not put any of our design controls in the eQMs. So, I had to print it, and I had walk it around.
And do you think anybody actually reviewed it?
Probably not.
Etienne Nichols: And I bring that up just, I mean we're talking about contrast. I mean I didn't anticipate or expect to talk about green light grew, but I mean, you brought it up.
So, what's the difference with, with green light grew then in that regard?
Niki Price: Well, for me I would have enjoyed it just because one, I could have electronically kind of had it signed off as part of the design review. We always had these in our design reviews, but it was a separate sign off and it was part of the dh, which for me it's like I had to print that out every single time and put it into a binder and then put it into a cabinet and maintain it that way.
And then if I ever, of course I would always just pull up the version that I had saved on my computer or in SharePoint. But who's to say that was the right version, right? So that you have that too.
So at least in Greenlight, you know, you're working off of the latest and greatest version, you can do that electronic routing, have your design reviews all within the system. It was just too much all over the place. We had eQMS, we had SharePoint, we had a local server, everything was in boxes somewhere.
You know, I, for again having everything together.
Etienne Nichols: One of the. So, one thing I would bring up too, because this is, I, I live this a little bit. I don't know how many pages it would have been when I was managing risk matrices and design, design, design trace matrices, but, but there's a lot too. And the thing that I loved was so I kind of got to where in order when, when I would go around and get it signed off, I would basically gray out everything that was previously unchanged and just the parts that were changing or needed to be approved of.
That's how I got, kind of got my confirmation that okay, they probably did review the part that needed to be reviewed.
I love that Greenlight Guru does that automatically. The things you reviewed last time are locked. Don't worry about those. They're. They're locked. I mean you can unlock them if you want to change them or whatever, but.
Oh, so nice.
Niki Price: Yeah, yeah.
Like I said, I always use as an example, because this is, like, why I personally would like it. You know, it's not me just trying to say, oh, you know, blah, blah, blah.
Like, I would have used this practically, because I'm telling you, I spent days, sometimes,
luckily, I never. I didn't always have to get them signed off at the same time, but sometimes I did. And so, yeah, it just. The amount of frustration in late nights of just trying to get it to print correctly.
Etienne Nichols: Yeah, I don't. I don't know if you identify this, but I meet some younger engineers sometimes younger. I'm. I consider myself to be young still. I hope that I'm still young, but anyway.
But I meet them that are younger than me, and I. And they've never used Excel for design controls, and I'm like, you are so spoiled. You have no idea how difficult life can be.
Niki Price: I know. Well, and the thing is, is that that trace matrix came from an FDA inspection because, like, we didn't even.
That was the whole point I started. The job really was implementing a traceability software, but it didn't really work that great.
So, all our trace matrix was basically a Word document that said, here's all of our requirements and here's where we tested them.
And the FDA was like, nope.
So, we ended up having to build something that was essentially what Greenlight has,
and it took me six months to build it.
Etienne Nichols: Time well spent, I'm sure.
Niki Price: Oh, man. And then I had to retroactively put everything in there. So, imagine, you know, trying to put, you know, almost 900 requirements and everything that it linked to?
Yeah, I spent. I spent way too much time on that.
Etienne Nichols: Well, isn't that what you want, your project lead, project manager, and, you know, senior project engineers doing, you know, spending six months building out a spreadsheet?
Niki Price: Well, I wasn't even the project manager. I was just the verification engineer. But that's the thing is when you're doing that type of work, I think you're inherently a project manager regardless.
Right. Because it's like you have. You have multiple protocols going on, releases happening, here's all the documentation, deliverables, and here's all the people doing my testing. So you kind of end up being a project.
That's how I got into it, was that I was doing kind of R and D work, so.
Etienne Nichols: Okay, well. Okay. Sorry for going off on such a tangent. I just. I couldn't help it. I. I haven't talked about green light grew with anybody. I'm not working as closely with the customers anymore on it.
So, it's just kind of interesting to, to talk shop about that, like the good old days. But the battle days, whatever you want to call them, they're all good, but.
Okay. Well, you mentioned a lot of different processes that a verification engineer has to have first. I guess get your Excel spreadsheet or Greenlight Guru, whatever that tool you're going to use, and I guess that'll dictate when we get to the next step. But what are, what are the steps that a verification engineer goes through?
Niki Price: Well, and I'll say this, I think to the terminology, verification engineer might not be the term that everybody calls it. I mean, it might just be engineer, R D engineer, design assurance engineer.
But you're essentially brought in, you know, for the lifecycle of the product. So, you know, a lot of times we would get user needs from marketing. So, they have already scoped out the user needs.
And then they were like, here's our user needs. Now you have to come up with requirements. And of course, we all know that you may only have a handful of user needs and you're going to have to make more requirements than there are user needs.
So, we would sit in a room sometime, you know, for months at a time, and just try to come up with all the different design inputs, slash requirements, whatever you want to call them,
and just make sure like, hey, did we, did we hit everything that matters? You know, again,
there's only so much into the weeds you can get. But we just want to make sure that we're covering everything.
And then from there, as a verification engineer, your mind starts thinking, how am I going to test this? How am I going to test this? And I know when I'm talking to customers, they come up with an input.
I'm like, think about how you're going to test that. Because if you can't test it, you know, you got to think about, like, it's either written in a way that, you know, you got to, got to change it so that you know how to test it.
Don't want to have those, you know, ambiguous requirements.
Yeah, I was like, why am I saying unambiguous? But yeah, you don't want it to be like, I don't know how to test this. So, you want to make it, you know, direct.
So, you know, okay, this is exactly. I tell people, requirements a lot of times are going to be your acceptance criteria for your testing. Right. Because that's what you're that's how I did it. It was like my requirements were pretty much my acceptance criteria and my protocols.
So that was really the first thing. I would go back there, and I would just start playing around, am I. Because how many times I got requirements from somebody is like, this doesn't even. It's not how it works. This isn't how the system works.
So, we would have to redo those. But.
Etienne Nichols: And can you give us an example?
Niki Price: Well, so I'll say this. Like, sometimes when you're the one working on the device and you have people who haven't really worked with the device in quite some time or they haven't at all, they go, oh, it's got software.
Oh, they'll write it a certain way like, oh, the software does ABC. And then you immediately come back and say, that doesn't happen in this software. You know, or people have a tendency to copy and paste from other projects. Software's not the same. Right.
So, there were several times where I was like, oh, this doesn't actually happen in the software, or this doesn't actually happen on the device.
So again, that's why you got to bring everybody into the room because some people work closer to it than others and have that collaboration. But yeah, I would go back there and start testing and make sure everything does work as expected.
Right? Because either the, the input was written incorrectly or somebody didn't do somewhere along the line, maybe they didn't program it. And sometimes that would get chucked back to, you know, software engineering, like, hey, we need it to do this.
It's not doing this.
Etienne Nichols: Were some, where's some of the tests? What, what were some of the tests that you used for verification?
Niki Price: Well, talking about this particular device, again, it had software in it as well because it was IVD. So, we had controls. Right. So, we had to, when things were results were inputted, you know, it had to have certain controls that went along with it.
You can't just test something and not have a quality control along with it.
Most of the time that's just part of the CLIA standards and things like that.
Etienne Nichols: What do you mean by that?
Niki Price: So, if you're doing, if you're doing diagnostics and things, you're dropping blood into wells and you're mixing it, you're trying to get type screening infectious disease.
That doesn't mean anything unless you have a control standard next to it. Right?
So, you have to ensure that, like when you do your COVID test, you know, it has a control line. Because if you don't have a control to actually compare it to. I don't know if it's right or wrong.
Right.
So, yeah, most of these you'll see some sort of control in there so that, you know, hey, because if the control doesn't work, it's possible that it's. Your plate's invalid, your test is invalid. So, you want your control to be pos neg, whatever that control is. So, you know, your results are good.
And sometimes they'll even do it in duplicates or triplicates too, depending on what the, what the test is. So, we had a lot of controls in place, and the controls had to be a certain thing.
We had certain algorithms around assays. We had things hardware wise that, you know, it has to, has to drop this many microliters of sample or pull up these many microliters of sample.
We actually also had interfering substances, IVD. You're gonna see where people have to really think about sample interferences and things like that. So, we had, we had requirements around can we test samples with lipids, can we test samples with bilirubin, samples that have certain levels of hemolysis. And these are all things that you have to decide, can your device do it or not? Right.
So, if you have a user who's saying, well, I need to be able to test samples with fat in them, with lipids, okay, you know, you got to try to try to do that. But a lot of times there's ranges.
Systems can't essentially depending on what, what it is. You know, if you've got a layer of lipids on top of blood or something like that, system's not going to be able to see through that. So those are all things you have to just, you know, figure out during your R D phases and your feasibility.
Can we actually test for these things or get results when we have these?
Etienne Nichols: So, okay, what were, when you went through that verification? You,
you got the. I'm trying to remember the string of things that you said that were really key to your job.
The analysis and then the reporting.
What were some of the, the other steps and, and the difficulties that you faced with that.
Niki Price: Yeah. So, you know, we have all these requirements, and they're signed off.
Boom. Now it's up to me to create the test cases around it. And really, I mean, when you have several hundred requirements, it doesn't make sense to have several hundred protocols. That's ridiculous. Right. So, then I would try to chunk all these inputs into logical ways of testing. Like, all right, maybe 30 of the inputs actually are for a particular module or for particular process flow.
So, a lot of it was me back there actually working on the system and trying to go, okay, I can do this here, I can do this here. And really coming to an efficient way of building a protocol.
And a lot of it was just performance as well. You had performance standards that you had to hit, but that all to say, then you'd start chugging and creating protocols and it's not really usually one person who can do all of that.
We had over 100 protocols for any given time that we would have to run. And again, this isn't, you know, a device that's been around for a while and it had a lot of requirements, so it made sense.
But yeah, we had over 100 protocols and it was growing with each release. But you would then essentially get your protocol approved. However, I had to walk everything around because it wasn't in the eQMs.
And then you would run those tests.
And so, from there, fingers crossed it works because it worked before or, and that's something too that you have to really think about is you got to have some sort of what we would call either like a problem reporting or anomaly reporting.
I know some people will put it into their deviation again though. It's, it's like, it's hard to say if it's pre, if it's in development, it's, it's pre-release. It's hard to really call it a non-conformance at this point.
Right. Because you're not, you're not non-conforming to specs that are, you know, for a release product. So, we actually had a separate sort of, I'll say process for just anomalies that happen during verification and validation. And that's the fun part is trying to justify those.
Why did it happen? Here's where all your root cause analysis comes in. Why did this happen this time? So, a lot of times I was back there trying to figure out, okay, technician did all these things, all this stuff happened, let's look at the results, let's pull up reports from the system and see like, why did this happen?
And sometimes that would lead us to changing the algorithms on the system because it's not reading what we want it to read. So, we have to play around. So, then it goes back to doing some design work, running the protocol again and getting the results that you're hoping you'll get.
Etienne Nichols: Yeah. And then all of those need to be linked somehow to your trace matrix traits, I guess.
Niki Price: Yeah, well, and so, you know, doing in Excel, I mean, you Type out what it is. You say, okay, I just ran version 1.0 of my protocol. You type it out and then if you have to do it again, you have to know to manually go in there and put, I just did version 1.1. Because that was something that they wanted to see is they wanted to know for every requirement, what was the latest and greatest protocol and summary report that you had, what was the software version, if you're testing with software, and they wanted to see that in the latest and greatest design output. So, yeah, sometimes trying to manage all that testing happening at the same time could get a little bit overwhelming.
But, you know, I enjoyed it. And then you get to write the report to say what the results are.
Etienne Nichols: Yeah, that can. Can be the fun part.
Niki Price: Not always, but yeah, I said I enjoy writing. I did it. But yeah, it's always it. You know, it's one of those things where it's like you get so excited to run a protocol and then sometimes on day one, it's like, up this happened.
Why?
So then once you figure out what's going on, you know, it's either was the sample messed up? And that's the great thing about biologics is like, sometimes it's the sample. It's not even anything that you can really predict.
Sometimes it's the lot of materials that you're using. Sometimes the system just isn't working as expected, or sometimes it's just you got it wrong, and you got to go back and change it.
Etienne Nichols: Yeah.
What you've been describing really reminds me of a conversation I had with Orla Conufton. I think she's Aztec Medical. And we, we basically talked about the design assurance professional. You mentioned, Design assurance Engineer.
And really, I think that's the, the title that I'm not very familiar with, but it's the role that I'm extremely familiar with. And it's kind of like. Because all the different activities you were talking about is essentially the marriage of a product development engineer and a quality assurance or quality engineer kind of rolled into one.
Managing that with a little bit of project manager mixed in. Just dash to make sure that they stay organized and they're managing those Excel matrices or whatever it is, as far as the design control matrices, probably some risk management, and then managing that verification, those verification activities, and making sure it's an efficient. Because you have to use. You have to know the device.
Maybe you didn't design it, but you have to know the device well enough to say, okay, if I run this test with this test case, I'm actually going to bust out 3, 4, 30 requirements in one test, and then I can roll on to another one and do another. So that design assurance professional title, that's kind of one of my things.
That little, little interest is to figure out a way that we can figure out a career path to that design assurance professional that's not just zigging and zagging and then getting pulled into the middle.
I don't know how you landed there.
Niki Price: Yeah. So, it's kind of interesting. Like I said, I think, I think. And I'm hoping I'm not offending anybody, but I think verification engineer, a lot of times that's tied to heavy software stuff, which I'm not a software person necessarily, but verification engineer, design assurance engineer, quality engineer is one that I was like, oh.
I was thinking to myself, like, okay, I think technically I'm kind of a quality engineer because I'm doing a lot of the engineering work, but I'm also the person who's making sure that the release is good before it actually gets released.
So. On the quality side of it, too, because it didn't go back to the quality department, we were the last stop before it.
It went out to the public.
So, I was. I kind of called myself a quality engineer for a while, and I'm not sure if that's correct or not, but I'm like, I feel like I'm doing a little bit of both.
And then years ago, when I did shelf-life validations, I wasn't even called either. I was a quality associate, you know, and I just happened to be lumped in.
We did shelf-life validations completely separate from the validation department, which focused heavily on just the equipment.
So, you've got a couple different things there, but I think everybody calls it a little bit something different in the end, I think product development, period. Because you have a lot of engineers that come out of engineering school and they're like, I'm going to design a bunch of stuff, and they get roped into doing all of the development, you know, documentation. And I'm. It's like, oh, sad face.
Etienne Nichols: So, I know everybody wants to be an R and D engineer when they come out with minimal documentation.
Niki Price: Yeah. And it's just not that way. I think a couple of companies I've worked for over the years, they were very R and D, and then they realized, oh, shoot, we can't just be back here in a lab throwing stuff around. We have to start doing this product development process early on.
And it was hard to kind of get people into that mindset. I've seen, I've seen where I've. Where you come in and like everybody's on that. They think scientifically and they're all about the science.
But then it's like you got to kind of bring that quality part into it. So I think having that product development process in R&D is, is key.
Etienne Nichols: Yeah, yeah. And you mentioned something there. Like I kind of consider myself a quality engineer. Well, there's, there's a couple things there. You know, there's our title that we're given by the company and that is just, you know, however they tier their compensation is probably tied to all that. But then there's what you consider yourself and like, if you considered yourself a quality engineer, the things that you read maybe outside your organization, publications and things like that were probably associated with what you considered yourself in your mind. I'm a quality engineer, so I'm going to learn more about quality engineering.
If I'm a product development engineer, I'm probably going to learn more about the product development engineering.
But that's why I think there's that middle design assurance engineer that we don't have anything for that. Well, there's a lack of, I think. And if, if someone was in that role and they said, I'm a design assurance professional, I'm going to go get that design assurance information anyway.
Doesn't matter. And I don't even know why I'm talking about it, but that's my little hill that I'm hopefully not going to die on, but I talk about probably more often than I should.
Let's talk about something else.
What were some of the biggest challenges?
And I'm going to go ahead and phrase it this way. What were the things that probably made you cry when it came to this role and that you really wish you could go back and say, Niki, this is what I do differently.
Niki Price: Oh, so if we're. Are we going to talk product development?
Because I could go into every type of role I've had and tell you times that I've probably been crying, but product development. So, when I got into it, I, and I was probably misguided. I went from a very heavily regulated Class III device in quality to a Class II in RD. And my first thought was like, great, I don't have to do anything. Like I can just be free and lackadaisal about everything.
No, that is completely wrong.
I actually, and not that I ever was. I've always brought quality to what I did. It's just there was a little bit. I feel like a little bit of burden because I'm like, okay, I'm not going to kill anybody.
But that's not the way to think at all.
In fact, I feel like I did pretty good overall. Like, I was really good about reviewing things, but like, everybody, when you do something for a long time and you're doing the same thing, it gets monotonous because you rush to the finish line, shoot, this didn't work. Go all the way back, and you do this over, and it's like this rinse and repeat thing.
And you get so tired of sort of verifying the same thing over and over again. You're like, why can't we just get through this?
I actually released. I was the last stop. I reviewed a protocol; thought I did everything I needed to do. It went through all the reviewers, it got approved, it got put on the field. And then right before everybody started using it, they were like, oh, there's an error. This is. This is wrong in the software. And I was like, what?
So of course I'm like, freaking out. I go back through my stuff, and I was like, son, like, I missed this, I missed this. And we've all done it. Nobody's perfect. And I got so upset. Now, granted, I mean, at the time, like, everybody was really nice. It was like, Niki, we're just going to recall it. We'll. We'll fix it.
We'll implement some additional things. Which I felt like, oh, this is my fault that we're having to do this extra stuff.
But you learn, you know, by your mistakes. I'm just glad that it. It didn't cause any issues. But it could, right? I mean, that's the thing is, like, this particular product, I'll say this wouldn't have hurt anybody, but it could have if I hadn't been laser focused.
So, it really helped me to go, you know what? Okay, I gotta. I gotta think of a better way to do checks and balances when I'm doing my reviews. And so, you know, that really helps.
But no, I cried. Like, I absolutely got so upset thinking that, like, oh, my God, I just release something and I missed. I missed something. And what if this happens again? I think that is definitely, especially in quality.
That's something you live with every day. Because it doesn't matter how many times you read something, how many times you flip through, and you look and you double check. You can always miss things. And so you just. You try to be methodical about it, right? But when you're doing a hundred things, you Just have to stop and focus on what you're doing at the moment.
Make sure you do it with the greatest care and give it all of your.
All of your focus. Because we do. We all have things. People are talking to us and you're like, oh, you know, and you just miss a whole entire chunk of something that you were supposed to review.
Etienne Nichols: So what? So, one last question. I'm curious. Is there anything that you see, because you work with a lot of customers now, is there anything related to design verification that maybe you see regularly that is a pitfall, maybe even for the entire industry or things that you could. Maybe a piece of advice that you would give to people who are approaching design verification.
Niki Price: Um, so I think. And I've. I mean, I've done this myself, I think most people interchange the two, you know, I mean, and it's sometimes hard, right?
Etienne Nichols: It's like validation and verification.
Niki Price: Yeah, yeah. Because. And when I've done it my entire. When you're on paper, it's easy to say this. I think some people say, okay, I'm doing verifications because it's like one test or two tests, validation, they'll usually kind of lump. You have like, you know, shelf-life validations and packaging validations.
And sometimes people will call things validations or verifications and they'll just kind of intermingle them, you know. And again, when you're doing it in Excel and on paper, it's easy to do.
And I'm not going to say, like anybody's going to come down on you super hard about it, but again, you have to think about verification is for design inputs, validation is for user needs. And so you have to make sure you, you have that connection between the two.
Because if you just call everything a validation.
Etienne Nichols: Yeah.
Niki Price: Well, you're not doing the verification part in the guidance for the design inputs. So that's something I try to remind people. Like, hey, are you actually verifying a design input with this or are you validating a user need? And think about how you want to title that.
Etienne Nichols: That's really good advice. Yeah, yeah. I think some companies get to the end and they want to.
They're approaching. They get through verification and they're approaching their validation. Then they look at their user needs at that point and say, can we adjust our user needs so that we're going to pass our validation?
And that's not a good way to look at it. So.
Niki Price: Yeah, no, and that's the thing is, like, there are times when, you know, user needs fall out of the scope of the project, but the user needs come from the users and so try not to change those.
Right. That's.
Etienne Nichols: Yeah, yeah.
Very cool. Thank you so much, Niki. I really appreciate you taking the time to talk to us today.
I hope you have a good rest of your day and thanks. Especially when you're not feeling great, I hope you get to feeling better.
Niki Price: Hopefully have fun.
Etienne Nichols: I'm totally jealous of your last vacation that you were on, but I won't bring it up if you don't want to bring it up.
Anybody wants to talk to Niki about that, please reach out to her on LinkedIn. She's one of our medical device gurus at Greenlight Guru, and so hopefully you get to work with her one day.
Did that sense come out right? Hopefully get to work with her one day.
Niki Price: Yeah, if you're lucky, right?
Etienne Nichols: Yeah. Thank you, Niki. We'll talk to you next time.
Niki Price: All right, bye.
Etienne Nichols: Bye. 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 podcast@greenlight.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.
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.
