I don’t even really like to use the word retrospective. I prefer to use the term validation or revalidation. Validation of software and computer systems used to automate regulated activities or record keeping is required for compliance with FDA regulations. In a situation where this has not been performed prior to actual use of the automation, non-compliance with FDA requirements becomes an historical fact and regulatory exposure remains.
Retrospective validation was a term initially used by FDA several decades ago when it first began requiring computer system validation and many systems were already in use without validation procedures or evidence of validation. Special techniques were permitted to retrospectively demonstrate that a computer system works properly. This generally applied to cases where there was independent historical evidence that could be collected and used to show proper operation. An example would be an automated sterilization system used in manufacturing where data from independent logging devices recorded key process variables such as pressure and temperature. This type validation was not intended by FDA to be acceptable practice going forward. The validation requirement was intended to ensure the computer system was proven to work properly for its intended regulated purpose prior to relying on it in production or the quality system. Of course, there are also FDA requirements for design control, verification, and validation of software used in medical devices or as a standalone medical device itself.
At this point in time the performance of retrospective validation is a corrective action which once complete reduces noncompliance enforcement risk going forward. If use of an unvalidated system presents meaningful field safety risk, then alternate methods should be used immediately to ensure safety while validation or replacement is performed. It can also be helpful if for past deficiencies there is evidence that if problems were uncovered they did not affect product safety or effectiveness; or appropriate field actions (e.g., recalls) were taken in a timely way.
Essentially any retrospective validation is documented admission of noncompliance. While this may be true in a specific situation there is no requirement to label it “retrospective” and draw attention to it. More importantly, I have seen many instances where companies have validated systems, but choose to improve the validation evidence or to raise the validation process to current standards — and yet refer to this as retrospective validation implying some historical noncompliance. In situations where a system is in use and validation activities are performed for any reason while there are often different but appropriate techniques that are more efficient then prospective methods or complete reverse engineering and prospective V&V.
When faced with situations where systems are being revalidated, brought up to current validation standards, or in a worst case scenario are in use and were never validated or the validation documentation is missing, the best starting point is to analyze why your company has enough confidence in the system to be using it. In another words just ask the knowledgable people involved: How do you know it works? (This is different then the question: Did we follow internal validation procedures?) Usually there are a variety of reasons ranging from their involvement in earlier validation or installation activities (even if insufficiently documented) to manual checking of the data involved, to evidence the actions or information produced have been accurate. Start here to put the best case together possible (since you may have an FDA inspection tomorrow/long before you have time to add to the validation); after all, the intent of the validation requirement in the regulations is to ensure product safety and effectiveness and speaking to why the system will not have a negative impact in this regard using whatever evidence or rationale you have, can reduce the likelihood or severity of an FDA enforcement action. Using this information perform a risk assessment based on intended use of the system and the confidence you have in the system determine if the system should be immediately taken out of use and if any emergency field actions should be taken (e.g. a computer system doing automated testing and release of product is faulty).
Once this is complete, the next best step is to ensure the system is under change control, and if it is not immediately institute formal controls. An unknown moving target can not be validated as the evidence you produce will not be traceable to specific versions. Following this, create a validation or re-validation plan, but unlike prospective validation planning, focus on being creative in the V&V techniques that can be advantageous given that the system is in use. While you must have documented requirements for the system, V&V can utilize review of existing records output by the system either in comparison to independent records or by instituting temporary manual data logging and comparison with the system displays or reports as the system is used (so the users are essentially doing some of the testing), or perhaps there is downstream manufacturing testing of the output of the system that can be used as verification evidence. Alternatively, you might manually construct test records or databases to be used alongside the real data or implement manual testing of the system outputs for a period of time or range of transaction types. What is most efficient will vary greatly based on the type of system, its intended use, and degree of product safety and effectiveness risk.
While much more could be said on efficient validation methods for systems in use and the universal question of “How much is enough” I will just end by saying that if there are widespread validation deficiencies, once field safety risk is assessed and ensured, the most important steps are to first make sure all existing system are under strict change control and changes are verified; and second to ensure all systems under development but not yet deployed are properly validated in a prospective manner prior to use. This helps show FDA you are implementing effective corrective and preventative actions going forward and prevents new non-compliances. There is little more frustrating to validation staff then working hard on retrospective validation while building up a continual backlog of new systems that are out of compliance and requiring perpetual retrospective validation. This like digging a ditch and throwing the dirt in front of you. At some point progress grinds to a halt.