The Validation of Non Product Software
03:00 PM ET | 12:00 PM PT | 02:00 PM CT Duration 60 Minutes
Webinar Includes : All the training handouts , certificate ,Q/A and 60 mins Live Webinar
"Thomas Bento is a student of Quality and Regulatory Compliance"
How to comply with 21 CFR Part 820.70(i) and effectively implement a software validation
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 and inspection risk 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 Seminar will explore other Risk based methods for satisfying the QSR requirement and regulatory expectations
This course will teach how to comply with 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 as 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
Who will Benefit
- 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
Industries who can attend
This 60-minute online course is intended for professionals in the Medical Device, Biotechnology,Pharmaceutical Industry. Although not presently stated in the draft , the same guide could be used by FDA Regulated Industries personnel.