Advantu

Top 5 Challenges with Intended Use Validation (IUV) for Medical Devices & Software Applications

by · Published · Updated

Why does it always take longer than expected, and who’s supposed to execute…?

We conducted a survey of Biotech Industry Engineering Executives, and we asked them to list the Top 5 Challenges they’ve faced with Intended Use Validation (IUV) projects – here’s their amazing feedback:

Top 5 Challenges with IUV

  1. Being provided the time & manpower to perform those tasks that are NOT directly related to testing the product.
  2. Making sure that the user requirements are correct & complete. If you go too far, then you are doing a validation of the 3rd party app. If you don’t have correct user requirements, then your validation is not accurately covering your intended use.
  3. Having a SME who can write the requirements, and someone to execute the protocol & then write the report.
  4. Knowing when a validation is required and when it is not.
  5. Understanding the difference between COTS tool validations, and internally developed tool validations.

Before we dive in, I have a few easy questions:

Are you the Director of Quality at a medical device company where your team utilizes a software application(s) during the process of building a medical device?

Are you the SQE or Quality Manager or Lead who’s been tasked with executing this IUV project?

Fun question: do you have engineers who haven’t executed an IUV project before?

I remember being an SQE Lead on a large project (marrying a fleet of medical devices to a large nurse-facing hospital system) which required the use of 2 New Tools for testing, one was a COTS tool (JMeter) and the other was being built in-house.

I was tasked with performing two IUV project(s) simultaneously, so our test team wouldn’t be negatively impacted by the additional workload.  I had never performed an IUV before and I had no idea what was involved. Ultimately, I was handed a set of documentation (previously conducted IUV plans) and off I went.

As painful as each IUV project was, I’m grateful today for being forced to learn the process so we can pay it forward.

Now let’s cut to the chase & take a few minutes to explain IUV and the impact to your project.

Why is IUV necessary and where is it applied?

Here’s the short answer; the FDA (section 6.3 of the FDA Guidance on General Principles of Software Validation) states that “off-the-shelf software development tools, such as software compilers, linkers, editors, and operating systems” are required to have intended use validation performed.

The format of the required documentation is detailed in the Off The Shelf Software Use in Medical Devices guideline document. Section 2.1 has the questions that the OTS software BASIC DOCUMENTATION needs to answer.

  1. What is it?
  2. What are the Computer System Specifications for the OTS Software?
  3. How will you assure appropriate actions are taken by the End User?
  4. What does the OTS Software do?
  5. How do you know it works?
  6. How long will you keep track of (control) the OTS Software?

When we state OTS, we are also referring to COTS – Commercial Off The Shelf software. The commercial aspect means it’s a commercially released software application that you can buy from a real company that utilized design controls and quality systems, which can be easily determined.

A typical COTS IUV project can take 2-3 weeks’ time, depending upon the complexity – but for in house built tools, it can take 3-6 months due to scope creep and feature changes.  (I’ve lived that pain)

In the end, regardless of the COTS application’s list of features – as long as specifically needed functionality (for your project) is built in and can be validated, that’s all you care about.

For today’s article we will respond to the First Challenge above, and the remaining Challenges will be addressed in future blog articles.

If you’ve never performed an IUV project, this challenge will be an eye opener.

First Top Challenge with IUV

“Being provided the time & manpower to do these tasks that are NOT directly related to testing the product.”

  1. Here’s what a typical IUV Project Scope and Validation Plan look like
  2. IUV Project Scope
    • This work instruction applies to software products that are acquired from a 3rd party or developed in house and focuses on the areas referenced by the General Principles of Software Validation (GPSV) that relate to product development. Examples include:
    • Unit test tools for product code testing
    • Product test automation software and systems
    • Computerized emulators & simulators used to automate product design or product testing
    • Product related network monitoring tools
    • Product related health and/or performance monitoring tools which do not impact or modify the functionality of the product
    • Troubleshooting of commercial products – support applications (e.g., tools to troubleshoot network switches, connectivity issues, etc.)
    • Tools for viewing and/or manipulating data within a proprietary database deployed with a product for one-time data correction purposes only. (e.g., database data corruption due to unforeseen customer data changes, business objects database viewer, etc.)
    • Manufacturing test fixtures with a software component
    • Product support software used during deployment to customer sites for the purpose of Installation Qualification (IQ), Operational Qualification (OQ) and or Performance Qualification (PQ), and may include; automation of product installation, manipulation or reporting on data resident in commercial products (e.g., conversion tools for migrating data during an upgrade), monitoring product operation without intervention to correct the problem.
  3. IUV Plan
    • Purpose of Document
    • Definitions, Acronyms and Abbreviations
    • References
    • Description of Software
    • Intended use(s), Intended Use Environment(s), Intended User(s)
    • Risk Management
    • Software Requirements
    • Configuration Management
    • Software Validation Approach
      • Test Strategy
      • Validation Tests Prior to Execution
      • Regression Testing
      • Test Case Environment
      • Tools & Resources Needed
      • Acceptance Criteria
    • Installation Qualification
    • Training
    • Maintenance
    • Appendix – Test Case Template
    • Review and approve IUV Validation Plan
    • Create Validation Tests (Test Cases or Protocols)
    • Review and Approve Tests
    • Test Execution and Validation Report
      • Test Execution
      • Create Test Report
    • Make software tool available to intended users
    • Maintenance

As you can tell, the IUV process is extremely time consuming, and typically – unless a medical device manufacturer has an established IUV team – this burden is absorbed by the SQE team already performing product testing.

I realize this sounds onerous…especially since the IUV process is FDA mandated & it can’t be avoided.

The good news – if you work with experienced Engineers who’ve executed numerous IUV projects before, it doesn’t have to be a serious negative impact to your project or schedule.

Be sure to look for the next IUV Blog Series Article where we respond to Challenge 2:

“Making sure that the user requirements are correct & complete. If you go too far, then you are doing a validation of the 3rd party app. If you don’t have correct user requirements, then your validation is not accurately covering your intended use.”

If you are about to start an IUV project, or you’re currently experiencing challenges – be sure to reach out and request a free IUV consultation.

Our Validation Engineers are available to support your current or upcoming intended use validation project.

We know IUV!

Share

You may also like...