A common question I get from my clients is ‘what documentation/SOPs are necessary to properly implement a regulated computer system? I recommend a list found in Appendix A of Guidance for Industry Computerized Systems Used in Clinical Investigations FDA 2007 Guidance Document.

This list is defined for Clinical sites and related activities as stated in the scope of the document. However, after reviewing the list provided in Appendix A, I believe that it is applicable to other regulated systems beyond the scope clinical systems. This post is recommended for anyone who plans on implementing a regulated computer system.

List of Documentation

This is the actual verbiage from Appendix A. I’ve added my own comments below in BOLD.
Standard operating procedures (SOPs) and documentation pertinent to the use of a computerized system should be made available for use by appropriate study personnel at the clinical site or remotely and for inspection by FDA.

The SOPs should include, but are not limited to, the following processes.

System Setup

System setup/installation (including the description and specific use of software,hardware, and physical environment and the relationship)

I would include Configuration Document/Procedure to specifically describe how the system is setup. Screenshot within this document are a strong recommendation.

System Operating Manual

The software/hardware vendor should provide this but make sure you review this once you understand how the system operates. Often times the vendor will not make the proper corrections between software releases and may lead to improper software operation if this is the primary end user training.

Validation and Functionality Testing

See GAMP 5 or other CSV recommendation. This is too big of a topic to comment on within this post.

Data collection and Handling

Data collection and handling (including data archiving, audit trails, and risk assessment)
Risk Assessment should be its own document as far as system Risk is concerned. It may also be included as part of Change Control procedures.

System Maintenance

I would make the system decommissioning a separate process and include a Data Retention Procedure. Make sure you can still access stored information for the appropriate amount of time after the system is decommissioned.

System Security Measures

Don’t forget to coordinate with the overall IT procedures on system security. You may be out of compliance if your program security procedure is separate from IT computer security and they don’t follow the same security requirements. (i.e. password expiration, length, login attempts before user lockout, etc.)

Change Control

I would personally limit Change Control to validated systems. You may encounter many errors during validation that are a normal part of the validation process that may otherwise overwhelm your Change Control process and delay system validation. However, process/procedure/quality related changes may still require Change Control.

Data Backup, Recovery, and Contingency Plans

Don’t forget to test the system recovery as part of this process. Having the procedure is fine. Make sure the backup and restore actually works before you actually need a real restore of your data.

Alternative Recording Methods

A paper backup is one method that is possible. Another method would be duplication of the production site, alternative hardware backup (server or other HW), duplicate system. IT can be a valuable resource for alternative methods or configurations that will mitigate risk.

Computer User Training

The vendor will often provide material related to system usage. Make sure this material is specific to the level of access for the end user and their associated job function. In addition for COTS applications, the specific configuration may require extensive revision of the vendor provided training.

Roles and Responsibilities

Roles and responsibilities of sponsors, clinical sites and other parties with respect to the use of computerized systems in the clinical trials.

One area that should be addressed is Signature Authority. If a user delegated their authority to another user per procedure, make sure the software can capture this information properly. Another recommendation is a roles/rights matrix for the system users.

It is better to define this per role in the system if possible since this matrix will have to be updated with personnel changes if it is user based.