Validation of Non-Product Software
In this webinar We will explain the role of Risk Management in Non-Product Validation, understanding how to avoid major mistakes when validating software to FDA standards, This webinar will review the validation planning process with emphasis on avoiding common pitfalls, The attendee should leave the presentation confident in their ability to improve the level of validation success.
More Trainings by this Expert
This course will teach how to comply to 21 CFR Part 820.70(i) and effectively implement a software validation program for medical devices, meeting the FDA requirements and produce a safe product. We will explain the role of Risk Management in Non-Product Validation. How software requirements are used in validation will be described.
21 CFR 820.70(i) requires validation of software that automates all or part of any process that is part of the quality system. That software includes the following:
- Software used as part of the manufacturing process (including software embedded in machine tools, statistical process control software, programmable logic controllers [PLCs], and software in automated inspection or test systems)
- Software used in process validation (such as statistical calculation software, spreadsheets, etc.)
- Software used in design and development processes (such as CAD software, CAM software, software development tools, software test tools, compilers, editors, code generators, etc.)
- Software used to automate part of the quality process (such as complaint-handling systems, lot-tracking systems, training-database systems, etc.)
- Software used to create, transmit, modify, or store electronic records that are required by regulation
- Software used to implement electronic signatures for documents required by regulation
If a Medical device manufacturer is using software to automate a process that is required by FDA, it is essential to show that the software accurately, reliably, and consistently meets the requirements for its intended use.
Does that mean you need to do it simply because FDA says so? At the simplest level, yes. But why is FDA so interested in how software works? FDA isn't so interested in the software itself as it is in the processes that the software is automating. FDA wants to be sure those processes are accurate, reliable, and consistent.
If software validation reduces the risk of a failure that could ultimately result in patient harm or jeopardize the integrity of other quality systems, then why not require software validation to reduce the risk of other, nonregulated functions? Wouldn't it be nice to reduce the risk of software failure that could disable your company's e-mail for a week, or shut down a production line for hours at a time, or delay deliveries of raw materials, or lose track of accounts receivable? Shouldn't the company be as concerned about these functions as FDA is about those that are regulated?
The point is that software validation is not just a regulatory nuisance it is fast becoming a necessity for the device industry's increasingly software-controlled environments.
What Software Should Non-Software Engineers Validate?
Non-software engineers should be able to validate most software categorized as off-the-shelf or embedded. As its name implies, off-the-shelf software is purchased for a specific purpose, such as CAD software, compilers, or calibration tracking software.
For all but the simplest custom software (software written for a specific purpose that is unique to a company), validation should probably be left to software development and validation professionals. Spreadsheets, macros, batch files, and similar items created in house for specific purposes should all be treated like custom software, but those are usually small and simple enough that they can be validated by non-software engineers.
Many off-the-shelf software packages require custom software elements to do anything useful. There are also custom software systems that include some sub elements that are either off-the-shelf, custom developed internally, or custom developed externally. Non-software engineers can participate in the validation of these complex systems by focusing on the system-level validation for intended use, while leaving some of the more-technical verification testing activities for the software development and validation professionals.
Why should you Attend:
When used as intended, process validation can provide increased process reliability, confidence, improved yields, and reduced operating expenses significantly.
- Compliance to 21 CFR Part 820.70(i) Automated Process is required for Medical Device Manufacturers
- FDA inspectors are now being trained to evaluate software validation practices
- Increasing use of automated manufacturing and quality systems means increased exposure
- Most recalls can be traced back to computerized equipment, exposing the validation process to scrutiny
- Corporate uncertainty leads to inaction and 'wheel spinning'
- A third of recent warning letters included citations with respect to improper or ineffective validation
Many companies struggle with understanding how to avoid major mistakes when validating software to FDA standards. This webinar will review the validation planning process with emphasis on avoiding common pitfalls. The attendee should leave the presentation confident in their ability to improve the level of validation success.
Manufacturers that do not understand the options that are available for Process validation will usually follow an IOPQ Validation process. This is not required and may not be needed. This webinar will explore other Risk based methods for satisfying the QSR requirement.
Areas Covered in the Session:
Who Will Benefit:
- NPS Validation Planning
- NPSV Misconceptions
- NPSV Program
- New NPSV Paradigm (Out of the Box)
- IOPQ Best Practices
- Research & Development
- Quality Engineers and Auditors
- Manufacturing Engineers
- Quality Assurance & Quality Control Teams
- Operations Teams
- Document Control
- Device Development Teams
- Personnel involved in Verification and Validation
Planning, Execution and Documentation for Devices