We are asked the question all the time about how to execute the validation process to allow for the use of TFS into the production environment. When working with the regulatory departments of our clients we find that the effort involved for the validation project is too high. When we start measuring the duration of the project in many months then there more then likely too granular validation process being run. Below are some guidelines:
21 CFR820.70 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. All software changes shall be validated before approval and issuance. These validation activities and results shall be documented.
Ideally in order to validate an OTS Application Lifecycle Management (ALM) such as TFS established work instructions or protocols should be already in place for which the validation effort can be based upon and used as a reference for auditing purposes. In addition, it would be preferable to have access to validation data compiled by the manufacturer. In the case of TFS we do not have access to the validation data from Microsoft so section 6.3 of the FDA publication: “General Principles of Software Validation” state that:
Where necessary validation information is not available from the vendor, the device manufacturer will need to perform sufficient system level “black box” testing to establish that the software meets their “user needs and intended uses”
In addition 21 CFR820.70 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. All software changes shall be validated before approval and issuance. These validation activities and results shall be documented.
In the absence of such protocols (or partial coverage) the validation effort can be led by an industry expert to help establish such protocols and establish best practices of the use of the software as per the recommendation of the manufacturer.
As ALM and TFS experts we are well positioned to propose how best to use the system in your regulated environment. In addition, with our specialized knowledge of the use of TFS in FDA regulated environments we can help establish those bases SOP’s, lead the validation effort and train the users on the SOP’s and industry best practices.
The first question that must be resolved before proposing a validation plan for an OTS software package would be to establish the level of risk which will dictate the level of validation evidence that will be required. Section 6.1 of the FDA publication: “General Principles of Software Validation” states:
The level of validation effort should be commensurate with the risk posed by the automated operation. In addition to risk other factors, such as the complexity of the process software and the degree to which the device manufacturer is dependent upon that automated process to produce a safe and effective device, determine the nature and extent of testing needed as part of the validation effort. Documented requirements and risk analysis of the automated process help to define the scope of the evidence needed to show that the software is validated for its intended use.
Based on the FDA description it is in our opinion that the level of risk associated with TFS is low as the true risk with the project lies with the artifacts stored within TFS and not TFS itself.
Note: You must conduct a proper risk analysis to support this conclusion.
With the assumption that the risk level will remain low with TFS we propose the following approach:
1) Installation qualification (IQ) validation. Work with members on IT to establish a straightforward minimal process to validate the hardware that will be used for the system.
2) Define a streamlined validation process that could be repeated to validate the system when patches or updates are applied.
3) Reduce the number of test protocols produced. Construct the test protocols in a manner that covers multiple system requirements. This will also reduce the amount of duplication inherent in many of the steps within the test protocols.
4) Focus on what has been customized. There is no need to go through ever permutation and combination on how TFS works. Simple focus on the “happy path” on the most common activities and ensure coverage for any configuration changes (e.g. additional fields, workflow changes).
5) Work closed with Quality Assurance (QA) to ensure timely involvement when approvals are required. It does make not much sense when the process is stalled due to an approval not being received to execute a test protocol.
6) Approach the validation of TFS in an iterative manner. Validate one workflow at a time and release it into production. The maintenance of a product backlog for the validation project will help demonstrate progress.
The essence of the TFS validation effort is to establish that “we know it works” and with our leadership for validation projects we can help ensure that the key features are verified and validated in an appropriate level of detail. This approach would rapidly accelerate the implementation of TFS.
