Posts
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!
