Since 1986 - Covering the Fastest Computers in the World and the People Who Run Them

Language Flags
April 26, 2010

Negotiating IT in the FDA Regulatory Environment

Bruce Maches

All life science, food product, and cosmetic companies in the US must operate under the regulatory framework put forth by the Food & Drug Administration. In my first blog entry I briefly touched upon the subject of FDA regulatory compliance. This blog entry will dive deeper into this topic to give you a much clearer understanding of the regulatory environment that life sciences companies must labor under and what the IT groups in those organizations must deal with from a compliance standpoint. I will then discuss how this impacts the advance of cloud computing in life science companies along with some examples of current uses in my next entry.

Every life science company, whether bio-tech, big pharma or medical device, must navigate a complex sea of regulations, recommended practices and government mandates as part of their normal business activities. This can include SOX (for public companies) HIPPA2 (patient privacy for electronic records) and numerous FDA regulatory guidelines. All life science companies have some sort of internal regulatory affairs function that ensures FDA compliance across the entire organization focusing on research/laboratory practices, manufacturing processes, clinical trials, and the IT organization. The primary driver for IT regulatory practices that I will focus on is CFR 21 Part 11. One clarifying comment, the FDA, like many other regulatory bodies does not issue standards; instead it provides guidelines on what must be done to be considered compliant but not on the execution of how it is accomplished.

In a nutshell the Code for Federal Regulations 21 Part 11 defines how life science companies implement system controls, including audits, validation & verification processes, electronic signatures, and documentation for software and systems involved in processing electronic records. This primarily applies to systems dealing with research, drug development, manufacturing, clinical trials, regulatory submissions but not common systems such as the companies financial or HR applications. Part 11 compliance is done through an intensive validation process involving three primary steps which I will describe shortly. All of this effort is to ensure that processing activity and electronic records for a particular system are accurate and can be trusted. In addition the overall IT compliance environment includes the system support and maintenance procedures along with verifying that the personnel managing the system have the requisite skills and training to properly do so.

The key word here is trust – if I am an FDA auditor how do I know I can trust the operation and output of a particular system? Keep in mind that if you cannot prove something then to an auditor is did not happen. The actual Part 11 compliance process for any application includes the hardware, software and operational environment for the system itself. This allows an IT group to answer the questions:

Can I prove the system was installed correctly?

Can I prove the system is operating correctly?

Can I prove the system is performing correctly to meet the stated user requirements?

To prove these three things the system validation process has three primary components, the Installation Qualification (IQ), the Operational Qualification (OQ) and the Performance Qualification (PQ) scripts. These are extremely detailed documents laying out the individual steps involved in performing these three tasks. Each step has an expected outcome (i.e. click on OK and the dialog box disappears) which must be handwritten in, each line item initialed and every page signed. To give you an idea on how lengthy this process can be I recently installed an off the shelf document management package with no customization for a bio-tech client. The IQ document was a 1 inch stack of paper, the OQ filled two 3 inch binders, and the PQ was 2 inches of paper. I know this sounds quite exhausting but it is the process by which an auditor can be assured that the work was correctly done per spec. Any issues encountered during the execution of the scripts must be documented as deviations and then resolved with supporting information. In performing the IQ script, one of the standard pieces of information recorded is the model, type, configuration, and serial number of the computer on which the software is being installed which may not be applicable in a cloud computing environment.

I hope I haven’t bored you with all of the details but I wanted to give you more background on the environment in which FDA regulated companies must exist.

So the big question is how does this impact the acceptance of cloud computing based applications in life science companies? In my next blog entry I will discuss some of these questions:

How does the FDA currently view the use of cloud technologies?

Does the use of private vs. public cloud services affect Part 11 compliance?

Does the type of cloud service (IaaS, PaaS, and SaaS) being used impact the validation process?

What current examples are there of life science companies using cloud technologies?

How can cloud help life science companies deal with their inventory of legacy validated systems?