Webinar Duration: 60 minutes

RECORDED: Access recorded version only for one participant; unlimited viewing for 6 months (Access information will be emailed 24 hours after the completion of payment)

SPEAKER: Thomas Bento

OVERVIEW:
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:
– NPS Validation Planning
– NPSV Misconceptions
– NPSV Program
– New NPSV Paradigm (Out of the Box)
– IOPQ Best Practices

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

SPEAKER PROFILE:
Thomas is a student of Quality and Regulatory Compliance and has been supporting the design, development and compliance of Medical Device Manufacturing for close to 15 years. He started his career training in Software engineering and shortly moved into Commercial Software Quality. After many years of working for companies like Mitek Systems and Hewlett Packard, the decision was made to work in the regulated space of Medical Device Manufacturing, working at Edwards, Pulmonetic Systems and as a regulatory consultant for small, medium and large Medical device manufactures.

He is currently working as the Sr. Vice President of Quality & Regulatory Assurance at Nihon kohden America, manufacturers of Patient Monitors, Neurological and Cardiovascular devices.

Through his experience he has found that most Medical Device Manufactures feel that more is better to meeting regulatory expectations. He finds that this is the exact opposite and that manufacturers are better off by cultivating a simplified defensible approach to regulatory compliance.