Intended Use Validation – what’s required, and a little extra…

…for Biotech, Pharma & Medical Device Companies

In this age of a global pandemic, it’s becoming increasingly difficult to stay on top of all (compliance impacting) activities during product development. Whether it’s the race to produce a vaccine for COVID-19, or the next medical device breakthrough for those living with Diabetes.

On top of that, we are all extremely busy, stressed, and worried about our family, friends, clients and colleagues.

Which means, this is when non-product software validation activities slip through the cracks…because the compliance aspects are often misunderstood, set aside for later or simply forgotten.

Especially when you’re dealing with the confusion around home-grown applications versus commercial off the shelf products.

The problem is, whether it’s considered unsexy or trivial – if your Non-Product IUV Program isn’t properly set up, executed, documented and maintained – then it becomes a Big Problem for required submittals or untimely audits.

This explains why our clients brag about the support we provide to ensure their submittal was accepted, or they passed their CE or MDSAP Certification audit the first time – we know what we’re doing.

Let’s dive right in to what is required, and what is considered ‘nice to have’ for non-product intended use validation, after providing a few definitions and explanations.

Applicability Definition (per the FDA)

• Software used as a component, part, or accessory of a medical device
• Software that is itself a medical device (e.g., blood establishment software)
• Software used in the production of a device (e.g., programmable logic controllers in manufacturing equipment)
• QMS Procedures, Instructions and Processes
• Software used in implementation of the device manufacturer’s quality system (e.g., software that records and maintains the device history record)

For this article, we will be discussing non-product software used in the production of a device or clinical product, including manufacturing.

What software tools require validation for intended use?

This question comes up a lot, so in short, they are non-product software applications which are utilized during the design and development of your customer facing product – whether it’s a drug, medical device or instrument.

There are two IUV categories:

• Software that’s built in-house (home grown)
• Software that’s purchased (commercial off the shelf – COTS)

What is required for intended use validation?

Let’s begin with non-product software that’s built in-house.

Software that’s built in-house, requires the same compliance measures as if you were going to sell it to your customers – even though you’re not going to.

Therefore, you will have two phases:

• Verification
• Validation

Verification is the process of making sure that you have objective evidence that specified requirements are met. It is usually performed by tests, inspections, and in some cases analysis. Did you build what you intended.

Applies to:

• All Design Controlled Products and Processes.

Validation is the process of making sure that you document objective evidence that user needs and intended uses are met and consistently provide the intended benefit.

Applies to:

• All Automated QMS Processes
• All Design Controlled Products

Let’s talk about a ‘real world’ client’s experience with intended use validation (IUV) for an in-house created software application.

We supported a drug manufacturing Client who was executing a BLA submittal and they hit a wall, when the FDA inquired about a software application they’d built, which was used to capture clinical trial data for their drug testing phase. Because it was an application they weren’t planning to sell, they weren’t aware this application would require (intended use) validation.  So, each time they submitted the BLA package, the FDA would kick it back with questions about their IUV process; and because it was new to them…things went downhill rapidly.  When they responded to the FDA with answers to their questions, they got many of them wrong, so the FDA response would include even more questions for them to answer, with requests for more clarification.

The list of questions was growing with every submittal, and the submittal timeline was stretching out as well.  Due to the increasing time & costs involved, their management halted the process & reached out to us for help.

Here’s what we showed them.

When you build a software application to support product development, you’re required to show evidence of verification and validation – which is the same process as if you were building a software application to sell to your customers.

We started with a gap assessment of their QMS to see if it properly reflected validation of ‘non-product’ software applications, plus any IUV documentation they may have.

To shorten this story, we were able to bring their QMS into compliance, including an IUV Plan, (requisite requirements encapsulating user needs, test plan, test protocols, final report) reflecting both verification & validation activities, which allowed them to send a fully accurate and complete BLA package that was accepted by the FDA.

For in-house built software applications – what goes into a fully compliant IUV program?

The image below is ideal for displaying all the required verification and validation activities for your in-house built (non-product) software application.  It’s pretty straight forward and easy to follow – which is what the FDA will look for during your submittal or audit phase. The easier you make it for the FDA to review, the more successful your engagement will be.

Non-Product Intended Use Validation Workflow

Additionally, as promised, here’s a little extra…

• Templates supporting complete documentation
• Integrated Risk Identification and Assessment
• Implementation of ‘Best Practices’ identified in GAMP 5, ISO 14971, ICH Q9
• Accurate ‘Level of Effort’ planning based upon identified risks

Does Advantu simply provide guidance, or will you roll up your sleeves and do the work for your clients?

Advantu’s experts can, in short order, assess your QMS (with regards to IUV), and provide guidance which includes corrective actions to bring your company’s QMS into compliance, with a fully auditable IUV program included.

Typically, our clients are short on time, so we usually perform all the tasks ourselves, which provides maximum customer confidence in the end result. Their submittal is accepted and they pass any FDA/MDSAP/EU Certification Audit they’re facing.

What if I want more detailed information about the IUV Process?

That’s a great question and it comes up a lot.

We recommend hopping on a call with one of our IUV experts, share your concerns and collaboratively we can take care of your software tool validation tasks from strat to finish.

Let’s put all those IUV tasks behind you.

Scroll down and send us a note – tell us you want to talk to an IUV expert today!