Simplify & Manage your Intended Use Validation Program with Ease…
If you are a regulatory or quality engineering leader, and you’re facing a submittal, an audit…or both…this information is for you.
In our experience, intended use validation (IUV) of non-product software application tools is a very simple process; but because it isn’t often discussed in the mainstream it can be misunderstood, put off or simply forgotten.
We want you to know, we can provide guidance for those who wish to do the work themselves – and if you are swamped, we will take care of everything for you. 🙂
Yes, this is a simple process, but if you aren’t experienced with this process (especially the pitfalls) then it will become extremely time consuming and cumbersome for you and your team. Especially if folks confuse product validation with non-product validation – which happens a lot!
We want to take away all the pain and misery associated with IUV, by helping you put your QMS into compliance – which will feed directly into your ongoing process improvement program as well.
What is IUV?
Per the FDA, here is the applicability definition:
- 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)
- Software used in implementation of the device manufacturer’s quality system (e.g., software that records and maintains quality management system records)
What it means to you.
If you are a regulatory/quality leader, working for a biotech, biopharma/pharma or medical device company…intended use validation is very important to your success with regulatory agencies.
If your QMS isn’t fully compliant (with respect to IUV) and if your documentation isn’t accurate or complete – then your next submittal/audit will be very painful.
The good news – we can help you assess, mitigate and bring your intended use validation program into compliance in a relatively short period of time.
Who does this apply to?
If you are developing a drug, building a medical device or instrument – and you utilize any written procedures, hardware or software application(s) to support the design or manufacturing processes for your customer facing product – then they require intended use validation, per the FDA. {21 CFR 820.70(i)}
Whether you utilize a commercial off the shelf product (such as Excel or any spreadsheet program) or you build one yourself (in house developed software application to capture defects, for example) then, each software application requires its own process for intended use validation.
How it works.
It’s all about intended use. In other words, how you intend to use the software application to support your product development and/or manufacturing phases.
If you’ve purchased a commercial-off-the-shelf (COTS) software application, (like Excel), then the process has fewer moving parts.
A COTS software application has already been fully verified and validated by the manufacturer, before it was publicly available, so it isn’t necessary for you to repeat that process. Unless you customize the COTS software application; all customization needs to be validated.
I’m dramatically reducing the level of effort for illustration purposes here.
Your work here is much simpler; you only need to determine how you’re going to use the software, which is defined as intended use.
Assuming your QMS is compliant, (with your SOP defining your IUV process), then it’s just a matter of creating your IUV documents, or updating existing ones.
- First, Create an IUV Plan.
- Second, determine the intended use of the COTS software application. (user needs)
- Third, convert the user needs into requirements.
- Fourth, create test protocols to validate the requirements and verify risk mitigations
- Fifth, trace all the protocols to the requirements
- Sixth, execute test protocols until all have passed
- Seventh, generate a test report
Completed!
As I stated, that is an over simplification of the process for COTS software applications (tools), because I want to illustrate the process.
For home-built software applications (tools) the process is more expanded, because software verification comes into play.
To save time, the verification phase for a home-built software application is required, (similar to verification phase in product SDLC), in addition to the validation phase – and when both are properly documented and executed, your life is much easier because that’s what the FDA wants to see.
What if I don’t have the resources (people or time) to update or implement an IUV program for my company?
That’s a great question, and we hear it all the time.
Advantu has supported multiple biotech, biopharma and medical device companies for their IUV needs, and for 95% of them we performed all the work ourselves.
Our clients have enjoyed having their submittals accepted, plus – they’ve passed audits for MDSAP and CE certification.
All due to the skill, experience and dedication of our Regulatory and Quality Process Experts.
If you are experiencing an IUV challenge, or you have questions regarding various parameters – please let us know!
