Retrospective Validation of Enterprise Systems

Yesterday was the fourth and final stop on our virtual book tour, looking at important topics from "Validating Enterprise Systems: A Practical Guide" (published by the Parenteral Drug Association and available via their bookstore)

In yesterday's session (recording and slides available here) we looked at the topic of retrospectively validating enterprise systems including why it is important to retrospectively validate systems that have not previously been validated and various reasons which lead to retrospective validation.

As we discussed yesterday, some of these reasons are understandable and acceptable to regulatory authorities while other reasons (such as ignorance or cost avoidance) are not.

We got through most of your questions yesterday but there were a couple of questions we didn't quite get around to answering so here they are.

Q. How is retrospective validation different to normal validation?

A. Many of the actual activities are identical but when retrospectively validating the system it is possible to leverage existing documentation (if any) and actual experience with the system.
Where good documentation exists and has been kept up-to-date the task of retrospective validation can be relatively quick. However, when little or no documentation exists it can take almost as long to retrospectively validate a system as it did implement it.

If the system has been maintained and supported using well documented processes such as help desk, incident management and problem management it will also be possible to leverage this information and use it to inform detailed risk assessments. With actual empirical data it is possible to make a more accurate assessment of risk likelihood and probability of detection.

Where a system was well implemented and has been well maintained this additional information can be justifiably used to limit the extent of the verification activities required as part of the retrospective validation.

Where this empirical data highlights problems or issues with the system it can also be used to determine which areas of the system require greatest focus as part of the risk-based validation effort.

This can mean that in some cases retrospective validation can be more successful than prospective validation in terms of appropriately addressing real risks in a cost-effective manner. However, as we stated in the webcast yesterday, because retrospective validation is not conducted as part of the implementation activities it is generally significantly more expensive than prospective validation which is well integrated with the original implementation effort. For this reason retrospective should be avoided.

Q. How common is retrospective validation? Do many companies have this problem?

A. There is a good deal of variation in the industry. At one end of the scale there are well-managed companies who are well aware of their regulatory responsibilities and who prospectively validate all appropriate enterprise systems at the time of implementation. At the other end of the scale there are companies who are either ignorant of the need to validate certain enterprise systems, or who choose to ignore the requirement in order to save money.

To some extent this depends on the maturity of the market and of the organisation. The most mature organisations have learned that risk-based prospective validation adds relatively little to the cost of implementation and provides good return on investment in terms of more reliable and robust solutions.

Less mature organisations still do not understand the cost benefit of risk-based validation or are not aware of the need to validate certain enterprise systems. While to some extent the US and Europe are more mature markets in this regard this is not universally the case. There are still new start-ups and companies where profit margins are slim who still do not prospectively validated their systems.

In markets which have historically been seen as less mature (e.g. Asia, Africa, Latin and South America) there is a growing realisation of both the need and attractiveness of validation with respect to implementing reliable and robust enterprise systems which help to streamline business operations. While retrospective validation is currently quite common in these markets (as they move to meet the growing expectations of changing local regulations and loom to export products to markets where the need for validation is already well established) this will change over time - and quite rapidly if other indicators of change are reflected.

This means that while retrospective validation will continue to be required in many markets for a number of years to come (and hence the need for a chapter on the subject in "Validating Enterprise Systems: A Practical Guide") we predict that this will be the exception within the next 5-10 years, with retrospective validation becoming rarer in all markets.


Thanks to all of you who have supported the virtual book tour we do hope you will join us for our forthcoming series of IS compliance and computer system validation webcasts over the next few months (details and registration available here)