when it comes to verification and validation, medical device companies need to ensure that what they're doing actually makes sense.
how confident is your medical device company when you reach the design verification and design validation stages?
known colloquially as "v&v," for many it feels like you're on the homeward stretch to market, yet there are often issues causing companies to get stuck.
for example, do you want to ensure that you have the "right" answers? or are you more interested in asking the right questions? the distinction can be very important and is a big part of what should inform your v&v processes.
i had a chat with mike drues, president of vascular sciences and a long-time consultant for medical device companies, fda, and health canada. we discussed our thoughts on v&v and what companies can do to use processes that make sense.
right questions or right answers?
design verification and design validation
we both often get asked about v&v and the difference between verification and validation. these are very much part of design controls and are distinct from one another while being applicable across different scenarios. in fact, when it comes to preparing a 510(k), you'll quickly realize their importance.
verification is proof that you designed the product correctly. do your outputs meet your inputs? have your inputs been written well and have you recorded sufficient outputs? the overall question is "did i design this device correctly?"
validation is subtly different. the overriding question is "did i design the right device?" this is, of course, a case of asking the "right questions" rather than looking for the right answers. what are the user needs and intended uses? is this the device to meet those needs? validation happens fairly late in your product development process, yet it's a reflection of how well you did the early work--did you clearly define user needs?
the overall purpose of v&v is to demonstrate that the device total outputs (design, manufacturing, software, etc.) meet what you wanted it to do. fundamentally, the definitions of verification and validation will remain the same in different contexts for your medical device.
a common question
drues frequently receives questions regarding change management within companies. if they have a device that's already on the market and through 510(k), manufacturers are often confused by the requirements for making changes.
"if i want to make a change to my medical device, how do i know if i need to go to fda with either a special 510(k) or pma?"
this is usually versus a question of knowing when a change is not considered significant and when it is managed by filing a letter internally.
this generates a lot of problems for medical device companies and comes down to v&v. you must demonstrate that the change doesn't affect the safety and efficacy of the device. you need to test and research--do the work to prove it. this is the essence of v&v.
at the same time, i prefer that the regulatory requirements be factored in as part of the decision-making. that doesn't mean doing things just because the regulations say so, but doing things that make prudent, engineering sense, too. the end goal is to demonstrate that your device is safe and effective. companies get caught up trying to please regulations, that "right answers" bit, then sometimes find themselves doing things that don't make a whole lot of sense just to please a checkbox on a form.
drues advocates that you do what makes sense for your device, then bring in the regulations. he had an example where someone was designing some complex testing and wanted some help but couldn't answer as to why they were doing it. you have to know why you're doing the test to begin with! it's not a "going through the motions to meet v&v" thing.
a lot of companies get products through submission, launch into production, and assume they won't need to make a change. this is naive. it could be as simple as a logo change for your company or as complex as a material change in the construction of the device. understand the impact of the change. conduct those v&v activities and consider the regulatory impact without blindly doing things that don't make sense. it shouldn't simply revolve around "i need to do x, y, and z for verification and validation in order to put in my submission."
an iso auditor that i've met has said, "we need to do a better job of root causes." he recommended the "five whys," which can also be useful for v&v. if your root cause is "to satisfy a regulatory requirement", you need to rethink your approach.
drues finds that when he asks why companies are doing things a certain way, he often gets answers like "i don't know" or, worse, "because it's required." if the test provides no other value and is only happening because it's "required," there's no point. he suggests going to fda separately and explaining why it's not practicable in the case of the company and what would be useful instead. fda is open to reason where a testing requirement may not be suitable for you.
always seek feedback
we both are huge advocates for companies getting feedback early in the process through the pre-submission program, before you put together that official submission.
communicate frequently with fda or relevant regulatory agencies. drues says "tell, don't ask," and "lead, don't follow," when it comes to dealing with fda. it's a case of knowing the right questions to ask.
don't go in and ask, "what do i do?" first, it's your job to know what to do. second, you might be opening up pandora's box with the regulatory authority. they can now instruct you to do whatever they ask. tell them what makes sense and why. reviewers will ask questions if they have them. expect that if they have to provide you with "right answers" or guidance, they will be looking for those in a formal submission and they had better be impeccable.
one of the few requirements of the pre-submission request is that you must submit your questions to fda in advance in order to get a meeting. to drues, this violates his rules of not asking fda questions first. in order to successfully get your meeting, you must ask those questions, though. his advice is that when you craft those questions, you take a "design" approach. create leading questions so that the only answer they can come to is the one you want them to. ask the question in such a way that gives you the answer that you want.
as stephen covey wrote in the seven habits of highly successful people, "begin with the end in mind." work out where you want to be and move backward from there.
testing and proof
many companies tend to obsess over getting studies done. don't get so hung up on clinical studies. you have to have good engineering in the first place. there's a place for benchtop, animal, and clinical testing, but no kind of test will be perfect. you'll have limitations every time. human factors, usability, etc. will always come into it.
the most important thing, i think, is to realize that verification doesn't always specifically mean a test. engineers always want to use testing methods to prove things, but verification can be simpler; for example, through analysis or inspection. prove that outputs mean inputs; that is the overriding requirement. use testing where it makes sense to do so.
one of the most common questions drues hears is, "if we came to fda with our new device, what will they want to see in terms of safety, efficacy, and performance?"
sure, that's an important question and we understand why you're asking, but look from a different perspective. one day it could be your own family member or friend who needs to use this device. as their concerned loved-one, what do you expect to see in terms of safety and efficacy? what would put your own stamp of endorsement on it? when you can show this (and only then) is when you should go and have a discussion with the regulatory authority. "we designed the device perfectly, yet the patient died anyway" is a scenario you hope to avoid. the solution to mitigate this is to get people to think of the device being used on their family.
right answers or right questions?
as you can gather from our discussion, we lean the way of crafting and seeking the questions that are going to form a solid foundation for your verification and validation activities.
sometimes, looking for "answers" will leave you constrained to being told what to do and then monitored to ensure you did it.
keep what makes sense for your device at the forefront and, if you are in a pre-submission situation, formulate questions so that they point to the answers that you know will be the best scenario for you. this is with safety and efficacy at heart, of course. are you happy for your device to be used by your own family?
jon speer is cofounder and vice president of qa/ra at greenlight.guru.
[image courtesy of qimono/pixabay.com]