Computer systems performing regulated operations shall be validated. Typical examples of such systems are
• Systems that control the quality of product during its development, manufacturing, testing and handling process.
• Systems that create, modify, maintain, archive, retrieve, or transmit data used to prove the safety, efficacy, and quality of product and formulations.
• Systems that provide information on which decisions are made affecting fitness for purpose of the product.
• Systems that create, modify, maintain, archive, retrieve, or transmit records that must be available for inspection by a regulatory agency.
• Systems that provide data or reports that are sent to regulatory agancies.
The dept and scope of the software depends on the category of the software, and the complexity and criticality of the application.
All Life Science companies these days would be wise to have a procedure/SOP called ‘Conducting a Compliance Assessment for GxP Systems’.
The report outputed from this (decision tree) should then drive the “project” down the correct path of what, and what you do not, validate. Also, what deliverables you would require to validate it should validation be required. Basically it becomes a matrix of deliverables, reviewers and approvers.
Note: In my experience, in the case of ‘Information Systems CSV’; the general rule for Life Science companies tends to be that they validate all Information Systems, with the exception of those that exist purely for financing and budgetary reasons.
I am in the process of validating an application server running a manufacturing system. Backup data is handled by another networked server, which stores backups onto its local tape drives by copying data over the network. Do I need to validate this server as well as my main application server?
What about other networked servers that handle tasks such as printing?
[quote=exmos42]Chandra,
I am in the process of validating an application server running a manufacturing system. [/quote]
First point, I always qualify my servers and then validate the software that runs on the server.
I would also qualify this server, and include a section in the qualification where data integrity is tested. i.e data on backup server is identical to the main application server
Check our server qualification document out see link below.
Let’s go back to the original question: What systems should be validated?
To address that question, we need to answer a different question first: Why should systems be validated? Because a regulator wants you to do it? Ok, that’s fine with me but a better answer would be to mitigate the risk that the system doesn’t perform as intended or doesn’t effectively address the need for that system upon its deployment. Or phrased a little differently: to ensure that the system consistently performs as intended and effectively addresses the need for that system. As far as non-regulated systems, it would be an educated business decision (risk/benefit/cost trade off) as to whether or not to validate a system and to what extent. My view is that all mission-critical systems (without the system the organization would not be able to fulfil its purpose) must be validated. As far as regulated systems, there are mandatory objectives to be achieved prior to deploying the system or putting the system into the market. A medical device for example, must be proven to be effective and safe when used/operated under specified conditions in the target use environment. To achieve that objective, the medical device regulations mandate manufacturers to perform specific activities and that basically comes down to validation. Depending on the applicable regulation, any non-regulated system that directly or indirectly can impact the quality of a regulated system may also be subject to validation.
Whether you operate in a regulated industry or not, good practice would be to document educated decisions (decision and reasoning based on risks and any applicable regulations) as to whether a system must be validated or not. Would the decision be to validate the system, this documentation should include the scope of validation (validation effort must be commensurate with the risks).
Stripped of all jargon, surely it makes good sense for any industry to:
know what it wants to get for its money and tell its supplier(s) that
check that the proposed supplier(s) are suitable (with respect to quality, financial stability etc etc)
check that what the supplier proposes to deliver actually matches what’s wanted
make sure that what is delivered is installed correctly and according to instructions
make sure that what is delivered functions as expcted, with no unintended consequences
make sure that when operated within a whole process structure, what is delivered is actually usable (as opposed to functioning) and reliable in use
Along the way, risks need to be identified, considered and managed appropriately.
Just common sense really in my view!
I personnally think that all computer systems of any kind, complexity, scope etc should go through that process - with the identification etc of risks driving much of the actual action.