Don't Validate That Software! Part II

NOTE: This discussion is a continuation of Monday's post by Jeff Boatman - CQA and Sr. Subject Matter Expert, QPharma. To read the 1st part of this post, please click here.

INTEGRAL SOFTWARE

Suppose I have three autoclaves. They’re used to sterilize final product for human implantation: major potential for serious health consequences (and remember, you don’t get to say “it doesn’t matter because we wind up testing our product”—it matters). All three of these autoclaves use software.

The first one has a separate PC connected to it, and the software resides on that computer’s hard drive, interfacing with the autoclave through a serial port. The PC is a general-purpose computer that can interface with a number of different autoclave models, and allows the user to set up specialized cycle profiles and alarms. Does that software need to be validated? You bet!

The second one sounds different, but in most ways, it’s not. That autoclave has a computer built right into it, running software with a user interface that permits customized cycles and alarms. Now there is indeed a difference: it is not designed to be disconnected from one autoclave and hooked up to another. Clearly there is some amount of scale-down that is appropriate in not needing to check that the computer can be reliably moved from one autoclave to another. But the core expectations remain the same: not only does the software, as it is configured right now, run the autoclave in such a way that it consistently works (OQ = correct temperature/pressure/cycle profiles, PQ = actually sterilizing loads); it also must demonstrably provide confidence that a range of different parameters and program sequencing will be reliably translated into actual machine operation and that those profiles are consistently implemented. That’s a qualification that goes beyond simply how the machine itself operates: it is software validation. We may have used a risk assessment to scale down the amount of testing needed, but there is definitely a separate software aspect to this.

Now consider the third example. This autoclave is computerized, but the software is programmed for one specific cycle profile; it is not customizable. There are a couple of ways this could be done: the autoclave could truly be a one-trick pony, with the computer no more customizable than a four-function calculator; or more and more commonly, the software is customizable, but the manufacturer has decided that the configuration will be “locked down” and never changed, at least not outside formal change control (which includes, of course, a process for evaluating changes for the need to perform re-validation).

I contend that in this last example, the whole concept of “software validation” goes out the window. If indeed the system has any potential for changing settings and parameters, then certainly you must both explain the measures used to preclude anyone from making unauthorized and unvalidated changes, and then demonstrate the effectiveness of those controls; and if the autoclave electronically captures or transmits any digital records that are used for GxP purposes, then validation for Part 11 may still apply. Those could include actual cycle monitoring records, any data input by users such as batch identification, or confirming the identity of authorized users.

But provided you have covered these Part 11 items, there is no regulatory obligation to...

Don't Validate that Software!

Written by Jeff Boatman - CQA and Sr. Subject Matter Expert, QPharma

BACKGROUND

General software validation became an official part of U.S. regulated Life Sciences in 1996 with the finalization of the Quality System Regulation. Contained within that Rule is 21 CFR 820.70(i), which states when computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol. It is important to note that while Part 820 is a Medical Device regulation, another section [21 CFR 820.1(b)] gives FDA the authority to apply this requirement to other companies as well.

Prior to this, there was no specific regulation dealing with software validation; the closest was 21 CFR 211.68, which since 1964 has stated that if a manufacturer uses an automated system to produce a drug product, it shall be routinely calibrated, inspected, or checked according to a written program designed to assure proper performance. Bear in mind that computers were practically a novelty when that Rule was finalized, and modern validation practices were only beginning to emerge; the first software inspectional guidance wasn’t issued until 1983.

In 1997, FDA followed up with 21 CFR 11, which states that systems that create, store, process, or transmit electronic records used to satisfy regulations must include validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records [21 CFR 11.10(a)].  Shortly after, the Center for Devices and Radiological Health published Guidance for Industry: General Principles of Software Validation, which has since gone through several draft and Final revisions. While that guidance is from FDA’s Medical Device division and does include sections on the validation of software which is, or is used within, a Medical Device, it also has broad applicability to other Life Science firms as well.

The broad applicability of 21 CFR 820.70(i), the virtually universal applicability of Part 11, and the adoption of the standards in FDA’s software validation guidance make it clear that FDA has very high demands for software validation at Life Science firms, and indeed consulting firms like QPharma rely upon FDA’s comprehensive expectations to stay in business. It must be obvious to the reader that the problem that we see most often is too little software validation, too poor software validation, and too poorly executed software validation. Further complicating this is the latest move by CDRH to vastly increase the scope of what FDA considers to be "Medical Device Software" into areas that traditionally have been considered outside CDRH’s (and even FDA’s) jurisdiction.

THE USUAL...AND THE UNUSUAL

When we do audits, our comments are usually: you need to validate this...you forgot to validate that...you didn’t consider this. But once in a while, our comment is: why did you validate that?

Let’s hit some of the basics.  First, you need a Traceability Matrix (TMX), which shows all of your requirements, all of your testing planned (and performed), and linking them together. Traceability of requirements to testing is always a good idea, but for software validation, it’s mandatory: the FDA guidance mentions it repeatedly.  The most important purpose of a TMX is to ensure that every requirement actually gets validated or otherwise verified. But it also goes the other way: if you are testing something and it is not traceable back to a requirement, then why are you testing it?

Another low-hanging fruit is risk assessment. If you take the validation requirements of 21 CFR 11.10(a) and 820.70(i) literally, you’ll probably never manage to make any product for sale: all you will ever do is validate, validate, validate. (As an example, if you literally accept 820.70(i)’s obligation to validate all software changes prior to implementation, can you imagine the potential implications for daily antivirus definitions and Microsoft Windows patches?) In both its software validation guidance and the 2003 Guidance for Industry: Part 11, Electronic Records; Electronic Signatures – Scope and Application, FDA has been putting increasing emphasis on doing risk assessments of systems to determine exactly what truly needs to be validated. In particular, the Part 11 guidance offers companies the possibility of exempting broad swaths of functionality from validation provided that you can back that up with documented risk assessments. FDA may object to lesser validation based on a risk assessment they disagree with, but they will object to lesser validation without a written risk assessment at all.

In both of these examples—validation of functions that aren’t required, and validation of functions that a risk assessment could have exempted—we would caution our client that they are going overboard and that their validation dollars are better spent elsewhere. But how about software that runs a manufacturing process, and that process (and therefore that software) really does have a significant impact upon product quality, and even public health?

More on this topic and the answer this Wednesday, September 29th!

Live Informative Sessions - Join Us!

The experts at QPharma will be giving some presentations towards the end of the year - and we want you to join us! We hope you have found our blog to be informative, interesting, and at times, entertaining. Come meet the subject matter experts who write our articles at the following venues:

October 24-27: 2010 RAPS Annual Meeting - San Jose, California

Come join Nancy Tomoney at our Sponsor Spotlight Session on Monday, October 25th! Nancy will be giving an informative learning session on:

Current Events Impacting FDA Registration and Sale for Products Marketing Through CDRH, CDER, CBER and CVM. 

QPharma is also giving away a Flip Video Camcorder - just stop by our Booth #525 and enter for your chance to win!

October 25-27: IVT'S Validation Week - Philadelphia, PA

Session 4, Day 2 - Tuesday October 26th Gregg Mauriello and Elise Miner are headed to Philadelphia, PA to give their talk on: Best Practices for Validation of a Software as a Service (SaaS) Customer Relationship Management (CRM) Solution. One of our most popular blog posts, this duo will be answering your questions on this process and addressing your most pressing concerns when it comes to validation "in the cloud".

Check out the description of their Session Track here (scroll to "Session 4").

November 7-10: ISPE 2010 Annual Meeting - Orlando, FL  

Nancy will be joined by Kim Stanton, another of QPharma's Validation Managers, at ISPE's meeting in Orlando this year. Our experts will be giving the following presentations on November 8th, 7:00 AM - 8:00 AM on Stage 2:

- Case Study in Good Laboratory Control Practices - Applying GAMP, Calibration Management, Good Laboratory Control and Good Engineering Practices for a Successful Move. 

Talk will detail the tasks, checklists, and activities used to relocate an Analytical Laboratory from one operating site location to another.  

- Applying Best Practices using Validation Test Management Tools for Validating Computer Systems.

Presentation will detail the efficiencies of Test Management Tools and how to apply best practices to Test Management tools to meet regulatory standards for Validation deliverables.

Visit us at our Booth #415 to talk to our Subject Matter Experts!

We hope to see you there!

Test Management Tools - What Are They & Why You Need Them

Written by Kim Stanton, Associate Validation Manager at QPharma

As anyone that has been involved in a Validation effort can attest to, the old Validation Standards of requirements/system design documentation, over-testing, paper based script development and execution can be burdensome, resource/budget intensive and time consuming. This is making Pharmaceutical, Biopharmaceutical and Medical Device companies search for Test Management Tools that will streamline their validation efforts.

Computer System Validation (CSV) Test Management Tools manage the validation process by providing the ability to gather requirements, conduct risk assessments, create test plans, execute scripts manually or automatically, manage deviations and create summary reports.

Since many Test Management Tools are web-based they have the ability to centralize a company’s validation processes, allowing for resources from various locations to be involved in all aspects of validation efforts without the need for travel budgets and travel resource downtime. Execution times are greatly reduced since testers do not have to transcribe pages of test results, attachments and deviations. Also, multiple testers can execute simultaneously (unless there are script dependencies) since all activities are performed in the Test Management Tool. In addition to streamlining the execution process, the following steps are greatly improved using Test Management Tools: traceability of requirements to testing, attachments to test steps and deviation to test steps.

No matter which Test Management Tools are used to manage a company’s validation processes there could be a number of issues that will need to be addressed during the implementation of a Test Tool. Moving from a paper-based test management process to a system-based process requires changes in current procedures and resource training.

Many Test Management Tools have the ability to configure Workflows. Workflows are critical for controlling the validation process, from requirements documentation to summary report close out. Workflows ensure consistency for each validation effort managed by the Test Management tool no matter what type of application is being validated, what department of the company is conducting the validation, or what location of the company is performing the validation. A controlled workflow ensures compliance with the companies Standard Operating Procedures (SOPs) and regulatory guidelines. If workflow configuration is not available in the chosen Test Management Tool, a SOP for workflow management/operation must be documented and approved.

The Test Management Tools selected should be compliant with 21 CFR Part 11 requirements, which includes:

• The Test Tool must only be accessible by personnel with a valid user account.

• A well defined Approval process (see above) must be implemented.

• Electronic signatures should be configured.

• Audit trails to capture creation and changes to all validation deliverables including the executed scripts must be implemented.

All personnel involved in Validation processes must be educated and trained on the Test Management Tool to include Quality Assurance personnel. This will ensure that resources that perform validation activities will realize the benefits of the Tool, ensuring that it will be used in a compliant manner.

Since the Test Management Tool will be configured by both Regulatory and Business requirements, the System Development Life Cycle (SDLC) of the tool will need to be managed to include support, tool-specific SOP documentation and validation of the tool.

 

For more information on QPharma's validation services, please email us at info@qpharmacorp.com, or give us a call: 888-742-7620 and ask for Rob Finamore to discuss your needs!

FDA Announces Plans to Revise cGMP Regulations for Auditing Vendors

Written by Teresa Jaworski – Senior Validation Specialist at QPharma

By year end 2010, FDA is planning to release new regulations that will include requirements for Pharmaceutical manufacturers to physically audit their vendors, no longer allowing paper audits to be acceptable. This change is being considered because of the large number of gaps being found in manufacturers’ quality systems due in part to the growth of production outsourcing. It is expected that once the drafting process of these proposed regulations is completed, they will be available for review and comments for approximately three to six months.

Brian Hasselbalch

According to Brian Hasselbalch, representing the Office of Compliance’s Division for Manufacturing and Drug Product Quality within FDA’s Center for Drug Evaluation and Research, at a conference held jointly by the agency and Xavier University in Cincinnati, Ohio, June 13-16, “between 2001 and 2007, the number of products manufactured outside the United States and the number of manufacturing sites abroad doubled. Some of the new products being imported into the US come from countries with less developed regulatory systems.”

As indicated in the U.S. Food and Drug Administration (FDA) Guidance for Industry Q10 Pharmaceutical Quality System, which is in accordance with 21 CFR Part 820.50, Pharmaceutical companies are ultimately responsible for ensuring that processes are in place to assure the control of outsourced activities and quality. In doing so, companies should implement processes to access the suitability and competence of a vendor prior to outsourcing operations or selecting them as a vendor. This can be accomplished by establishing approved procedures, performing audits, and ensuring qualifications. Note that defined quality requirements should be used during the auditing process to ensure the vendor is capable of meeting these requirements. The evaluation results should be documented.

If it is determined that the vendor is qualified, an approved, written agreement, often referred to as a Quality Agreement, that defines quality requirements, responsibilities, and communications necessary for quality-related activities, should be created and approved between the two parties. Records of acceptable vendors should be established and maintained via an Approved Vendor List.

If a company does not have an Approved Vendor List, it cannot be concluded that vendors being used by the company are qualified to provide the products and services being used for cGxP purposes. With the establishment of an Approved Vendor List, a company can work smarter, not harder. A company will be able to determine if a qualified vendor is currently available that can provide the necessary products or services instead of going through the entire qualification process each time a new vendor is needed. It also ensures that several vendors are not being used for identical products or services. In the end, this will result in better utilization of resources, an improved state of regulatory compliance, and a cost reduction for the company.

However, having these procedures in place does not ensure proper implementation of them. Training should be conducted and documented on these approved procedures, emphasizing the need for quality in all aspects of the vendor qualification process including ensuring that all required vendor assessment and auditing documentation is stored in a centralized, secure location.

A vendor audit does not have to be conducted by a company representative. It is acceptable to use contracted resources to perform these audits as long as the resources are qualified to perform the tasks and the qualifications are documented. According to Hasselbalch, “We will not demand that you individually audit. We acknowledge and recognize a surrogate or a third party audit arrangement. It may be more efficient and more effective, quite honestly. A third party audit would have to be performed by a credible auditing arm [with] certain characteristics that assure the integrity and the quality of the audits.”

Refer to the links below for FDA MedWatch reports relevant to outsourcing.

• http://www.fda.gov/Safety/MedWatch/SafetyInformation/SafetyAlertsforHumanMedicalProducts/ucm172252.htm
• http://www.fda.gov/Safety/MedWatch/SafetyInformation/SafetyAlertsforHumanMedicalProducts/ucm214036.htm
• http://www.fda.gov/Safety/MedWatch/SafetyInformation/SafetyAlertsforHumanMedicalProducts/ucm214034.htm
• http://www.fda.gov/Safety/MedWatch/SafetyInformation/SafetyAlertsforHumanMedicalProducts/ucm213532.htm