Before conducting any periodic review you should classify each system as either GMP related or Non-GMP related and then prepare the write-up on the periodic review for GMP related computer systems.

The following points are some that should be addressed when creating your Periodic Review Policy document.

1. System Unique Identification Number & Location

Each computer application should have its own unique identifier and it should be clearly indicated where the application resides. In the case of a computer system this may be either the physical location of the server in the companies datacenter or if it is a cloud based application an assessment of the vendor’s infrastructure should be performed so the location of the software can be determined.

Understanding the scope of vitual machines and how they work in the regulated space is beyond the scope of this article but this should also be considered in terms of the location.

2. Computer System Validation Status (Includes Re-Qualification/Re-Validation)

Understanding the current state of the computer system is also very important, for example is the system currently in a validiated state? If not why not. It is also of paramount importance to track how many times the system has been revalidated and why?

For example is it a buggy system?

Does the vendor need to be audited again to ensure they are keeping their QMS inline with company policies. Have you got a periodic review policy for all vendors in place?

Is it time to upgrade to the latest version of the vendors software?

Related: Learn More About Software Validation

3. Review Computer System Security

In the ever evolving world of IT it is critical that you are secure from outside attacks. You need to keep up to date with the latest security patches from Microsoft and other vendors you work with. Is your current firewall still fit for purpose or do you need to upgrade. What about your backup and restore policies are they still working correctly should a disaster strike.

Working with cloud based applications throws up another host of questions about security so if you are working with such applications make sure you stay up-to-date with security best practice.

4. Back-Up & Restore Policies

As mentioned above ensuring that you have a solid back-up and restore policy is key to ensuring business continuity. It is good practice to test that these policies work regularly, for example if you upgrade your MS SQL application how can you be sure that the nightly back-ups are working correctly?

Don’t make the mistake that you can just document how you can do this, make sure that you fully test it works and that it works consistently and correctly.

5. Deviations, Issues & Downtime

Keep a log of all deviations, issues and downtime associated with a system. This information is invaluable for the continuous assessment of the system and it will clearly indicate where the issues are with each system.

If the same deviations are occcuring regularly is will be easy to see trends and where actions need to be taken for system improvement.

6. Changes to Computerized Systems

This not only includes changes to the systems but also changes to company standards, policies and procedures. All upgrades to each system should also be monitored closely with detailed risk assessments before any upgrades take place.

Keeping track of all on-going changes will make is much easier to pinpoint issues down the line.

7. Complaints

Its not uncommon for the userbase to complain about a new IT system when it goes-live, very few people appreciate change to the status quo when it involves their workload. With that in mind it’s a great idea to keep track of all complaints that the system receives so again the common trends are apparent.

If the complaints are justified and occcuring on a regular basis they can be acted on with the full facts at hand.

8. CAPA’s

Having a solid CAPA system will ensure bugs, issues and problems get fixed and get fixed correctly. You should already have a CAPA system in place that allows you to track any ongoing corrective and preventaive actions to a system.

These CAPA’s can then be linked directly to the systems unique identifier, each CAPA raised for each system should be referenced in the Periodic Review Document/Log.

9. Tracking

All actions identified from the current periodic review and status for the actions identified from the previous review should be documented. This will assist with knowledge transfer and assuring key pieces of information do not get lost when people move on.

Its not a good idea to have one system owner with all of the knowledge of the system in their head.

Summary

I hope the items above give you some indication of what you should include in your own periodic review policies and procedures.

Another point worth mentioning is how to trigger the review of each system to ensure each system gets periodically reviewed. It would be a good idea to use an IT system that has a triggering system so key stakeholders can be reminded of when such actions need to be taken.

You can make review reports part of your document management system; which specifies the review frequency of these report, you could also indirectly use the DMS to trigger the revision/updation of these reports.