COMPUTARISED SYSTEMS – LIFE CYCLE MANAGEMENT

What is computer system? 

The computer system is composed of all computer hardware, firmware, installed devices and software controlling the operation of the computer. 

What is computerised system? 

Computerised system is composed of the computer system and the controlled functions or process. i.e. a process or operations that is integrated with a computer system.

 

The controlled function may be composed of equipment to be controlled and operating procedures that define the function of such equipment or it may be an operation, which does not require equipment other than the hardware in the computer system. 

• A large variety of computerised systems are used in regulated user organisation these range from the simple standalone to large integrated and complex systems. 

• Regulatory user should have an inventory of all their computerised systems, ownership, supplier, developer, functionality, links and validation status. 

• A policy and validation master plan for computerised systems should also be available for inspection. 

• It would be expected that regulated user validation policy and validation master plan should identify the companies approach to validation and its overall philosophy w.r.t computerised systems. 

The VMP should

• Identify which computerised systems are subject to validation. 

• Provide brief description of the validation strategies for different categories for computerised systems as well as other validation activities. 

• Outline protocols and related test procedures for all validation activities including computer systems. 

• Define reporting requirements to document validation exercises and related results. 

•  Identify key personnel and their responsibilities as part of the validation program. 

Computerised systems Life cycle: 

The computerised system life cycle encompasses all activities from initial concept to retirement The life cycle of any system consists of four major phases as follows.

 • Concept 

 • Project

 • Operation

 • Retirement 

CONCEPT PHASE: 

During the concept phase the regulated company considers opportunities to automate one or more business process based upon business need and benefits. Typically, at this phase, initial requirements will be developed and potential solutions considered. Activities in this phase will depend on company approaches to initiating and justifying commencement 

PROJECT PHASE: 

Project phase contains following stages

 1. Planning  2. Specification, configuration, coding  3. Verification / Calibration / Qualification / Validation 4. Reporting and release 

1. Planning:

Planning should cover all required activities, responsibilities, procedures and timelines. Activities should be scaled according to 

a) Impact assessment on patient safety, product                         quality and data integrity:           i. The system impact on patient safety, product                            quality and data integrity shall be evaluated.          ii. 21 CFR Part 11 assessment of the system shall                      be done.
 b) System complexity and novelty (Architecture and                    categorization of system components)            i. System complexity shall be evaluated

 c) Vendor /Supplier assessment: 

• Regulated companies should consider formally assessing each supplier of GxP regulated computerised system/ service being provided. Documented justification should be provided for not assessing supplier of GxP regulated systems/services. 

• The computer system supplier should build quality and integrity in to software product during development as it cannot be added effectively later by regulatory company.

• Supplier assessment is an opportunity to develop relationship with suppliers and to clarify expectations and intentions and to identify misunderstandings and risks. Mainly there are three type of assessments. 

1. Basic assessment based on available information 
2. Post audit, using a questionnaire 
3. On-site audit by relevant specialist, auditor or auditor team 

• Typically, a basic assessment is sufficient for lower impact system, while higher impact system may require formal audits. Postal audits may be appropriate for suppliers of standard and configurable products and services. Once the supplier have been accepted, they may be subject to periodic re-evaluation by the regulated company at the frequency specified in their SOP’s.

• Regulated company normally maintain a supplier audit schedule which indicate which supplier have been audited, when the audit took place, the reason for the audit. 

• A clear and complete understanding of user requirements is needed in order to facilitate effective planning. Initial requirements are often developed during the concept phase and completion of user requirement gathering typically occurs during the planning phase.

 d) User requirement specification (URS):

• User requirement specification should describe the required functions of the computerised systems and be based on document risk assessment and GMP Impact. User requirement should traceable throughout life cycle.

• The URS should also specify what system must and must not do. URS should satisfy the following criteria

• Each URS should be reviewed, authorised and uniquely cataloged. • There should be no conflict between requirements.

• Each requirement, particularly those to be met to satisfy GXP expectations, should be specified in a manner such that compliance with the requirements is capable of being verified objectively by an authorised method. E.g. Inspection, analysis or test.

• The URS, although independent of supplier should be under stood and agreed by both user and supplier. There should be a clear distinction between mandatory regulatory requirements and optional features.

• The URS should contain functional and non-functional requirements, functionality effectiveness, maintainability, usability etc. Requirements should be objectively verifiable

• URS should also form the basis for a risk assessment of the system for GXP compliance requirements. And nature of any GXP risks should be clearly stated. 

• A URS defines clearly and precisely what the regulatory company requires the system to do. Requirements should be specific, measurable, achievable, realistic, and testable. And requirements can be priorities as mandatory, beneficial and nice to have.

Content of URS typically includes

• Operational Requirements (Functions, data, technical, interface and environment) 

• Functional requirements include safety, security including access control, audit trail, use of electronic signatures, output (report files) and unambiguous error message.

• Data requirements includes definition of electronic records, definition of data, data migration, data input and subsequent editing, backup & recovery, archive requirements, data security and integrity. 

• Technical requirements includes changes in system operation, disaster recovery, performance and timing requirements, action required in case of failure, capacity requirements, access speed requirements, hardware requirements, portability, efficiency and configurability. 

• Interface requirements includes interface with users (these should be defined in term of roles like Plant operator, warehouse administrator…etc.) and interface with equipment’s such as sensors & actuators.

• Environment requirements includes lay out, physical conditions like temperature, humidity, physical security, power requirements 

• Constraints to be observed

•  Constraints includes Compatibility, availability, reliability, maintenance & down time, working methods, user skill levels, expansion capability, expected life time and long term support. 

• Life cycle requirements includes development, procedure, testing requirement, documentation, tools, training course…etc.

 2. Specification, configuration, coding: 

The number and level of detail of the specification will vary depending upon the type of system and its intended use.

a) Functional/process/business specification: i. From the URS, The supplier of the software would be able      to develop the functional specification. The functional              system should define a system to meet the URS i.e.                Customer needs.

ii. The functional specification should provide a precise and        detailed description of each of the essential requirements      of the computer system and external interfaces this                means description of functions, performance and where          applicable, design constraints and attributes.iii. For particular types and levels of systems it may be                appropriate to have combined URS & FS. 
b) Configuration specification:      Which includes the configuration details 
c) Detailed design specification:     Which included complete design details 

 3. Verification / Calibration / Qualification / Validation:           (Testing): 

• There is generally increasing testing requirement from standard software and hardware to custom software and hardware. The increased testing derives from a combination of greater complexity and lesser user friendly.

• For some simpler GxP systems, for example certain PLC’s system based on basic algorithm or logic sets, the functional testing may provide adequate assurance of reliability of computerised systems. For critical and/or more complex systems the verification system that is conducted at the IQ, OQ and PQ stage provides only a limited level of assurance that the system does what it purports to do reliably. This level of testing provides only limited assurance of the operation and reliability of hidden functions and code. For complex systems there should also be a high level of assurance that the development of the software has ensured delivery and operation of a quality product that is structurally sound, clearly defined and controlled. 

• Test scripts related URS & FS should be developed, formally documented and used to demonstrate that the system has been installed and is operating and performed satisfactorily.

• Regulated users should be able to demonstrate formal acceptance of systems after testing and controlled transfer in to live operational environment. 

Categories of Software: 

Category -1 (Infrastructure Software):

Description: 

a) Layered software’s (i.e. Upon which applications are              build) 

b) Software’s used to manage the operating environment. 

Typical examples: a) Operating system b) Database engines c) Middle ware d) Programming language e) Statistical package f) Spreadsheets g) Network monitoring tools h) Scheduled tools i) Version control tools 

Typical Approach: 

Record version number and verify correct installation by following approved installation procedures. Calibrate instruments as necessary. 

Category -3 (Non-configured software): 

Description: Run time parameters may be entered and stored but the software cannot be configured to suits the business process.

Typical examples: a) Firmware based applications. b) COTS Software c) Instruments 

Typical Approach:i. Record version number and verify correct installation ii. Life cycle approach, Risked based approach for supplier        assessment, iii. Risk based tests against requirements iv. Procedures in place for maintaining compliance and               fitness for intended use and fitness for intended use. 

Category -4 (Configured software):

Description: 

Software’s that can be configured by user to meets the specific needs of user business process. Software code is not altered. 

Typical examples: a) LIMS b) Data Acquisition systems c) SCADA & ERP d) CDS & EDMS e) Building management systems f) Spreadsheets g) Simple human machine interfacesh) Clinical trial monitoring 

Typical Approach:

i. Life cycle approach, 

ii. Risked based approach for supplier assessment, 

iii. Demonstrate supplier has adequate QMS & Design                 specifications. 

iv. Record version number and correct installation.

v. Risk based testing to demonstrate application work as            designed in test environment and within business process 

vi. Procedures in place for maintaining compliance and               fitness for intended use and fitness for intended use. 

vii. Procedures in place for maintaining compliance and                fitness for intended use and fitness for intended use. 

viii. Procedures in place to manage data 

Category -5 (Custom software): 

Description: 

Software’s that custom designed and coded to suit the business process.

Typical examples: a) Internally and externally developed IT applications b) Internally and externally developed process control applications c) Custom firmware 

Typical Approach: i. Same as configured product and  ii. More rigorous supplier assessment with possible supplier       audit. iii. Possession of full life cycle documentation iv. Design and source code review.

Categories of Hardware: 

Category-1: (Standard hardware components) 

The majority of hardware’s used by the company will fall into this category. Standard hardware components should be documented including manufacturer or supplier details, and version numbers. Correct installation and connection of components should be verified. The model, version number and where available, serial number, of pre-assembled hardware should be recorded. Pre-assembled hardware does not have to disassemble. In such cases the hardware details can be taken from the hardware’s data sheet or other specification material. Configuration management and change controls apply. 

Category-2: (Custom built components)

Custom items of hardware should have a design specification and subjected to acceptance testing. The approach to supplier assessment should be risk based and documented. In most cases a supplier audit should be performed for such hardware development. Assembled systems using custom hardware from different sources require verification confirming compatibility of interconnected hardware components. Any hardware configuration should be defined in the design documentation and verified. Configuration management and change control apply. 

4. Reporting and release: 

The system should be acceptable for use in the operating environment and released in to environment with controlled and documented process. Acceptance and release of the system for use in GxP regulated activities should require the approval of the process owner and system owner and quality unity representative. 

At the conclusion of the project, a computerised system validation report should be produced summarizing the activities performed, any deviations from the plan, any outstanding and corrective actions and providing a statement for intended use of the system. 

OPERATION PHASE:

• As part of preparing final acceptance and formal handover for live operation, the regulated company should ensure that appropriate operational processes, procedures and plans have been implemented and are supported by appropriate training.

• Once this has been accepted and released or use, there is a need to maintain compliance and fitness for intended use throughout its operational life. This is achieved by the use of up to date documented procedures and training that cover use, maintenance and management.

• The operational phase of system may last many years and may include changes to software, hardware, the business process and regulatory requirements. The integrity of the system and its data should be maintained at all times and verified as part of periodic review. 

• As experience gained during operation, opportunities for process and system improvements should be sought based on periodic review and evaluation, operation and performance data and root cause analysis of failures. Information from the incident management and CAPA processes can be provide significant input to evaluation. 

• Security of the system and security o the data is very important and the procedures and records pertaining to these aspects should be based on the IT policies in conformance with the relevant regulatory requirements.

• It is very important for a regulatory user to maintain the procedures and records related to the access to the system. There should be clearly defined responsibilities for system security management suitable for both small and complex systems, including: 

a) The implementation of the security strategy and                       delegation b) The management and assignment of privileges c) Levels of access for users d) Levels of access for infrastructure (firewall, backup, re-          booter, etc.).

• Examination of procedures and records should assure that the following basic requirements are satisfied. 

• Access rights for all users are clearly defined and controlled, including physical and logical access. b) Basic rules exist and are documented to ensure security related to personal passwords or pass cards and related system/data security requirements are not reduced or negated.

• Correct authority and responsibilities are assigned to the correct organisational level.

• Procedures are in place to ensure that identification code and password issuance are periodically checked, recalled or revised.

• Loss management procedures exist to electronically invalidate lost, stolen or potentially compromised passwords. The system should be capable of enforcing regular changes of passwords.

• Procedures identify prohibited passwords.

• An audit log of breaches of password security should be kept and measures should be in place to address breaches of password security.

• The system should enforce revoking of access after a specified number of unsuccessful logon attempts.

• Measures are needed to ensure the validated recovery of original information and data following back up, media transfer, transcription, archiving, or system failure.

• Attempted breaches of security safeguards should be recorded and investigated.

• Some equipment, such as standalone computerised systems and dedicated operator equipment interfaces and instruments may lack logical (password etc.) capabilities. These should be listed, justified and subjected to other procedural controls.

• The validated back-up procedure including storage facilities and media should assure data integrity. 

• The frequency of back up is dependent on the computer system functions and the risk assessment of a loss of data. In order to guarantee the availability of stored data, back-up copies should be made of such data that are required to re-construct all GxP-relevant documentation (including audit trail records). 

• There should be written procedures for recovery of the system following a breakdown; these procedures should include documentation and record requirements to assure retrieval and maintenance of GxP information. 

• The examination of the procedures and records should assure that the following basic back up and disaster recovery requirements are satisfied:

a) There should be procedures to assure routine back-up of data to a safe storage location, adequately separated from the primary storage location, and at a frequency based on an analysis of risk to GxP data.

b) The back-up procedure including storage facilities and media used should assure data integrity. There should be a log of backed up data with references to the media used for storage. Media used should be documented and justified for reliability.

c) All GxP related data, including audit trails should be backed-up.

d) Procedure for regular testing, including a test plan, for back up and disaster recovery procedures should be in place.

e) A log of back up testing including date of testing and results should be kept.      

A record of rectification of any errors should be kept.

• It is expected that appropriate controls will exist such as maintenance of a register of authorised users, identification codes scope of authorised action in support of GxP electronic records and electronic signatures.

RETIREMENT PHASE: 
• This section covers system withdrawal, system decommissioning, system disposal and migration of    required data. 

WITHDRAWAL: Removal of system from the active operations. i.e. users are deactivated, interfaces disabled. No data should be added to the system from this point forward. Special access should be retained for data reporting result analysis and support. 

DECOMMISSIONING: The controlled shutdown of the retired system. 

DISPOSAL: 

Data, documentation, software or hardware may be permanently destroyed. Each may be reach this stage at a different time. Data and documentation may not be disposed of until they have reached the end of the record retention period as specified in the record retention policy. Due to volumes of data and records involved, retirement can be a major task. 

Consideration should be given following points.

a) Establishing procedures covering system retirements including withdrawal, decommissioning, and disposal as appropriate. 

b) Documentary evidence should be retained of actions taken during retirement of the system. 

c) GxP records should be maintained, their required retention periods and when record can be destroyed. 

d) The need to mitigate records to new systems or archive and method of verifying and documenting this process

e) Ability to retrieve these mitigated records on the new systems. 

DATA MIGRATION: 

Data migration may be required when an existing system is replaced by a new system, when an operating system experiences a significant change, or when the scope of use of system changes. The migration process should be accurate, complete and verified.