1. Purpose
The purpose of this Guideline is to define and provide guidance on the requirements for managing and documenting changes which take place during the development, implementation or operation of a computerised system, including its supporting operating environment.
2. Scope and Applicability
The change control principles in this Guideline support the delivery and ongoing support of well-defined systems to meet user requirements. They are essential when supporting validated processes and maintaining regulatory compliance. This Guideline applies to information/business systems, process control systems and laboratory instrumentation/systems. It applies to the following as applicable to the specified system throughout its life cycle:
– Application Software
– Operating System Software
– Embedded Software
– Computer Hardware (including microprocessors, PLCs etc)
– Networks
– System and Configuration Data
– System Documentation
This Guideline does not apply to routine changes to data, methods, reports or facilities that, in principle, are subject to predicate rules (e.g. Good Laboratory Practice, Good Manufacturing Practice and Good Clinical Practice).
3. Definitions
3.1 Computerised System
A group of hardware components assembled to perform in conjunction with a set of software programs which, collectively, are designed to perform a specific function or group of functions in a defined environment (and including peripheral devices, personnel and documentation, e.g. manuals, SOPs).
3.2 Change Control
The process of maintaining control of the status of computerised systems by the establishment of local procedures requiring the evaluation, documentation, approval and controlled implementation of all changes by qualified representatives of appropriate disciplines.
3.3 Predicate Rule
The governing national and international regulations and guidance covering Good Laboratory Practice, Good Manufacturing Practice and Good Clinical Practice.
4. Responsibilities
To ensure that uncontrolled changes are not made to systems and equipment covered by this Guideline, it is essential that clear, unambiguous responsibilities are established for the management of all systems and system components.
4.1 Change Control Forum
During system development a forum (eg ‘Change Control Panel’) should be established to oversee change requests for the project phase. This forum will report directly to the steering group for the project. Normally it will require at least two people including the System Owner/Project Manager and Infrastructure Manager or their delegates, as appropriate, with technical and Quality Assurance representation where necessary. For the operational phase of a system a different forum will be required (eg ‘Change Control Board’) replacing the function of both the steering group and the development change control forum and this should be chaired by the System owner or delegate (eg Application Manager). Normally it will require at least two people including the System Owner, Application Manager or their delegates, as appropriate, with technical, infrastructure and Quality Assurance representation where necessary.
Both forums should be competent to:
– Assess all aspects of the proposed change
– Recommend acceptance/rejection/deferral of the proposed change
– Assess the impact of any proposed change in terms of cost/benefit
– Define the scope of the validation/testing work
– Ensure that all key documents, including manuals, training and SOPs affected by the change are amended, and that the change is complete
– Agree the work plan for an approved change
4.2 System Owner
This is the individual with responsibility for the business area or process the system is automating or supporting. During the system development project, prior to the appointment of a system owner, the project sponsor will assume this role. Some system owners may delegate some or all of the maintenance tasks including change management. Where this is the case, their areas of delegated responsibility will be clearly defined. The system owner will:
– Approve recommendations of the change control forum (ref section 4.1)
– Ensure that all changes requested are coordinated, using a documented procedure.
– Ensure that changes to the system are made and controlled according to defined standards.
– Ensure proper communication and consultation regarding the change particularly where a system crosses organizational or functional boundaries
4.3 Central Super User
Coordinate/implement/manage routine activities so that the change controls are properly applied.
4.4 Project Manager
Ensures that relevant procedures are followed and that suitable change control procedures are in place before any development or enhancement is made during new system developments or amendments to existing systems. Act, with appropriate business support, on behalf of the system owner until formal handover.
4.5 Infrastructure/ Service Manager
Ensures that due consideration is given to the potential impact of infrastructure changes on supported applications in consultation with the system owner or project manager as appropriate. Ensures that formal change control procedures are established and followed for the installation, maintenance and operation of computer hardware and networks, infrastructure software and system and configuration data.
4.6 System Developer
– Uses the formal change control procedure as appropriate to the stage and type of the system development or change
– Evaluates the requested change and providing resource estimates
– Uses appropriate documented development methodologies, including version control and revision comments as applicable Implements the requested change when authorised to do so.
4.7 Quality Management
4.7.1 GxP QA
* Review and approve, if appropriate, for compliance with GxP.
4.7.2 IS QM
* Review and approve for adherence to the IS quality management system.
* Contribute to the development of the validation/qualification approaches for the change.
5. Guideline
All changes must be controlled and documented. In new project developments the formality of the change control processes increases as the project advances. Initially this may be in the form of informal project team discussions, through formally recorded project team meetings, to a formal change request process. The need for increasing rigor and formality depends on the impact on system lifecycle documents as these are developed and related to each other. Changes to implemented systems must always be reviewed, impact and risk assessed, authorised, documented, tested and approved before the system is returned to operational use with the change live. In principle, change management follows the process flow outlined in Appendix 6.
5.1 Making a Request
Requests will be received from a number of different sources (e.g. system users, system managers, infrastructure managers, departmental managers, developers) and by a number of different communication methods. All requests for change must be logged in an index, uniquely referenced and made available for review by the relevant change control forum.
5.2 Specification of Change
Any proposed change must have a detailed specification of the change or new functionality. This may be developed in stages as per the lifecycle model user requirement, functional specification etc, provided that sufficient information is available at the time of submission for the change control forum to make a decision.
5.3 Technical Assessment
It may be appropriate to make a separate preliminary technical assessment of requested changes that should be made available to the change control forum. This would include an assessment of the technical implications of the change, how it should be implemented and its estimated development/implementation time. In particular this technical assessment should include, as appropriate, validation, regulatory and risk assessment, security assessment, ability to reverse the change and recovery strategy as well as disaster recovery.
5.4 Change Disposition and Authorisation
The change control forum should review each change request and carry out a preliminary desirability, feasibility and impact assessment based on the perspectives of business need, compliance requirements, financial and other relevant factors. The following decisions are possible: Reject – do no further work on the request Defer – defer the request to a later date or for further details Accept – proceed to develop the request, or an agreed version of the request, for implementation Authorization to proceed must be confirmed by the system owner or delegate, together with QA as appropriate. For both new and existing systems, the proposal, key points reviewed, the decision and relevant supporting information must be retained for at least the lifetime of the system.
5.5 Rejected Change Requests
The reason for rejection should be noted on the change request, the originator notified and the record archived.
5.6 Deferred Change Requests
Where a request is recognised as a good idea or sensible change, but for reason of cost, risk, expediency, priority etc cannot be immediately progressed the originator should be informed and the request kept on file for subsequent reconsideration. If possible the appropriate date to reconsider the request should be specified.
5.7 Accepted Change Requests
Authorization to proceed must be formally recorded.At this stage the clarity of definition of the following should be confirmed:
– The scope of the change and which controlled items in the scope of this guideline are affected
– The impact of the proposed change
– The cost and effort required, including IS, engineering and all other business elements
– A risk assessment and back-out plans in case of failure
– A list of controlled items requiring revision
– The extent of testing required
– New or revised training requirements
– The range and extent of communication required for the change to be successfully implemented
– Any new support requirements
5.8 Change Completion and Approval
When all elements of a change have been implemented, documentation revised and appropriate testing carried out the system owner or delegate, together with QA as appropriate, should review and approve the formal change request, which should then be archived and the change history updated to include this change.
5.9 Exceptions
5.9.1 Like-for-like (i.e. functionally identical) replacements
It is not always easy to assess whether a situation is truly like-for-like and consideration should always be given to the potential impact of any subtle change. Where there is no discernible change then replacement can be by normal maintenance procedures. Like-for-like replacement should still be recorded in the system history.
5.9.2 Emergency changes
It is recognised that certain changes need to be implemented as quickly as possible. These situations will commonly arise when a user or system owner reports a fault in a critical area of use or operation and its resolution is essential to completion of a time-dependent task. What constitutes an emergency change should be clearly defined. Even in an emergency, testing of critical elements of the change should be carried out before implementation to avoid unforeseen serious repercussions. Any necessary interim procedures should be considered and specified. The change must be subsequently reviewed, tested, documented and approved according to the appropriate procedure and in a timely manner.
6. Appendices