Top 5 Software Tool Validation Challenges
Facing validation of (non-product) software applications? This article is for you!
Our clients have faced push back from the FDA during submissions, during audits and while attempting certification for the CE label – these are the challenges they faced.
And Yes, we’re talking about intended use validation (IUV) of non-product software applications – or tools.
I’m going to start with the most unique issues, explain what the blocking issues were and continue through to the most prevalent challenges medtech/biotech/pharma companies face.
Here’s one of the most common. “We’ve never validated software tools before – we don’t even know what IUV means – so how do we get started?”
First, IUV is the acronym for intended use validation, and it means – validation of non-product software applications for their intended use; which means, validating how you’re going to use them during R&D or Mfg phases, and it’s important to get this part right.
Second, the Advantu team has years of experience in guiding our customers through developing a tailored procedure (and all the required templates) necessary to ring your quality system into full compliane for IUV, as well as other gaps you may have.
Here’s a great question: “How do we know if our software tools need to be validated?”
I would say this is almost the most popular question we’re asked – and here’s the straight answer: “It depends”.
Because there are two core areas for software tool validation for any medical device, biotech or pharmaceutical company – research & development, and, manufacturing.
Any supporting technology utilized during those phases will require intended use validation; however, the level of validation is determined during the risk analysis and user needs assessment phases. Some software applications require more validation than others, and our experienced IUV experts know how to determine the level of effort required for each tool.
For example: if an excel spreadsheet was used to keep trial data, but no calculations were involved, then a minor level of validation will be required, per the FDA.
As another example: if an engineering team (building a medical device) was utilizing JIRA with multiple modules, it could take up to a month to fullly validate this system properly.
This is why it’s so important to have experienced help with this process.
You could spend alot of hours doing this work – only to have the FDA pushback (on something our team member would know) and cost your company alot of time and money.
This is always a fun one: “What do we do if we’ve already used a software tool within our organization that has not yet been validated?”
It actually depends upon a couple of things.
First, how long until your 510(k) submittal, and second – what was the tool used for?
In the end, Yes we can help you in Four Parts:
- Begin with a gap assessment of your QMS/IUV processses
- Review the report, collaborate on which recommended corrective actions you desire
- Work with your team to actively implement the corrective actions
- Bring your organization’s IUV program into full FDA compliance
At the end of the day, we’re experienced with this scenario and if we take care of it in time – it need not derail your submission. 😎
I too faced this same question, when working as a SQE Lead on a project, and I was tasked with performing validation on a software system being built by the medical device manufacturer.
“Our organization has built (coded) its own software tools – is the IUV process different, compared to off-the-shelf applications?”
Intended Use Validation for software tools built in-house requre a more in-depth approach, when compared to off-the-shelf tools. For example, since the medical device manufacturer made their own software tool, the FDA requires both Verification of the software (make sure you built what you said you would build), and, Validation of the software (make sure it meets user needs), and getting all of the documentation correct, is your proof that you are fully compliant.
This challenge is one of the EASIEST to mess up!
One of the first companies to call us for support, because they were stuck in a costly submittal push back holding pattern with the FDA, was due to software tool validation for an application the organization built themselves. They didn’t have much software or tool validation experience, which meant their FDA interactions caused them almost a year’s delay.
After Advantu’s team took over the project, we performed all the tasks, wrote up the report – updated their submittal package – and it was accepted by the FDA. Yes, they are one of our happy testimonials…and a repeat client, due to our FDA expertise.
Since we support alot of startups, here’s the first question we hear: “This seems like something we can perform ourselves – why should we engage an outside firm?”
The first answer is always Time.
How much time do you have to complete the project, before IUV becomes a blocking issue for your product release date?
Many organizations are fully capable of performing IUVs on their own, however, we recognize this isn’t a core competency for most teams – so any mistakes being made could potentially delay the product release until they’re sorted out.
Often times, since most teams only perform software tool validation occasionally, (not on a regular basis), they may not be aware of any FDA regulations that could negatively impact their timeline – such as, knowing the difference between verification & validation for a custom (in house) developed software tool. If your team makes a critical documentation or process mistake, you won’t know about it until the FDA auditors kick back your Submittal (or fail your audit) months later – and then you lose half a year to respond accordingly.
At Advantu, we’ve been performing software tool validation since our company launched in 2014, and we have a list of happy clients with successful IUV projects to prove it.
The reason is simple: if you utilize an experienced team (with a proven track record of successful IUV projects) then you can rest assured that you’ll meet your deadline, because we’re known for on-time deliveries.